When it comes to the build system I don't care about a few seconds. Nowadays cmake has pretty good integration in other tools, which makes development more convenient.
15:53
In addition, the recognition of the required tools (compiler, python, ...) and libs caused less problems for me than with bam.
15:55
Dune: one color is fine I think. Which one would you prefer?
while I don't back the idea, you are pretty much forced to use dynamic cam in some gametypes. with the current size of monitors, it's just some absurd artificial constraint that we put on players to be able to handle a vomit-inducing camera imo
16:01
it's not like teeworlds devs thought "oh yeah and it'd be really fun if there was a moving camera that you have to deal with", screens were just too small to let you zoom out properly back then
16:02
the "if you don't like it don't use it" argument doesn't hold for gametypes where dyncam is such a massive advantage you just have to use it
16:03
@Sonix if you're done with the clocks, would you post them (on github or else)? :)
I mean either ReiTW or Learath proposed the idea of having customly rendered entities, which can be anything like text or clocks, so I was just thinking that race might make use of that idea maybe, as it's rather cool to have such a feature.
This is a big thing... You can do it the hacky way and just add a few basic things, quickly notice that it's too limited and add further stuff. Result would be ugly code, compatibility issues, ...
dyn cam is super annyoning, especially if one does not use it. one should be enforced, either full dyn or full static. both are incompatible imo, and it sucks to be playing against dyn/dyn toggle with full static, as they use both the advantages of full static and the advantages of dyn.
The whole thing could also be extended in the future. For now it's important to have the new stuff in the protocol. It can also be used for auto demo recording and the old ghosts from 0.6 :)
16:28
Most stuff is still from the client pack :D -> credits to sushi
I would like to see support for freeze. That is for example used in DDRace and in zCatch (Anticamper). The tee can not move meanwhile. Currently they use the ninja skin for that.
It's a bit annoying that the protocol is so restrictive in 0.7. when it contains unknown flags it will drop the packet/snapshot. 0.6 just filtered it out
Well there was some ddnet version for the web. Playing the game in a browser is not the best idea due to missing udp... But a demo player would be cool. No clue how hard it would be to compile tw to webassembly though. I guess the threaded rendering with legacy opengl might be a problem
Rewriting it in js would be a lot of work. You'd have to implement all the snapshot, delta and compression stuff in js. Probably easier to use the existing code
<-- + --> I'm very busy nowadays