00:24 < bridge_> [teeworlds] <jxsl13> custom rendered clocks :'(
00:29 < bridge_> [teeworlds] <jxsl13> :( gotta learn go and or rust, would not need to choose a build system.
15:57 < bridge_> [teeworlds] <jxsl13> *opens PR: remove dyn cam from game*
16:52 < redix> 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. 
16:53 < redix> In addition, the recognition of the required tools (compiler, python, ...) and libs caused less problems for me than with bam.
16:55 < redix> Dune: one color is fine I think. Which one would you prefer?
16:56 < redix> jxsl13: what's wrong with the clocks? :D
16:59 < Dune> redix: I mean, it depends on where you want to use them
16:59 < redix> I still don't get the problem with dyn cam. Some people can handle it... Others can't ^^
16:59 < Dune> if you plan to use them on the UI, like on the server info of race servers or ingame server info tab etc.
17:00 < redix> Only thought about the ingame timer =\
17:00 < Dune> 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
17:01 < Dune> 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
17:02 < Dune> 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
17:03 < Dune> @Sonix if you're done with the clocks, would you post them (on github or else)? :)
17:06 < bridge_> [teeworlds] <jxsl13> 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.
17:06 < Dune> that's an entirely different issue
17:08 < bridge_> [teeworlds] <jxsl13> Incorporate the issue with other issues in order to make it valuable in vanilla and not only in mods 😮
17:08 < bridge_> [teeworlds] <jxsl13> or for mods*
17:09 < redix> 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, ... 
17:10 < Dune> ^
17:10 < bridge_> [teeworlds] <jxsl13> 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.
17:10 < redix> The proper way would be to design a mod API and release a new major version
17:11 < bridge_> [teeworlds] <jxsl13> also I didn't say to do it quickly, I just thought about where it might be useful.
17:11 < bridge_> [teeworlds] <jxsl13> as there seems to be a lot secret stuff to be going on in the background at the moment
17:11 < bridge_> [teeworlds] <jxsl13> *pshh, tell me what's going on, pshh end*
17:12 < Dune> redix: yeah
17:13 < Dune> all teeworlds development is public. the only "background" thing I guess is skins
17:13 < bridge_> [teeworlds] <jxsl13> map editor?
17:13 < redix> In my opinion this needs 0.8. otherwise we'll always see "update to ...", "Use ... client" in the broadcast
17:13 < Dune> well yeah
17:13 < Dune> the latter might be preferrable though
17:14 < redix> Or at least one client that supports a full API :D
17:14 < bridge_> [teeworlds] <jxsl13> what are you working on, Dune Oo?
17:14 < Dune> that could be done through a modified client at first :)
17:14 < Dune> @jxsl13 my job? :)
17:14 < bridge_> [teeworlds] <jxsl13> no, I mean tw-wise x), can also tell me about work 😄
17:15 < Dune> nothing much, I'm very busy nowadays
17:15 < redix> Would definitely be good to have one full implementation... And not countless of incompatible and buggy clients
17:15 < bridge_> [teeworlds] <jxsl13> *cough vanilla, cough end :D*
17:15 < Dune> redix: yeah :)  something that is so modular that it can be merged easily in other modified clients and servers
17:16 < redix> +1
17:16 < bridge_> [teeworlds] <jxsl13> *.* a dream to never come true
17:16 < Dune> you never know ;)
17:17 < bridge_> [teeworlds] <jxsl13> 😉 <--  + -->  I'm very busy nowadays
17:17 < bridge_> [teeworlds] <jxsl13> *sherlock*
17:17 < bridge_> [teeworlds] <jxsl13> `;)` <-- + --> ...
17:18 < Dune> redix: got plans for xmas? :D
17:18 < redix> Not much ^^
17:18 < Dune> so you'd stick with the one clock in the broadcast?
17:20 < redix> I just didn't think about other places where it could be used :D
17:20 < Dune> do you want to put it in more places now?
17:23 < redix> Not sure yet. Will check where it might fit later :D
17:24 < Dune> thanks for the race stuff btw. It's nice and clean :)
17:27 < redix> 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 :)
17:28 < redix> Most stuff is still from the client pack :D -> credits to sushi
17:30 < Dune> btw https://github.com/teeworlds/teeworlds/issues/2173#issuecomment-508823471
17:30 < Dune> not sure if ddnet uses something
17:35 < redix> What about just adding a player flag for it that at least blocks the input?
17:36 < redix> Not sure how ddnet handles this but they still use the Ninja skin for it
17:38 < Dune> not sure if that achieves much if you cannot rely on it to display something to the client
17:38 < redix> 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
17:46 < Dune> oh really
17:50 < redix> You must not send the race gameflag to old clients for example. Otherwise the client will drop the whole gamestate snap item =\
17:53 < Dune> it's not that bad considering the client sends the game version 
17:56 < redix> True. But playing demos with old clients will look a bit strange :D
18:03 < rand> need a independant, yet full version, demo player :3
18:04 < rand> with a javascript version in order to play in web browser
18:04 < rand> and the moon
18:10 < redix> 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
18:10 < Dune> not sure, debugging is a bitch too
18:10 < Dune> probably easier to convert demos to videos
18:12 < redix> 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
18:12 < redix> Yeah videos are definitely the easiest thing
18:14 < Dune> webassembly is cool for well-contained scripting though :)
18:23 < Dune> if only teeworlds had some hooks to some UI/game functions ;)
18:24 < redix> ^^