Time  Nick      Message
07:43 MTDiscord <grorp> @Lars "blocking" is treated as true by clients older than 5.9.0 should definitely be documented in lua_api.md
08:00 v-rob     Quick question about network code: Shouldn't https://github.com/minetest/minetest/blob/39f4d26177ec1c8f246133c532a42ef7429bc36d/src/network/serveropcodes.cpp#L220 have a value, since TOCLIENT_MOVE_PLAYER_REL is 0x5d?
14:35 MTDiscord <luatic> grorp: added to my misc stuff todo
14:48 sfan5     v-rob: yes, it should
18:36 appguru   merging #14290 in 5m
18:36 ShadowBot https://github.com/minetest/minetest/issues/14290 -- show more lines in chat scrollback buffer by Sokomine
20:18 Sokomine  thank you! also for the help offer on #14289  hope that can be made useful evenutally as well
20:18 ShadowBot https://github.com/minetest/minetest/issues/14289 -- Add client-side logging of chat messages by Sokomine
20:31 lhofhansl Does anyone know why we would save blocks with m_generate = false to disk? It seems pointless, and we could also simplify some things if we avoided that.
20:33 Krock     needed to save overlapping trees
20:33 celeron55 the commonly used term is overgeneration
20:34 Krock     but if you can make sure it's entirely made of CONTENT_IGNORE then it's fine I think
20:34 celeron55 the most common occurrence of that is trees that have been placed between two mapblocks
20:35 celeron55 yes you for sure could implement a special case like that. wouldn't simplify anything, but could speed up something
20:36 lhofhansl Ah. Makes sense. Thank you.
20:37 celeron55 some weeks ago on discord i suggested that someone might want to implement a special mode for the mapgen where all overgeneration and lighting and such is disabled that requires the mapgen to touch anything outside the chunk being generated
20:38 celeron55 in that mode the mapgen could work multithreaded without a fancy merge strategy
20:38 celeron55 i don't know whether it would be useful for anything in practice though
20:39 celeron55 alternatively looking at a system that would be able to merge the results of multiple mapgen threads without creating obvious artifacts like currently would be interesting and useful
20:40 celeron55 it wouldn't hurt to implement a generic system for merging voxelmanips into the world and reworking the mapgen system to use that
20:40 celeron55 and no, i don't expect anyone to have the time for any of this. just blurbing it out as it's interesting
20:42 MTDiscord <luatic> celeron55: it is possible to write mapgens that have cross-chunk features yet don't need overgeneration
20:42 MTDiscord <luatic> spiraling down's mapgen is written in such a way
20:42 celeron55 it for sure is, but you need to do it in a very specific way
20:43 celeron55 lighting is impossible though. if you just propagate sunlight down and skip the rest, then it's possibly doable. then you want to update it to a final state later as the player approaches it, or something
20:45 lhofhansl celeron55: Any chance you'll pick up #12690 again? I've been looking into ways to make MT more useful at larger viewing_ranges. I think we are close to the limit of what can be done with the current RemoteClient::getNextBlocks(...) design.
20:45 ShadowBot https://github.com/minetest/minetest/issues/12690 -- New mapblocks-for-sending selection algorithm by celeron55
20:47 celeron55 well, people have been spending lots of effort tweaking the current implementation instead of making a batter one
20:48 lhofhansl Yeah, I'm one of those people :)
20:53 celeron55 i don't know when i'll have time available in such amounts that i want to spend it loading up my brain with MT internals
20:55 celeron55 if someone adopts that PR i for sure can provide advice about anything related to it. IIRC all that was left about it was a bunch of smaller details, it worked fine
20:56 celeron55 i don't think the LoD system that would be built on top of it needs to be very clear at the time of merging that PR
20:57 celeron55 it could be anything. that PR just enables the server to prioritize between LoD data and detailed data, which is a prerequisite to any LoD system
20:57 celeron55 (along with handling view range adjustment better)
20:58 lhofhansl hard to make time for anything but little changes here and there
20:58 celeron55 (and possibly my favourite, the fov-first-then-the-rest loading order)
20:58 celeron55 (and better client mapblock memory management. no more continuous forgetting and re-sending of the same mapblocks)
20:59 lhofhansl MT now easily works for viewing_range of 1000, much more definitely needs (1) a better client-server protocol and (2) LOD
21:01 lhofhansl Alright back to work.
21:15 Sokomine  hm. my mg_villages mod has to deal with unwanted modifications from neighbouring mapblocks already. it's pretty complicated. they're fine in the rest of the map - just don't want holes in a village