Time Nick Message 05:06 cheapie Hmm... on one hand celevator is currently the biggest lag source on VE-C when no players are online (a few things are running that shouldn't be, I need to look into that), on the other hand it doesn't really matter much as the max lag is fairly consistently 26ms when no players are online now 05:08 cheapie According to the built-in profiler, globalsteps are taking on average 1.6ms to process. I think that's fine. 05:15 cheapie Something that would be neat - not in terms of actually making any noticeable impact, just in the "lower numbers go brrrrrrr" department - would be the ability for a mod to have the engine stop calling its registered globalstep function(s) and then resume later. Sure, said functions could just immediately return, but... think of the... microseconds(?) that could be saved by just not calling them! :P 05:16 [MatrxMT] make a mod that manages other mods' globalsteps and takes them in and out :P 05:18 * cheapie gets to work writing Cheapie Systems Globalstep Manager Enterprise Edition™, complete with such features as taking an entire minute to load at server start and needing a second or two on every single globalstep to figure out which ones should run 05:19 cheapie FWIW this is what the profiler output looked like after letting it sit empty for a few minutes: https://gist.githubusercontent.com/cheapie/2e20a96bc8eb207195055b2f8e12aee4/raw/5944a417a7e5b2eb3210dd9ba4b6d9c340c7c6be/gistfile1.txt 05:20 cheapie In celevator I think there are some low-hanging fruit sorts of optimizations in globalstep[7] and globalstep[6], while the three on_step entries are a bug somewhere (probably on my end) as none of the relevant entities should exist in the world at the moment 05:51 cheapie I did the "low-hanging fruit" optimizations, among other things globalstep[6] fell from 454µs to 3µs average. Average lag with no players is now 335µs. 05:57 MTDiscord Excellent. 07:36 [MatrxMT] does dynamic lighting always draw it so the sun is exactly on the east-west axis, or can I tilt the sun north/south and have the dynamic lighting draw that correctly? 07:37 [MatrxMT] there is a tilt setting in sky after all 07:38 pgimeno I wondered the same thing 07:52 [MatrxMT] The answer is yes 07:52 [MatrxMT] https://forum.luanti.org/viewtopic.php?p=444380#p444380 07:53 [MatrxMT] it also pleases me that the positive numbers tilt the sun towards the north. For once, southern hemisphere is the default ! 07:56 [MatrxMT] mod idea: set the player's axial tilt according to their z coordinate, so they appear in the correct 'hemisphere' 07:58 [MatrxMT] then you should never spawn at a tundra at 0, 0, 0 07:59 [MatrxMT] yes, setting the heat values for mapgen would also make sense in the same world 13:43 ireallyhateirc btw would be nice if someone could confirm this bug https://github.com/luanti-org/luanti/issues/15643 13:44 ireallyhateirc it comes with a minimal reproducer too 15:31 ireallyhateirc Does river/cave generation happen on a separate thread? 15:32 [MatrxMT] all the mapgen happens on the one thread afaik 15:35 MTDiscord unless you enable multiple threads. but you dont want to due to the slice bug 15:36 ireallyhateirc The thing is the bug I linked above happens with emerge thread numer == 1 15:37 ireallyhateirc and I have a mod that modifies large chunks of map with Voxel Manipulators, for example I change spring soil (light) to winter soil (dark) and mapblocks that have caves/rivers often have glitches (outdated soil) 15:38 dzho sorry, I've got Debian and the 5.11 from flatpak. I did clone the reproducer repo game, checked it out to the indicated commit, but I don't see the pink blocks anywhere yet 15:38 dzho (which is to say, not Guix, and not 5.10, as the bug indicates) 15:39 ireallyhateirc that shouldn't make a difference 15:42 dzho ok, flew around a bit more to find river rather than ocean, but still no pink 15:42 ireallyhateirc I'll retest it, maybe something has changed since then 15:44 dzho ok 15:44 dzho not a total loss on this end, it's been a while since I dug down into the flatpak ~/.var 15:48 ireallyhateirc Okay, I know why you can't reproduce 15:49 ireallyhateirc I need to push a branch to the repo 15:54 ireallyhateirc dzho, do "git checkout transparent" 15:56 ireallyhateirc I believe it needs caves enabled in mapgen for the bug to appear and with that commit I reproduced the bug again with emerge threads = 1 15:59 ireallyhateirc the bug is quite rare but id does happen 16:01 dzho ok, got something coming up soon might not be able to get to it 16:01 ireallyhateirc this is from today on the "transparent" branch https://files.catbox.moe/5zbx48.png 16:02 dzho at least for a little bit. we'll see if someone shows up here on time 16:02 ireallyhateirc the nodes marked with "E" are mapchunk edges 16:04 dzho haha yeah I got that 16:04 dzho and ... there it is 16:05 dzho I am seeing pink blocks in lakebeds 16:05 ireallyhateirc yeah, so basically the pink nodes are the "default" stone which is used as the fallback for mapgen 16:06 ireallyhateirc but there's only one biome defined in that game with gray "base" stone 16:06 ireallyhateirc so pink nodes should never be generated unless mapgen somehow fails 16:07 dzho so, this is me having reproduced the bug, I take it? 16:07 dzho me, us, whatever 16:07 ireallyhateirc yeah, but what I really need is for core devs to make my bug report as a bug 16:07 ireallyhateirc because the issue went mostly unnoticed after being posted 16:08 ireallyhateirc to mark* 16:12 ireallyhateirc btw it appears that the improperly generated c_stone normally goes unnoticed because it is generated one node *below* the top layer of the bottom of the ocean 16:13 ireallyhateirc and also because if your game has c_stone set to "default:stone" then you won't notice a thing 16:14 dzho subtle 17:44 pgimeno @Blockhead256 thanks for the tip on the shadows, awesome 20:36 MTDiscord Command sent from Discord by luatic (formerly Grghliatic): 20:36 MTDiscord !tell ireallyhateirc rereading the conversation, it sounds like your problem might not have been with set_float, but rather you passed numbers as *keys* (or had them converted to strings implicitly when concatenating)? yeah, that will tostring, and that will lose precision. (set_float will also tostring and also lose precision.) 20:36 MinetestBot MTDiscord: I'll pass that on when ireallyhateirc is around 20:48 ireallyhateirc @luatic, yeah I used floats directly as keys but the outcome was the same when I explicitly used tostring 20:48 MinetestBot ireallyhateirc: Apr-27 20:36 UTC rereading the conversation, it sounds like your problem might not have been with set_float, but rather you passed numbers as *keys* (or had them converted to strings implicitly when concatenating)? yeah, that will tostring, and that will lose precision. (set_float will also tostring and also lose precision.) 20:49 ireallyhateirc thank you dear bots 20:59 [MatrxMT] the picture about the bug looks crazy, didn't know mapgen is so customizable 21:21 [MatrxMT] Whoever likes networking, I did a big QUIC library analysis (see GitHub). Lots of variance when it comes to usability. OpenSSL just finished and shipped its QUIC server code, so that might be the best. Likely I'll experiment with that next. 21:25 MTDiscord quiche (Cloudflare) was what paradust was looking at/using 21:25 MTDiscord also link: https://github.com/luanti-org/luanti/issues/15261#issuecomment-2833640668