Time Nick Message 00:24 paramat game#716 hmmmm 00:24 ShadowBot https://github.com/minetest/minetest_game/issues/716 -- Mgv5/mgv7 biomes: Enable patches of bare stone in deserts by paramat 01:33 paramat actually nevermind, thats's best done as a separate biome 03:10 ShadowNinja http://ix.io/lHH/diff 03:15 ShadowNinja Does anyone else fine using _m for private and protected members but no m_ for public members maddeningly inconsistent? 04:04 hmmmm nope 06:50 hmmmm https://github.com/minetest/minetest/pull/3310 17:37 Calinou hey, how about a "server_owner" or "server_admin" line in minetest.conf? 17:38 Calinou announces name of server owner/admin in server list, optional 17:38 Calinou possibly with "server_owner_email" and "server_admin_email" that accepts an e-mail address 17:50 PilzAdam Calinou, you can add that to the description 17:52 ElectronLibre PilzAdam: The point of such lines would have also been to be shown by a chatcommand to players who needed to know who is the admin/how to contact them to sort out issues. But adding it to the server's description also works I guess. 18:26 Calinou PilzAdam, yeah but it clutters it. 18:26 Calinou and it really doesn't incitate people to add their info 18:26 rubenwardy name? 18:31 est31 perhaps we can add a /notify_admin command 18:31 est31 as mod added to mtgame 18:31 est31 name isn't good as it needs to be an in-game name 18:35 est31 but yeah perhaps it would be a good idea to have an unified way to address the admin 19:13 kahrl is the output of --help and --version supposed to be prefixed with ": [Main]: "? 19:13 sfan5 no 19:15 CraigyDavi Was catch_up in ABMs set to true previously before https://github.com/minetest/minetest/pull/3248 ? 19:15 PilzAdam ShadowNinja, since your logging rewrite Minetest creates a debug.txt in the directory it's started from 19:15 PilzAdam can you revert that? 19:16 CraigyDavi Recently I'm noticing quite a few lag spikes probably caused by abms catching-up 19:18 est31 PilzAdam, I think it depends on the fact whether its compiled as in place or not in place 19:18 PilzAdam it previously created the debug.txt in the bin folder 19:18 PilzAdam I use run_in_place 19:19 PilzAdam now it creates it in any random directory I happen to be in 19:19 est31 CraigyDavi, yes it was true the whole time 19:19 CraigyDavi Ok 23:14 est31 ShadowNinja, non const references _are_ forbidden 23:15 ShadowNinja s/forbidden/discouraged/ 23:16 est31 in fact I think I had it the way you have it with the id being written into the area that gets passed as reference 23:16 est31 then hmmmm came around and said "no way" 23:16 ShadowNinja kwolekr's really the only one that's bothered with that point. 23:16 est31 please, lets have consistent rules 23:16 ShadowNinja I've changed it though. 23:16 est31 either remove the rule, or follow it 23:17 ShadowNinja est31: BTW, the noxt commit comming is working serialization. 23:18 est31 ShadowNinja, I have done no serialisation because the library has no way to bulk load from a format we specify 23:18 ShadowNinja The forEach thing isn't even necessary, since we can just iterate over areas_map (now that the SpatialAreaStore properly removes items from there). 23:18 est31 have you solved that problem? 23:18 est31 it did remove them before as well 23:18 est31 you just removed the code that removed it 23:19 ShadowNinja est31: You just iterate over the serialized areas and call insertArea. 23:19 est31 ShadowNinja, well yeah that works, but for large numbers its very complex. Better do bulk insert 23:19 ShadowNinja It might not be the most ifficient way to do it, but it's still plenty fast. 23:20 est31 (bulk insert is only needed for the library) 23:20 est31 once thats done, I'm ok with serialisation 23:20 est31 but then we really do need a better id algorithm 23:20 est31 your algorithm doesnt work for high insertion numbers 23:21 est31 even take the case where you add an area, remove, add remove etc 23:21 ShadowNinja est31: then make it a u64 or something. I think we can all agree 4 billion areas is for more than will ever be needed for the intended usecase. 23:23 ShadowNinja (Or 18446744073709551615 for u64) 23:23 est31 ShadowNinja, but why do you remove protection? It might be something different if you coded it, then I might perhaps even say, okay we dont need that, but its existing code in master and you make it behave _worse_ 23:23 ShadowNinja (actually make that 18446744073709551616) 23:23 est31 only to make it "simpler"? 23:23 est31 simple but yeah dont run a server too long 23:23 est31 this kind of thinking lead to y2k 23:24 ShadowNinja est31: You mean the "return nil of finding an ID takes too long" thing? 23:25 est31 ShadowNinja, yeah, that and the free ID finding algorithm. In fact it is precisely the same that is already there but it has an existing check for whether there is an area with that number, and it handles overflows properly 23:26 est31 (I mean the one that's there) 23:26 ShadowNinja est31: The largest amount of areas I've ever seem on a server was ~2k, so let's say 16k is a reasonable size, allowing for some area removal while the server's running. u32 is over 4 294 967k! 23:28 est31 still, it should return nil if the u32 range is full 23:29 ShadowNinja *sigh* fine, if you think it's that important. 23:34 est31 and sorry because of my earlier claims it seems it really hasn't removed from areas_map. 23:34 est31 good catch 23:45 ShadowNinja est31: Does it look better to you now? 23:48 est31 serialisation is better added in a separate commit 23:48 est31 perhaps even separate PR 23:49 ShadowNinja est31: It IS in a seperate commit. 23:49 est31 well one day the PR gets squashed, no? 23:49 ShadowNinja I can mark it experimental, but I'd rather have it at least compile, so I don't unknowingly break it when I change other things. 23:50 ShadowNinja est31: Related things, yes. But I'm ot qoing to squash the whole thing down to one commit. 23:50 ShadowNinja not* 23:51 est31 well, then we only discuss about what "Related" is 23:53 ShadowNinja Commits that fix previous commits get merged into the previous commit, possibly commits that change the same part of the code. It will still probably be more than 6 commits though. 23:53 est31 I do not want a history where we have a commit called "partial rewrite" which touches every file, and is a "partial rewrite" 23:54 ShadowNinja I don't want to squash it so much that you can't see the seperate changes. 23:54 est31 I also don't want a history where we have small related commits doing the same thing basically 23:56 est31 also, what benefit do you see in replacing an index based vector access with an iterator based one? 23:56 est31 https://github.com/ShadowNinja/minetest/commit/5ae8d1257083994322d20d789f84c4b2b3e00cb7#diff-62c82220ae4354cafe2c52da7e66e63eR212 23:56 est31 hmmmm has explicitly asked me to do that 23:57 est31 the code shouldnt be a place where everybody aligns it after how they like it best, such changes are pointless and wasteful 23:57 ShadowNinja I changed to it a map iterator, then I changed it back to a vector but diidn't switch from the iterator to the integer method. 23:58 est31 can you change it back? 23:58 ShadowNinja Yes. 23:58 est31 then the diff gets smaller, and perhaps similar commits can be merged more likely 23:59 ShadowNinja Except for the removeArea one, that looks much nicer with an iterator because of the erase call.