09:20 < bridge> [teeworlds] Hardest to understand is probably the stuff in network.cpp. One of the few times I had to pull out a pen and paper to keep track of the packet flow 09:21 < bridge> [teeworlds] Sdl stuff you can usually grasp, if you know sdl to start with 12:12 < bridge> [teeworlds] I agree with jxsl, if stuff were commented, it'd way easier tu understand whats going on. 13:04 < bridge> [teeworlds] Commenting is harder 19:27 < bridge> [teeworlds] Any thought on this? https://github.com/teeworlds/teeworlds/issues/2788 21:18 < bridge> [teeworlds] Well I wouldn't call the ddnet tile system easy to extend 😅 21:18 < bridge> [teeworlds] It's just hard coding additional layers with a specific functionality 21:24 < bridge> [teeworlds] Allowing multiple game layers that can have additional parameters per tile (like teleport number) would be a start. Mods could use some identifier (uuid?) to actually use these parameters. 21:24 < bridge> [teeworlds] That would at least reduce the required code but you still need a custom client to modify the maps and ofc a server that can make use of the parameters 21:27 < bridge> [teeworlds] i just mean extensible tiles 21:27 < bridge> [teeworlds] just for game layer for start 21:27 < bridge> [teeworlds] thats better in ddnet than in vanilla 21:28 < bridge> [teeworlds] well okay... one could restructure the collision code a bit yeah 21:29 < bridge> [teeworlds] Do you have any good ideas for that? 21:30 < bridge> [teeworlds] Ah well, you said you dont have so much time yesterday :D 21:30 < bridge> [teeworlds] didn't look at that code for quite some time =\ 21:33 < bridge> [teeworlds] i am working on a """kinda api""" (not really an API, just code exporting xd) for teeworlds modding, so merging with master works better and the whole source doesnt get bloated. For this, i of course also want tiles to be extensible in an easy way 21:34 < bridge> [teeworlds] My work for now 21:34 < bridge> [teeworlds] https://github.com/fokkonaut/teeworldsmodhook