Time  Nick       Message
09:38 twoelk     has anybody had trouble with crashes after flying around a lot in a dreambuilder world?
10:38 paramat    can you obtain a gdb backtrace?
10:58 paramat    seems #8258 is wanted for 5.0.1, updated, tested and ready for review
10:58 ShadowBot  https://github.com/minetest/minetest/issues/8258 -- Confirm registration GUI: Remove positional strings to fix Windows bug by paramat
10:59 paramat    i'll attempt to get #8328 ready today too
10:59 ShadowBot  https://github.com/minetest/minetest/issues/8328 -- Vein ore: Don't vary perlinmap Y dimension per mapchunk by paramat
13:37 paramat    hmm #8300 is a difficult situation (another one), added some posts. tired now back on Saturday
13:37 ShadowBot  https://github.com/minetest/minetest/issues/8300 -- Segfault in noise.cpp
13:39 sfan5      the proper solution would be to have separate ore managers per thread
14:42 twoelk     once the stable branch of mt is stable maybe the games in the forum thread of games releases ought to be transfered to old games and games that work well with or maybe exclusively with mt5 should get new starter posts in the release section - stating the protocol break
15:16 VanessaE   what's the ETA on 5.0.1?
15:40 * mmuller  discovers 5.0.0 got released on 3/5 :-o
15:42 VanessaE   yeah and the devs were talking about doing a 5.0.1 release very soon, like in the last day or two.
15:42 VanessaE   just wondering when that'll be since my players have been asking about updating to 5.x and 5.0.0 has at least one critical bug.
15:43 * twoelk   might have seen someone trying to shove a week into that release date
18:23 p_gimeno   sfan5: my patch implements separate ore managers per thread, but it gets ugly on l_register_ore
18:23 sfan5      didn't look at it yet
18:23 sfan5      though, is there no way to "copy" an existing oremanager?
18:23 p_gimeno   you have to register the same ore with the same parameters in all threads
18:23 sfan5      maybe that'd help cleaning it up
18:24 p_gimeno   I think I have an idea for a somewhat cleaner alternative, still a bit hacky but better
18:25 p_gimeno   I don't think you want to copy the oremanager, it suffices to register the ore in all threads
18:27 p_gimeno   the issue being, when the threads already have the oremanager, a new ore may come and may need to be registered while another thread is accessing an existing ore
18:28 p_gimeno   they need separate oremanagers and separate ores; the ores are the ones that hold the noise
18:31 sfan5      you can register ores at runtime?!
18:32 benrob0329 I believe you can register most things at runtime, just that clients won't be notified of the change
18:33 p_gimeno   I don't see anything stopping anyone from calling register_ore at any time
18:33 sfan5      clients don't care about ores so that would even work
18:34 sfan5      p_gimeno: IMO it would be sensible not to allow register_ore after the mapgen has "spun up"
18:35 p_gimeno   well, that's not my call :)
18:35 p_gimeno   my patch has a lock around the ore manager just in case
19:36 p_gimeno   hmm, if I can count on register_ore always being called from the main thread then the patch is much easier
23:41 p_gimeno   never do complex intertwined thread programming when you're sleep deprived - I made a big silly mistake in the new patch by not really duplicating the ore
23:46 p_gimeno   there are parts of register_ore that I don't understand - what's the nodedef manager and why is pendNodeResolve called there?