Time Nick Message 01:09 MTDiscord Ronaldo, right there with you:) 01:34 lhofhansl Perhaps a dumb question... Do we need to save generated blocks at all, until someone actually modifies them? As is we save a block as soon as it is generated. 01:36 lhofhansl If they are not save they'll just be generated again. That is (currently) slower than loading them back, but it avoids storing stuff. 07:44 MTDiscord Just my 2 cents: If generated areas would regenerate all the time servers would lag horribly...it'a a huge difference between generation and loading from DB even on my server's SSD and I only use 2 of the most common mods that trigger on mapgen (caverealms, nether)...there are servers that rely on much heavier lua mapgens 16:28 Fleckenstein What are the core dev's opinions about dual wielding? 16:43 sfan5 sounds fine to me as a concept 17:10 specing How does one use the other item? 17:10 specing how would* one use it 17:26 MTDiscord Depends on the item 17:55 MTDiscord on_use_alt_hand on_punch_alt_hand etc 17:55 MTDiscord Same type of calls for the main hand 18:12 MTDiscord Oh, that's a thought 18:12 Krock yeah sure why not 18:13 specing I mean 18:13 specing How would a player use it? 18:13 Krock I suppose the other item is just used as placeholder for shields? 18:13 Krock I've seen that on some Minecraft videos, so that might be the idea 19:38 lhofhansl Merging #10670. The one where sfan5 had done a lot of thinking :) 19:38 ShadowBot https://github.com/minetest/minetest/issues/10670 -- Avoid marking map blocks dirty upon deserialization. by lhofhansl 19:43 lhofhansl Can we merge #10660? 19:43 ShadowBot https://github.com/minetest/minetest/issues/10660 -- Improve sky rendering performance by numberZero 19:45 rubenwardy yes, it has two approvals and no objections 20:48 lhofhansl Krock: Hopefully that re-loading of blocks already generated will go away after my fix. 20:48 lhofhansl Ok... Merging #10660 20:48 ShadowBot https://github.com/minetest/minetest/issues/10660 -- Improve sky rendering performance by numberZero 20:49 Krock why no squash? 20:50 lhofhansl whoa... Did I do it the wrong way? 20:50 Krock you did the rebase merge. unless that's the way you wanted it 20:50 lhofhansl I did. 20:50 lhofhansl Didn't want that. 20:51 lhofhansl I can force push the squash. 20:51 lhofhansl Or we can leave it. 20:51 sfan5 yeah that'd be good 20:51 Krock git rebase -i HEAD~10 for manual squash 20:51 Krock dunno whether there's "git squash" tbh 20:53 rubenwardy I mean, at least the commits largely make sense 20:54 Krock what's more worrying is that we're approaching open issue N°1000 20:56 lhofhansl Not a fan of force pushes. Lemme know. Sorry I didn't squash before merging. 20:57 sfan5 leaving it is also okay 20:57 rubenwardy yeah, I think it's fine to leave it 20:58 lhofhansl Meh.. Sorry about that folks. 20:59 Krock more commits = more gooder 20:59 lhofhansl I always amend my commits on my branch, so I forgot about it here. 21:02 kilbith stars are much clearer than before, normal? 21:03 kilbith I mean brighter 21:05 Krock feature 21:05 sfan5 I did notice that too but didn't investiage it 21:05 sfan5 investigate* 21:06 sfan5 I'm pretty sure it still respects the star color 21:08 kilbith maybe a ARGB->RGBA confusing 21:08 kilbith since gl_FragColor is RGBA and SColor is ARGB 21:10 Krock how can there be a segfault in "no code"? https://github.com/minetest/minetest/pull/10661#issuecomment-733948983 21:10 rubenwardy try building with debug info, to get the line 21:11 rubenwardy also, end of function sounds like a destructor 21:11 sfan5 0x000000000000007e surely won't have debug info 21:11 sfan5 Krock: did you try my suggestion with -fsanitize=address? 21:12 Krock sfan5: no sorry. did I mess this message earlier? 21:12 Krock *miss 21:12 sfan5 <sfan5> Krock: for 10661 I suggest testing your code compiled with -fsanitize=address 21:12 sfan5 <sfan5> because the segfault you have looks like a buffer overflow or similar 21:12 Krock oh! 21:21 sfan5 pushing http://sprunge.us/rzvY6s?diff (two commits!) in 10 minutes 21:28 Krock L111 } ; 21:32 Krock heap-use-after-free.. the struct contains a pointer which is then double-freed.. oh no. 21:37 Krock thank you, sfan5. issue solved 21:41 sfan5 oops long 10 minutes 21:42 sfan5 pushed 21:56 sfan5 lhofhansl: what was the purpose of blockpos_requested in struct BlockMakeData? 21:59 lhofhansl There wasn't any. :) 22:05 sfan5 ah so the removal is not related to the other change 22:17 sfan5 I wonder what those awful lack spikes are when you fly through lots of terrain 22:17 sfan5 please dont tell me it's the VBO clearing 22:22 sfan5 hmm now it's not as bad as before 22:23 sfan5 nah that's not it 22:25 sfan5 anyway: when there's lots of blocks loaded(?) and you have infinite view range enabled there are frametime spikes every few seconds, this doesn't coincide with HW buffer clearing 22:25 sfan5 I guess it's doing something to all loaded blocks since culling is disable with infinite view range (is it?) 22:26 sfan5 also relevant: I'm moving fast in the direction of unexplored land (so none of those whatever thousand blocks in memory are visible) 22:26 sfan5 well whatever 22:29 celeron55 is transfer of blocks continuous and not coincidentally spiky with that behavior? 22:37 sfan5 sometimes? maybe? 22:43 lhofhansl Sorry... Cooking dinner on the side :) 22:44 sfan5 I don't see any obvious correlation of the debug graphs here -> https://0x0.st/iRlW.mp4 22:44 lhofhansl I do not know what these spikes are, but when I tried, pretty sure that they are not due to the HW buffer clearing. 22:45 sfan5 the errorstream is not visible there, but hw buffer clearing only happens every 10 seconds 22:45 lhofhansl The lag is (still) mostly due to meshing, I think (not all meshes come from the mesh generator thread) 22:45 lhofhansl But it 22:45 lhofhansl 's so much better than before. 23:54 lhofhansl I'm going to merge #10637 soon'ish. 23:54 ShadowBot https://github.com/minetest/minetest/issues/10637 -- Avoid generating the same chunk more than once with multiple emerge threads by lhofhansl 23:54 lhofhansl (Thanksgiving fun)