18:08 < bridge> [teeworlds] before you think about implementing water, what about slopes? 18:15 < bridge> [teeworlds] slopes were already implemented at some point 18:16 < bridge> [teeworlds] it turned out that they don't integrate well in vanilla gameplay because they require tees to go on the ground where they are vulnerable (iirc) 18:16 < bridge> [teeworlds] so the idea was rejected 18:16 < bridge> [teeworlds] hmm, that reasoning is discussable 18:17 < bridge> [teeworlds] it is 18:17 < bridge> [teeworlds] the reason I see for slopes is less movement penalty 18:18 < bridge> [teeworlds] what we'd need imo would be a project where several physics modifications are implemented to let people alpha test the stuff, gather feedback, see what is judged fun etc. 18:18 < bridge> [teeworlds] i would really want slopes on the ctf5 spots, where you have a 1 block height difference 18:18 < bridge> [teeworlds] I agree with that alpha project 😄 18:18 < bridge> [teeworlds] without going through this intermediary state I'm pretty sure no physics addition will be accepted in teeworlds 18:22 < bridge> [teeworlds] in 0.6 I remember we had trunk versions, maybe 0.7.5 trunk or something 😄 18:35 < bridge> [teeworlds] trunk just means master 18:37 < bridge> [teeworlds] svn speak 18:37 < bridge> [teeworlds] https://en.wikipedia.org/wiki/Apache_Subversion ctrl-f trunk 18:38 < bridge> [teeworlds] eww 18:49 < bridge> [teeworlds] They still use SVN for exams at my uni... 18:50 < bridge> [teeworlds] I hope you are not studying computer science 18:51 < bridge> [teeworlds] 😄 18:53 < bridge> [teeworlds] are there any reasons except historical to prefer svn over git? 18:54 < bridge> [teeworlds] svn can handle bigger files better IIRC 18:54 < bridge> [teeworlds] that's why we use git lfs at work 18:54 < bridge> [teeworlds] so there's one reason I guess, svn supports binary files natively 18:58 < bridge> [teeworlds] I am studying computer engineering.... 18:58 < bridge> [teeworlds] @Learath2 (I only said this because of SVN, not because of you or something 😄 ) 18:58 < bridge> [teeworlds] The class is a joke anyway, "Object Oriented Programming" in Java 18:59 < bridge> [teeworlds] Java was my first language, too, it isn't a bad starter language 18:59 < bridge> [teeworlds] It gives you the awful habit of "OOP everything" 19:00 < bridge> [teeworlds] yes, until you finish your algorithm and datastructures class 19:01 < bridge> [teeworlds] One thing I've really been enjoying is the functional programming capabilities of Java. I like how collections and streams work there 19:01 < bridge> [teeworlds] I enjoy python very much currently, it's just so much less code to write and maintain 19:02 < bridge> [teeworlds] Everytime I give python a chance I want to break my computer in half, so I'm steering clear of it for a while 19:02 < bridge> [teeworlds] xD 19:03 < bridge> [teeworlds] I have no idea how a language that's supposed to be "plug n play"/"granny friendly" has such a god awful import system 19:03 < bridge> [teeworlds] from x.y import z 19:04 < bridge> [teeworlds] that's the pleasant part 19:04 < bridge> [teeworlds] Try a nested project 19:04 < bridge> [teeworlds] you mean the package managing part? that's annoying 19:04 < bridge> [teeworlds] Package managing is also god awful yes 19:05 < bridge> [teeworlds] I have never seen a less capable package manager 19:05 < bridge> [teeworlds] I outsourced package managing to peotry 19:05 < bridge> [teeworlds] *poetry 19:06 < bridge> [teeworlds] https://python-poetry.org/ 19:06 < bridge> [teeworlds] In ddnet's bridge code I generate both the 0.7 and 0.6 protocol. It took a month of research into the stupid import system and I never figured it out 19:07 < bridge> [teeworlds] and for substructures in directories I only needed `__init__.py` 19:08 < bridge> [teeworlds] deen managed to get it working with `-m` but I just ditched the project 19:08 < bridge> [teeworlds] We would have had bridge servers 3 months earlier if we were using any language that's not python to implement the code generation 19:08 < bridge> [teeworlds] I wonder why you generate the netcode on the way, anyway 19:09 < bridge> [teeworlds] it's cute 19:09 < bridge> [teeworlds] and if anything changes in vanilla, I just need to copy a directory over 19:11 < bridge> [teeworlds] Oh and with the source files, I can generate the translation map easily. If I copy the already generated network.h I need to parse C++ with libclang, which is less than fun 19:11 < bridge> [teeworlds] I would have worked more with inheritance, so if you update the netcode you can just create another new child of a netcode parent part and allowing more netcode versions 19:11 < bridge> [teeworlds] The netcode is not 19:11 < bridge> [teeworlds] The netcode is not ready for any extensions 19:12 < bridge> [teeworlds] It'd have been a major rework that way 19:12 < bridge> [teeworlds] yes, which is why we have two active teeworlds versions and bridged servers 19:12 < bridge> [teeworlds] Exactly, it'd be great if we could all work together on getting some QoL in for modding 19:13 < bridge> [teeworlds] `SnapReplaceItem` would help a lot. The extended network protocol would be great. Map extensions would be great. Datafile extensions would also be great 19:14 < bridge> [teeworlds] The extended serverinfo protocol, or just replacing the serverinfo protocol with http 19:14 < bridge> [teeworlds] Or finally a clean `IGameController` that's just an ABC along with a `CGameContext` that's completely gamemode unaware 19:14 < bridge> [teeworlds] neat, Teeworlds amplified dos attacks 🤔 19:15 < bridge> [teeworlds] 0.7 is safe from amplification afaik 19:15 < bridge> [teeworlds] 0.6 does allow some amplified reflection but we ratelimit so it doesn't get out of hand