| Time |
Nick |
Message |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 07:39 |
|
calcul0n joined #minetest-dev |
| 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 |
| 07:57 |
|
v-rob joined #minetest-dev |
| 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? |
| 08:41 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:25 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:32 |
|
YuGiOhJCJ joined #minetest-dev |
| 11:41 |
|
jonadab joined #minetest-dev |
| 12:25 |
|
YuGiOhJCJ joined #minetest-dev |
| 12:57 |
|
imi joined #minetest-dev |
| 13:25 |
|
appguru joined #minetest-dev |
| 13:40 |
|
appguru joined #minetest-dev |
| 13:59 |
|
appguru joined #minetest-dev |
| 14:35 |
MTDiscord |
<luatic> grorp: added to my misc stuff todo |
| 14:48 |
sfan5 |
v-rob: yes, it should |
| 16:26 |
|
fluxionary_ joined #minetest-dev |
| 17:40 |
|
json joined #minetest-dev |
| 18:21 |
|
v-rob joined #minetest-dev |
| 18:36 |
|
appguru joined #minetest-dev |
| 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:30 |
|
lhofhansl joined #minetest-dev |
| 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:11 |
|
Desour joined #minetest-dev |
| 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 |
| 21:36 |
|
v-rob joined #minetest-dev |
| 23:34 |
|
panwolfram joined #minetest-dev |
| 23:36 |
|
v-rob joined #minetest-dev |
