Time Nick Message 12:29 proller https://github.com/minetest/minetest/pull/11910 another week of nothing 12:33 erlehmann proller rubenwardy already suggested a meeting and put your stuff on the agenda AFAIK 12:34 erlehmann also, look at how long others have to wait until their contributions are accepted, it is dog slow, but by no means unprecedented 12:35 erlehmann proller also did you fix the dissector and talk to himbeerserver and anon55555? 12:35 MTDiscord On it's own, this PR adds no functionality, yet risks breakage (which is "to be fixed in later PRs"). 12:35 erlehmann yes, that is bad 12:35 erlehmann nothing lasts as long as a temporary solution 14:31 proller where is breakage? 14:32 proller only one "broken" thing is mapgen_limit in teleport 15:37 MTDiscord What happens if a server used the provided compile flags and a client sent out-of-map coords? 16:56 proller now connecting between enabled and disabled flags not supported. 16:56 proller do not enable. 17:05 nrz i think this new release cycle is cool to start work on interesting things like this, and taccle this legacy limits, with some tester support maybe yes ? 18:53 rubenwardy What's the status of SDL support? 19:34 proller luatic> if this pr was merged 2 month ago now all compatibility issues was already solve 19:35 erlehmann how about you solve them first lol 19:35 erlehmann literally everyone is telling you that 19:35 erlehmann and we know you are capable! 19:36 proller also every dev wants different type of naming things 19:37 proller now it just type name change with few helpers 19:38 proller make compatibility - its big code change with new bugs 19:38 proller also need to decide how exactly keep compatibility? 19:39 proller 1. multicraft way about floats (pass protocol version to every read-write) 19:39 erlehmann speak old protocol with extensions? 19:40 erlehmann that way old clients then only go up to MAX_MAP_GENERATION_LIMIT or so 19:40 erlehmann or s32 bounds if you want to troll coredevs 19:40 erlehmann well s32 bounds - 1 invisible mapblock at least 19:40 erlehmann better stay with the current thing 19:40 proller 2. packet compatible (add new big numbers to end of packets) - it will increase some packets size, coord data will be duplicated 19:41 erlehmann well that sounds good 19:41 erlehmann what is the issue with it? 19:41 proller more network traffix 19:41 erlehmann i have analyzed traffic a lot and i would be *very* surprised if *that* is a problem ever 19:42 erlehmann compared to, say, contents of a mapblock being sent 19:42 erlehmann or, particles (lol) 19:42 proller empty old data will be send always, on later 5.6+ protocols 19:42 erlehmann i mean how much traffic are we talking per coordinate? 16 bytes? 19:42 erlehmann but for that you gain backwards compat ig? 19:43 proller +24 bytes for object positions 19:44 proller first way also makes per client backward compat without trash data 19:45 proller also size will be notable when 500+ clients connected 19:50 erlehmann so multicraft way is backwards compat too, but better you say? 19:51 erlehmann in any way, once you can demonstrate backwards compat word size enlargement i bet people will like your solution a lot more! 19:51 erlehmann (backwards compat as in: old clients see inner world) 19:52 erlehmann proller what is your thought of people who think y axis is not important btw? i think they are only thinking of minecraft 19:54 MTDiscord I think I have a decent suggestion now 19:55 MTDiscord If I'm not mistaken, the massive code change which is responsible for the large diff and might create lots of merge conflicts mostly is just a type rename which should be rather easy to review 19:56 MTDiscord Therefore, I suggest you take out all problematic extension of types to double their widths (the -32 flags) and make that your "part 2" 19:57 MTDiscord proller: part 1 would then only be the abstraction of the types, replacing floats, v3fs and aab3f with the ocoord type-based types and s16s, v3s16s etc with the npos types. ocoord would be just an alias for float / f32 and npos one for short / s16. 19:58 MTDiscord That can't possibly break anything, should be easy to review (just ensure that AST-wise, the replacements were done only for types and at the proper places), yet should get most future merge conflicts out of the way. 20:44 kilbith the "socket already in use?" thing still happen on Windows 21:22 proller luatic> how you will review just type change and check correctness? 21:23 MTDiscord how I would check the correctness of the type change? 21:23 proller now it 100% correct and compiles and works in any combinations of flags 21:23 MTDiscord Except I can hardly ensure the "works" part of "any combination of flags". 21:24 proller its impossible to find all block-node pos conversions without fully working code 21:41 erlehmann unit tests 21:41 erlehmann add unit tests for everything 21:41 erlehmann (lol)