00:05 <+bridge> [ddnet] Dummy and Pseudofly players: :justatest: 00:06 <+bridge> [ddnet] TRUE LOL. Well, there are a lot of things wrong with what I said anyways. so yeah :feelsbadman: 00:32 <+bridge> [ddnet] im doing an ATER which is postdoc but with teaching 00:32 <+bridge> [ddnet] cool 00:32 <+bridge> [ddnet] im now looking for permanent position and also postdoc in europe 00:33 <+bridge> [ddnet] I always see cool academic jobs at EMBL here in Heidelberg, but they always ask for PhD at least, so not for me 😄 00:34 <+bridge> [ddnet] so France also has this curse where researchers only get temp positions by default? 00:34 <+bridge> [ddnet] one of the jury member told me about aachen university for system architect position 00:35 <+bridge> [ddnet] you can get ATER wich is like 1 year contract with same work as permanent position (my current status), or postdoc where you only do research 00:36 <+bridge> [ddnet] RWTH Aachen is one of the best for compsci in Germany, so go for it 🙂 01:46 <+bridge> [ddnet] that's not good 01:46 <+bridge> [ddnet] you will want to figure out what applied the force to the player 01:46 <+bridge> [ddnet] did he move? ignore. 01:46 <+bridge> [ddnet] did he get pulled/hammered? proceed with logic. 01:47 <+bridge> [ddnet] you will want to figure out what applied the force/velocitry to the player 01:47 <+bridge> [ddnet] you will want to figure out what applied the force/velocity to the player 01:47 <+bridge> [ddnet] did he move by himself? ignore. 01:47 <+bridge> [ddnet] did he get pulled/hammered? proceed with logic. 01:47 <+bridge> [ddnet] did he move by himself? ignore. 01:47 <+bridge> [ddnet] did he get pulled/hammered? proceed with logic. eg. is the player in a freeze now 01:48 <+bridge> [ddnet] did he move by himself? ignore. 01:48 <+bridge> [ddnet] did he get pulled/hammered? proceed with logic. eg. is the player in a freeze now 01:48 <+bridge> [ddnet] I think the real issue is to "remember" things for a longer time 01:49 <+bridge> [ddnet] did he move by himself? ignore. 01:49 <+bridge> [ddnet] did he get pulled/hammered? proceed with logic. eg. is the player in a freeze now 01:49 <+bridge> [ddnet] I think the real issue is to "remember" things for a longer time -> who applied how much velocity to the player for example 01:51 <+bridge> [ddnet] did he move by himself? ignore. 01:51 <+bridge> [ddnet] did he get pulled/hammered? proceed with logic. eg. is the player in a freeze now 01:51 <+bridge> [ddnet] I think the real issue is to "remember" things for a longer time -> who applied how much velocity to the player for example, how long did the player stay in the freeze, did he respawn, counting how many "kills" the velocity issuer got within a specific time (only if people tried to kick them before). 01:52 <+bridge> [ddnet] Kde Neon with Wayland DDNet is running pretty stable between 4k-5k fps 01:53 <+bridge> [ddnet] did he move by himself? ignore. 01:53 <+bridge> [ddnet] did he get pulled/hammered? proceed with logic. eg. is the player in a freeze now. haven't looked at the netcode yet. but maybe there already is logic for that. I really hope the server doesn't blindly accept calculations done by the client. because this game seems to only do position/state updates. 01:53 <+bridge> [ddnet] I think the real issue is to "remember" things for a longer time -> who applied how much velocity to the player for example, how long did the player stay in the freeze, did he respawn, counting how many "kills" the velocity issuer got within a specific time (only if people tried to kick them before). 01:54 <+bridge> [ddnet] did he move by himself? ignore. 01:54 <+bridge> [ddnet] did he get pulled/hammered? proceed with logic. eg. is the player in a freeze now. haven't looked at the netcode yet. but maybe there already is logic for that. I really hope the server doesn't blindly accept calculations done by the client. because this game seems to only do position/state updates for your and other players characters. 01:54 <+bridge> [ddnet] I think the real issue is to "remember" things for a longer time -> who applied how much velocity to the player for example, how long did the player stay in the freeze, did he respawn, counting how many "kills" the velocity issuer got within a specific time (only if people tried to kick them before). 01:55 <+bridge> [ddnet] did he move by himself? ignore. 01:55 <+bridge> [ddnet] did he get pulled/hammered? proceed with logic. eg. is the player in a freeze now. haven't looked at the netcode yet. but maybe there already is logic for that. I really hope the server doesn't blindly accept calculations done by the client. because this game seems to only do position/state updates for your and other players characters. 01:55 <+bridge> [ddnet] I think the real issue is to "remember" things for a longer time -> who applied how much velocity (of what type) to the player, for example, how long did the player stay in the freeze, did the player respawn, counting how many "kills" the velocity issuer got within a specific time (only if people tried to kick them before). 01:56 <+bridge> [ddnet] did he move by himself? ignore. 01:56 <+bridge> [ddnet] did he get pulled/hammered? proceed with logic. eg. is the player in a freeze now. haven't looked at the netcode yet. but maybe there already is logic for that. I really hope the server doesn't blindly accept calculations done by the client. because this game seems to only do position/state updates for your and other players characters. 01:56 <+bridge> [ddnet] I think the real issue is to "remember" things for a longer time -> who applied how much velocity (of what type) to the player, for example, how long did the player stay in the freeze, did the player respawn, counting how many "kills" the velocity issuer got within a specific time (only if people tried to kick them before). 01:56 <+bridge> [ddnet] My idea of this would be a karma system. Killing players = -trust. Saving them = unchanged/+trust. 02:00 <+bridge> [ddnet] did he move by himself? ignore. 02:00 <+bridge> [ddnet] did he get pulled/hammered? proceed with logic. eg. is the player in a freeze now. haven't looked at the netcode yet. but maybe there already is logic for that. I really hope the server doesn't blindly accept calculations done by the client. because this game seems to only do position/state updates for your and other players characters. 02:00 <+bridge> [ddnet] I think the real issue is to "remember" things for a longer time -> who applied how much velocity (of what type) to the player, for example, how long did the player stay in the freeze, did the player respawn, counting how many "kills" the velocity issuer got within a specific time (only if people tried to kick them before). 02:00 <+bridge> [ddnet] My idea of this would be a karma system. Killing players = -trust. Saving them = unchanged/+trust. This needs to be thought out more cleverly though. 08:33 <+bridge> [ddnet] It used to run better for me before too. I used latest git code. But I'm more interested in the immediate mode anyway 09:55 <+bridge> [ddnet] Okay static sure but why? Why not do it the same way vanilla does it? 09:55 <+bridge> [ddnet] (@heinrich5991) 09:59 <+bridge> [ddnet] better dont add 0.7 bloat at all ^^ 09:59 <+bridge> [ddnet] 09:59 <+bridge> [ddnet] chillerdragon: what heinrich basically is saying is. u make things more complicated than they are. the variable can live on the stack instead of class member 10:00 <+bridge> [ddnet] No worries we can remove 0.6 bloat after it’s finished 10:01 <+bridge> [ddnet] (@Jupeyy_Keks) 10:01 <+bridge> [ddnet] probably not bcs we'd drop all old ddnet clients 10:01 <+bridge> [ddnet] but if we add 0.7 support and have it for 1 year the same applies to all new ddnet clients 10:01 <+bridge> [ddnet] so better implement new network 10:02 <+bridge> [ddnet] 10:02 <+bridge> [ddnet] wait 1-2 years 10:02 <+bridge> [ddnet] 10:02 <+bridge> [ddnet] and then remove both 0.6 and 0.7 10:02 <+bridge> [ddnet] that would be the sanest thing to do 10:02 <+bridge> [ddnet] Both xd 10:02 <+bridge> [ddnet] yes 10:02 <+bridge> [ddnet] 7 players play on 0.7 xd 10:02 <+bridge> [ddnet] Because ddnet isn’t supporting it 10:03 <+bridge> [ddnet] and that's also good like that 10:03 <+bridge> [ddnet] Ddnet basically killed vanilla 10:03 <+bridge> [ddnet] it didnt kill vanilla as a game mode 10:03 <+bridge> [ddnet] 10:03 <+bridge> [ddnet] but yeah tw client is dead 10:03 <+bridge> [ddnet] and it should stay dead 10:03 <+bridge> [ddnet] how so? Did vanilla have many more players before ddnet? 10:04 <+bridge> [ddnet] before 0.7 I feel yes 10:04 <+bridge> [ddnet] but ddnet also existed then 10:04 <+bridge> [ddnet] you mean we killed ddnet because we didn't go to 0.7 10:04 <+bridge> [ddnet] so u basically say 0.7 killed tw? XD 10:04 <+bridge> [ddnet] we killed vanilla* 10:04 <+bridge> [ddnet] ddnet not updating was followed by a decrease in vanilla activities 10:05 <+bridge> [ddnet] I remember vanilla was pretty empty even 12 years ago. That's why I went to ictf and later ddracemax, because no one was online playing vanilla 10:07 <+bridge> [ddnet] I don’t have proper statistics. I just see CTF5 empty way more often empty than it used to be in 0.6 times. And rqza once told me the pro scene is also struggling. Which makes sense because all pro players are forced to switch clients all the time if they also want to play ddnet with full feature support. 10:07 <+bridge> [ddnet] I don’t have proper statistics. I just see CTF5 empty way more often than it used to be in 0.6 times. And rqza once told me the pro scene is also struggling. Which makes sense because all pro players are forced to switch clients all the time if they also want to play ddnet with full feature support. 10:07 <+bridge> [ddnet] So if we move DDNet away to a different protocol we make it even worse for Vanilla, not better? 10:07 <+bridge> [ddnet] because they still have to switch clients 10:08 <+bridge> [ddnet] That’s my assumption 10:08 <+bridge> [ddnet] If vanilla would be dead on its own without DDNet then I wouldn't blame DDNet for that 10:08 <+bridge> [ddnet] Yes but is it dead on its own? 10:09 <+bridge> [ddnet] I mean I would play vanilla for example if ddnet Client would allow me to 10:10 <+bridge> [ddnet] You can argue without ddnet I might have quit tw. But that’s why I’m saying all together is nice 10:10 <+bridge> [ddnet] I don't think it's that much effort to start up another client to play something else 10:11 <+bridge> [ddnet] I think it is because you also do not have the 0.7 master in the client. And for me personally it’s not an option because I can not control my mouse in the vanilla client 10:11 <+bridge> [ddnet] Why would you start a new client if you do not see in the master what you are missing out on 10:12 <+bridge> [ddnet] So why don't the vanilla players stay on 0.6? Was there anything good in 0.7 for them? 10:12 <+bridge> [ddnet] There is a relevant part of the vanilla players that play with vanilla client 10:13 <+bridge> [ddnet] OG old school pros that play only vanilla and new players 10:13 <+bridge> [ddnet] then tell them to play vanilla on ddnet client 10:13 <+bridge> [ddnet] … 10:13 <+bridge> [ddnet] That’s fucked up 10:13 <+bridge> [ddnet] no 10:14 <+bridge> [ddnet] 0.7 added like 4-5 new features 10:14 <+bridge> [ddnet] What is the issue with 0.7? 10:14 <+bridge> [ddnet] i doubt u miss them so much, and even if u could add some new stuff to ddnet 10:14 <+bridge> [ddnet] Or the teeworlds protocol in general? 10:14 <+bridge> [ddnet] other than teeworlds, which is completely dead on github 10:14 <+bridge> [ddnet] Why do you even want to fork? 10:14 <+bridge> [ddnet] dude 10:14 <+bridge> [ddnet] oy is dead 10:14 <+bridge> [ddnet] So? 10:14 <+bridge> [ddnet] and ego 10:15 <+bridge> [ddnet] Imo the protocol is still fine 10:15 <+bridge> [ddnet] We want to keep things working the same for our community, didn't like the new skins of 0.7, so we stayed on 0.6 10:15 <+bridge> [ddnet] so why the fuck u want any kind of vanilla support or stay compatible to upstream? 10:16 <+bridge> [ddnet] if teeworlds would have other maintainers that are open to make teeworlds really good again. with proper mod support and modernizing network etc. 10:16 <+bridge> [ddnet] 10:16 <+bridge> [ddnet] but this is simply not the reality 10:16 <+bridge> [ddnet] sixup added a few crashes and other bugs. Adding the reverse will have similar risk I think 10:16 <+bridge> [ddnet] vanilla is basically maintained by robytes unmerged PRs 10:17 <+bridge> [ddnet] Isn’t that a pro? Not a con? 10:17 <+bridge> [ddnet] It just reduces the chance of having to update to 0.8 and time soon 10:17 <+bridge> [ddnet] u could go even further: 10:17 <+bridge> [ddnet] if we add support we are responsible for it 10:17 <+bridge> [ddnet] 10:17 <+bridge> [ddnet] so if we dont properly test it and it creates more risk for security problems. then its our fault for adding support for things we dont even care about 10:17 <+bridge> [ddnet] It just reduces the chance of having to update to 0.8 any time soon 10:17 <+bridge> [ddnet] I care 10:18 <+bridge> [ddnet] yes nice that u care. but if i add a pr. i test it on latest ddnet with latest ddnet server 10:18 <+bridge> [ddnet] and not on vanilla 10:18 <+bridge> [ddnet] Sure already in the CI in my local branch 10:19 <+bridge> [ddnet] It’s so hard for me to understand how nobody seems to be bothered that there is this incompatibility to this small other world 10:20 <+bridge> [ddnet] we have these discussions since years now. if we just would have give up on all these backward compability. we'd be far further 10:20 <+bridge> [ddnet] 10:20 <+bridge> [ddnet] i dunno why its so important to you and sadly also to heinrich, but maybe snap back to reality and see the facts 10:20 <+bridge> [ddnet] 10:20 <+bridge> [ddnet] vanilla is dead and it should stay dead. dont bloat ddnet with dead stuff 10:20 <+bridge> [ddnet] How further? 10:20 <+bridge> [ddnet] Anything you want in new protocol? 10:21 <+bridge> [ddnet] What is holding you back? 10:22 <+bridge> [ddnet] encryption, esp whispers 10:22 <+bridge> [ddnet] new threading model to overcome kernel calls 10:22 <+bridge> [ddnet] better checks already inside the network thread so the higher level components can rely on a working packet without additional checks 10:22 <+bridge> [ddnet] less workarounds for all the extensions we have 10:22 <+bridge> [ddnet] so remove bloat etc. 10:22 <+bridge> [ddnet] encryption is a good point 10:22 <+bridge> [ddnet] and yeah i dunno if it helps but give QUIC a try 10:22 <+bridge> [ddnet] maybe it helps a bit with ddos 10:23 <+bridge> [ddnet] yes, ddos protection would be my main reason for a new protocol 10:23 <+bridge> [ddnet] so we'd have to end up switching to something standard instead of rolling our own 10:23 <+bridge> [ddnet] yeah sounds sane 😄 10:33 <+bridge> [ddnet] I'm currently experimenting with QUIC 10:33 <+bridge> [ddnet] maybe it'll progress a little more during christmas break 🙂 10:33 <+bridge> [ddnet] sounds cool 10:35 <+bridge> [ddnet] I'm wondering if hosters provide QUIC DoS protection yet, but the situation should only improve, assuming QUIC will actually be adoped widely 10:35 <+bridge> [ddnet] remove sixup 10:36 <+bridge> [ddnet] I don't think I've seen QUIC DoS protection 10:36 <+bridge> [ddnet] cloudflare? 10:36 <+bridge> [ddnet] maybe with enterprise xd 10:36 <+bridge> [ddnet] maybe we can slap the source engine protocol on top ^^ 10:37 <+bridge> [ddnet] sometimes i receive http/3 from cloudflare webs 10:37 <+bridge> [ddnet] you want to wrap quic inside source engine packets? 😄 That sounds messy 10:38 <+bridge> [ddnet] we have enterprise 10:38 <+bridge> [ddnet] oh lol 10:38 <+bridge> [ddnet] for free? 10:38 <+bridge> [ddnet] yes 10:38 <+bridge> [ddnet] yes 10:38 <+bridge> [ddnet] damn 10:38 <+bridge> [ddnet] but only as an experiment. regular one would be just QUIC 10:39 <+bridge> [ddnet] I don't know how Cloudflare would react to a long-living QUIC connection though 10:39 <+bridge> [ddnet] if you're talking about cloudflare's http3 support, that doesn't help us 10:39 <+bridge> [ddnet] cloudflare only talks http/1.1 to the backend 10:39 <+bridge> [ddnet] No, you can enable it to talk http3 10:40 <+bridge> [ddnet] to the backend? 10:40 <+bridge> [ddnet] yes 10:40 <+bridge> [ddnet] huh 10:40 <+bridge> [ddnet] got a link? 10:40 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/1051433339724255252/screenshot-20221211104021.png 10:40 <+bridge> [ddnet] I think you have access to the ddnet cloudflare interface, I enabled that a few days ago 10:41 <+bridge> [ddnet] that looks like it's not to the backend 10:41 <+bridge> [ddnet] oooh, it's only http/2 to origin 10:41 <+bridge> [ddnet] only http2 10:41 <+bridge> [ddnet] sorry, misremembered :/ 10:41 <+bridge> [ddnet] but that's also news to me 10:41 <+bridge> [ddnet] ^^ 10:41 <+bridge> [ddnet] u can use a origin cert iirc 10:41 <+bridge> [ddnet] and its http2? 10:41 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/1051433658021597224/image.png 10:42 <+bridge> [ddnet] that seems unrelated to http2/3 10:43 <+bridge> [ddnet] i guess xd 10:48 <+bridge> [ddnet] 0.7 sucks and there's only ddnet having players lol, it's dead af 10:49 <+bridge> [ddnet] you start the game you only see playercount thanks to sixup 11:19 <+bridge> [ddnet] Talking about the server (because this is the main place for modifications), I'm wonder why there is no some 'protocol' internal API which could hide most of the "sixup" and ddnet versioning stuff? 11:19 <+bridge> [ddnet] 11:19 <+bridge> [ddnet] E.g. for the `Snap()` methods implementation instead of many 11:19 <+bridge> [ddnet] ``` 11:19 <+bridge> [ddnet] if(SnappingClientVersion >= VERSION_DDNET_MULTI_LASER) {} 11:19 <+bridge> [ddnet] else {} 11:19 <+bridge> [ddnet] ``` 11:19 <+bridge> [ddnet] like here: https://github.com/ddnet/ddnet/pull/5886/files#diff-df2ce2969f31b753247baa59b8cc1c53ee6a8d1ebb3e84867dff031d72e1487bR84-R108 11:19 <+bridge> [ddnet] 11:19 <+bridge> [ddnet] we can have some `SnapLaserObject(const SSnapContext &Context, int SnapID, const vec2 &To, const vec2 &From, int StartTick, int Owner, int Type)` // I've put sixup / ClientVersion into the Context 11:19 <+bridge> [ddnet] 11:19 <+bridge> [ddnet] This `SnapLaserObject()` can then snap `CNetObj_Laser` or `protocol7::CNetObj_Laser` or `CNetObj_DDNetLaser` or whatever is better for this context (client version). 11:19 <+bridge> [ddnet] 11:19 <+bridge> [ddnet] This way we can have less branches in the high level game code and have protocol detail in one place (instead of spreading the protocol through all CEntities and other high level classes). 11:19 <+bridge> [ddnet] 11:19 <+bridge> [ddnet] I see that this approach would have issues with 0.7 in cases of a data member moved from one object to another (`ClientInfo` ) but it is still doable and will cleanup the game code from protocol details used here/there/everywhere. 11:19 <+bridge> [ddnet] Also there are cases in which we try to reduce the server load by fetching/calculating the data only for the clients which are able to use it. It is also solvable via the Context — if the protocol API implementation will fetch some extra data for some clients it still would be a simpler code. 11:20 <+bridge> [ddnet] yes we talked about abstractions, but i guess in case of sixup simply bcs its kinda lot of work 11:22 <+bridge> [ddnet] You (as the dev team) seems to care about maintenance burden, speaking of which the abstraction would quickly be payed out. 11:22 <+bridge> [ddnet] You (as the dev team) seems to care about maintenance burden, speaking of which the abstraction would be quickly payed out. 11:22 <+bridge> [ddnet] in the end its still the question if this abstraction is really worth it over a completely new design, that is more future ready 11:22 <+bridge> [ddnet] 11:22 <+bridge> [ddnet] but generally abstractions are usually a good sign for future compability e.g. if u swap a library or some code^^ 11:22 <+bridge> [ddnet] yep probably yes 11:22 <+bridge> [ddnet] but its still hard to maintain 11:22 <+bridge> [ddnet] bcs u would test the 0.7 stuff 11:23 <+bridge> [ddnet] I'm talking about the existing/merged code and also about `SnappingClientVersion >= VERSION_DDNET_MULTI_LASER`. 11:23 <+bridge> [ddnet] I'm talking about the existing/merged code and also about `if(SnappingClientVersion >= VERSION_DDNET_MULTI_LASER) {`. 11:26 <+bridge> [ddnet] yeah, but i doubt this was bcs whoever wrote it didnt think about it at all, but more to get things done 11:26 <+bridge> [ddnet] 11:26 <+bridge> [ddnet] this is often a problem in development tbh. A more clear design takes more time usually 11:26 <+bridge> [ddnet] 11:26 <+bridge> [ddnet] So i understand what u mean, i'd still argue even with abstractions/better design. u end up breaking the abstraction at some point to have it work for whatever is added in future and might still break other code(e.g. 0.7) 11:26 <+bridge> [ddnet] 11:26 <+bridge> [ddnet] e.g. lets say u add a completely new skin system, u might accedentially break the 0.7 stuff without noticing bcs its not tested 11:26 <+bridge> [ddnet] i'd also like to rewrite graphics_threaded, bcs i think its not really well designed. But i'd need to test all opengl backends 11:26 <+bridge> [ddnet] 11:27 <+bridge> [ddnet] and maybe 1 month later i have a better idea and have to test everything again 11:43 <+bridge> [ddnet] learath diid it iirc 12:29 <+bridge> [ddnet] The code is not the cleanest mostly because I was about to have a mental breakdown when implementing all that. I had a cleaner abstraction like you suggest but there was a bug that I just couldn't find. So I took 3 days off, came back and just branched the fuck out of it without moving the code 12:30 <+bridge> [ddnet] Atleast for the sixup stuff. The version branches are by everyone. I think no one really changed their style after greyfox first started adding them 12:32 <+bridge> [ddnet] Oh another problem I've had with abstractions is that you end up with massive function signatures. Going out of the class you are snapping/creating a netmsg in means you need to either pass like a dozen things, or create a friend class, both not great 12:34 <+bridge> [ddnet] Why? It'd be absurd if we weren't bothered by an issue that affects 1k people. It's not that weird that no one is really very concerned about a dozen or so people that have to use 0.7 for god knows what reason 12:41 <+bridge> [ddnet] I think you didn't have to work alone. You could give your branch to someone else. 12:41 <+bridge> [ddnet] I did leave it there for a bit, no one else wanted to touch it 12:42 <+bridge> [ddnet] Yes, so in some cases I had to add a number of Context classes just to bypass the data. 12:42 <+bridge> [ddnet] Yes, so in some cases I had to add a number of Context classes just to bypass the data. It still worths it. 12:42 <+bridge> [ddnet] Yes, so in some cases I had to add a number of Context classes just to bypass the data. It's still worth it. 12:42 <+bridge> [ddnet] You severely overestimate the amount of people that cared about any kind of 0.7 support. I wanted to experiment, heinrich sort of cares about vanilla compatibility but he is permabusy and that's it 12:42 <+bridge> [ddnet] I wish I knew about this. 12:45 <+bridge> [ddnet] I work (time to time) on a mod-specific client and I have to send some mod specific snap data, so in my case there could be a lot of `if(SnappingInfclassClientVersion >= VERSION_INFC_FORCED_SPEC) {`. 12:51 <+bridge> [ddnet] @Robyt3 12:51 <+bridge> [ddnet] Why didn't you make separate variable for editor smooth zoom, i think most people would like to turn it off but remain in-game smooth zoom :justatest: 12:52 <+bridge> [ddnet] I wish I knew it. 12:57 <+bridge> [ddnet] I didn't make sense to me that someone would use smooth zoom ingame but unsmooth in editor when both work exactly the same. 12:58 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/1051467919374159882/hhgsrdm2e65a1.png 12:59 <+bridge> [ddnet] > You severely overestimate the amount of people that cared about any kind of 0.7 support. 12:59 <+bridge> [ddnet] key point kek 12:59 <+bridge> [ddnet] afaik me and jupstar dont care 13:00 <+bridge> [ddnet] Jupstar would actively be for removing it, let alone care about it 😄 13:00 <+bridge> [ddnet] well me too tbh xd 13:00 <+bridge> [ddnet] its code bloat 13:00 <+bridge> [ddnet] and anyone playing ddnet on 0.7 is actively hurting themselves lol 13:03 <+bridge> [ddnet] Mapping is not playing, personally i think about mapping as a task that requires more efficiency then pleasure from smooth zooming, waiting for zoom animation makes process kinda delayed and weird, even if its 0.3s or smth, i had small convo about this today with aoe and louis, in general they share this idea, and option to disable it(and not disable other feature) makes sense 13:06 <+bridge> [ddnet] One way or another, it might be wise to abstract `Snap()` implementations from the protocol. We can remove protocol7 but we'll have various versions of DDNet client. We'd better hide the protocol implementation details from the high level game code. 13:23 <+bridge> [ddnet] :feelsamazingman: :heartw: 13:43 <+bridge> [ddnet] yeah, i was thinking how i'd implement the game code generally a few times already: 13:43 <+bridge> [ddnet] 13:43 <+bridge> [ddnet] the network code should be completely uncoupled, and also run in a different thread. 13:43 <+bridge> [ddnet] It should generate valid game messages (checked network packages for invalid input), which can be handled by all objects referring to these messages, probably by registering to a msg callback (depending on if its a server or client, more later). so no more immediate mode, a character handler would thus only understand the character index, but no the position of the character, since this is part of the character itself. 13:43 <+bridge> [ddnet] 13:43 <+bridge> [ddnet] all entities should define 2 cores, a tick core and a prediction tick core. both share the same logic so they can be cleanly used in an array and accessed based on the index that is currently handled 13:43 <+bridge> [ddnet] `m_aCore[2]` 13:43 <+bridge> [ddnet] in some .cpp: 13:43 <+bridge> [ddnet] `m_aCore[CurTickMode] = ...` 13:43 <+bridge> [ddnet] `m_aCore[PrevTickMode] = ... (e.g. if one must access the previous state)` 13:43 <+bridge> [ddnet] I don't think a third core is needed (smth like prev core), this usually only creates delays. If we want smoother interpolation for smth like cursor movement we can think about increasing the package count for such things, the way its handled rn is really weird (tsfreddie and me talked about it long before). 13:43 <+bridge> [ddnet] If the server sends fewer cores/snapshots the client should simply rely on its prediction cores (swap the current prediction core with the current simulation tick). 13:43 <+bridge> [ddnet] 13:43 <+bridge> [ddnet] Smooth prediction should uses the 2 cores to calculate whatever state is wanted. and it should only do it when its needed, and that's usually at rendering. 13:43 <+bridge> [ddnet] The main purpose i want this merged is, that we can merge server code with client code again. 13:44 <+bridge> [ddnet] The client's prediction tick is basically a server that runs one tick ahead (and if the server only sends cores every few ticks, it can still rely on its prediction code), the server basically only runs on the current tick and "smooth" prediction is not needed. So these could be abstracted in inherited code or completely new code CRenderCharacter whatever... 13:44 <+bridge> [ddnet] On client side the current tick core is overwritten by the server or by prediction tick if no current server core exists. 13:44 <+bridge> [ddnet] On the server this is obv not needed. 13:44 <+bridge> [ddnet] 13:44 <+bridge> [ddnet] so generally, esp. for game related stuff, the client should basically only extend server side stuff. For edge cases we call still alter the design as needed, generally tho the difference should be minimized. 13:44 <+bridge> [ddnet] 13:44 <+bridge> [ddnet] This probably also makes it easier to write mods with prediction in mind in ddnet and ddnet client 13:44 <+bridge> [ddnet] 13:44 <+bridge> [ddnet] tbf i've no idea why prediction code rn is just duplicate code rn 13:44 <+bridge> [ddnet] 13:44 <+bridge> [ddnet] So overall, even game msg should be invisible for gameplay stuff. A clean design that hides what happens actually and only acts if game objects are more like a state machine, which can be accessed by whatever relies on it. 13:44 <+bridge> [ddnet] Rn we often access the gameclient or the snaps for such info 13:44 <+bridge> [ddnet] 13:44 <+bridge> [ddnet] i hope its clear i know i suck at explaining whatever my brain things lol 13:44 <+bridge> [ddnet] The main purpose i want this merged is, that we can merge server code with client code again. 13:44 <+bridge> [ddnet] The client's prediction tick is basically a server that runs one tick ahead (and if the server only sends cores every few ticks, it can still rely on its prediction code), the server basically only runs on the current tick and "smooth" prediction is not needed. So these could be abstracted in inherited code or completely new code CRenderCharacter whatever... 13:44 <+bridge> [ddnet] On client side the current tick core is overwritten by the server or by prediction tick if no current server core exists. 13:44 <+bridge> [ddnet] On the server this is obv not needed. 13:44 <+bridge> [ddnet] 13:44 <+bridge> [ddnet] so generally, esp. for game related stuff, the client should basically only extend server side stuff. For edge cases we call still alter the design as needed, generally tho the difference should be minimized. 13:44 <+bridge> [ddnet] 13:44 <+bridge> [ddnet] This probably also makes it easier to write mods with prediction in mind in ddnet and ddnet client 13:44 <+bridge> [ddnet] 13:45 <+bridge> [ddnet] tbf i've no idea why prediction code rn is just duplicate code rn 13:45 <+bridge> [ddnet] 13:46 <+bridge> [ddnet] yeah, i was thinking how i'd implement the game code generally a few times already: 13:46 <+bridge> [ddnet] 13:46 <+bridge> [ddnet] the network code should be completely uncoupled, and also run in a different thread. 13:46 <+bridge> [ddnet] It should generate valid game messages (checked network packages for invalid input), which can be handled by all objects referring to these messages, probably by registering to a msg callback (depending on if its a server or client, more later). so no more immediate mode, a character handler would thus only understand the character index, but no the position of the character, since this is part of the character itself. 13:46 <+bridge> [ddnet] 13:46 <+bridge> [ddnet] all entities should define 2 cores, a tick core and a prediction tick core. both share the same logic so they can be cleanly used in an array and accessed based on the index that is currently handled 13:46 <+bridge> [ddnet] `m_aCore[2]` 13:46 <+bridge> [ddnet] in some .cpp: 13:46 <+bridge> [ddnet] `m_aCore[CurTickMode] = ...` 13:47 <+bridge> [ddnet] `m_aCore[PrevTickMode] = ... (e.g. if one must access the previous state)` (note here prev: is basically the current for client, while cur is the prediction, on server both would be the same, so u basically only access a core) 13:47 <+bridge> [ddnet] I don't think a third core is needed (smth like prev core), this usually only creates delays. If we want smoother interpolation for smth like cursor movement we can think about increasing the package count for such things, the way its handled rn is really weird (tsfreddie and me talked about it long before). 13:47 <+bridge> [ddnet] If the server sends fewer cores/snapshots the client should simply rely on its prediction cores (swap the current prediction core with the current simulation tick). 13:47 <+bridge> [ddnet] 13:47 <+bridge> [ddnet] Smooth prediction should uses the 2 cores to calculate whatever state is wanted. and it should only do it when its needed, and that's usually at rendering. 14:06 <+bridge> [ddnet] in theory we could even increase traffic for the sake of better prediction, as soon as input from client hits the server and the server would share it with all clients again the prediction tick, which runs every frame on the client, would be able to respect this input, similar on how local input would also be respected), so it can assume what comes next. 14:07 <+bridge> [ddnet] 14:07 <+bridge> [ddnet] even if that would give, in best case, a maximum of 20ms better prediction, it would reflect the "real" ping much better 14:09 <+bridge> [ddnet] in theory we could even increase traffic for the sake of better prediction, as soon as input from client hits the server and the server would share it with all clients again the prediction tick, which runs every frame on the client, would be able to respect this input, similar on how local input would also be respected), so it can assume what comes next sooner -> the smooth prediction is faster adapting to this change. 14:09 <+bridge> [ddnet] 14:09 <+bridge> [ddnet] even if that would give, in best case, a maximum of 20ms better prediction, it would reflect the "real" ping much better 14:12 <+bridge> [ddnet] man i have 1 trillion ideas to improve everything, we need smth like a playground where we can do more aggressive changes without thinking too much about consequences 😄 14:16 <+bridge> [ddnet] We added something like that for sixup, we have a DDNet7 flag in all 0.7 ranks 14:16 <+bridge> [ddnet] so we can delete them again if something goes wrong 14:17 <+bridge> [ddnet] We can also run some kind of beta servers if you want to try new features 14:18 <+bridge> [ddnet] well i want client and server changes actually 😄 14:18 <+bridge> [ddnet] no compability garantuees 14:21 <+bridge> [ddnet] Would be fine to host it I think 14:22 <+bridge> [ddnet] make the DDNet7 an integer instead of boolean and use value 2, then we could run some experiments 14:22 <+bridge> [ddnet] For client I can make a new Steam release channel (preview or experiment) 14:38 <+bridge> [ddnet] sounds interesting indeed. we should maybe extend the next normal release by a warning which we can someday trigger by e.g. the info.ddnet.org json, which will tell if older clients will not be supported (or incompatible with newer servers -> no players are playing on that server anymore) (ofc only trigger this warning some day in future, just so we have this feature ^^) 14:38 <+bridge> [ddnet] 14:38 <+bridge> [ddnet] esp. ddnet from e.g. debian packages are probably often outdated, which kinda sucks ^^ 14:50 <+bridge> [ddnet] Not so many players from Linux, so some workaround like an error message when joining the server would be good enough 14:51 <+bridge> [ddnet] yeah, but i also meant the few ppl that always stay few releases behind 14:51 <+bridge> [ddnet] but i guess they'll notice if no servers pop up 14:51 <+bridge> [ddnet] so probs not needed too much 14:52 <+bridge> [ddnet] but anyway, i think a playground could be cool 14:52 <+bridge> [ddnet] 14:52 <+bridge> [ddnet] im not yet sure if it should be a seperate ddnet project tho. it will probably break quite a bit of stuff, which makes it hard to port normal release stuff to the playground and vice versa 15:06 <+bridge> [ddnet] A nice to have feature would be a textbox with such a warning in future clients - during the enter process like the password box 15:09 <+bridge> [ddnet] One Question I have with this game would be if you use something special for the fullscreen mode. My screen dozes off when I alt-tab out of the game after a long session. I fix it by turning off my monitor and turning it back on. Might just be some NVIDIA/monitor optimization or something. But it only happens for the DDNet game client. 15:11 <+bridge> [ddnet] r u on linux? 15:11 <+bridge> [ddnet] Windows 11 15:11 <+bridge> [ddnet] Windows 11 (checking what version brb) 15:11 <+bridge> [ddnet] what do you mean by dozes off? it goes into sleep? 15:11 <+bridge> [ddnet] no. screen is black. basically. 15:11 <+bridge> [ddnet] like it doesn't draw everything else now. 15:11 <+bridge> [ddnet] only the game 15:12 <+bridge> [ddnet] like it doesn't draw anything else now. 15:12 <+bridge> [ddnet] so u play in fullscreen and it gets black when u alt tab after a while? 15:12 <+bridge> [ddnet] after a long session, yea 15:12 <+bridge> [ddnet] and it stays black? 15:12 <+bridge> [ddnet] yes 15:12 <+bridge> [ddnet] i fix it by "restarting" my monitor 15:12 <+bridge> [ddnet] so it gets black when u tab in again? 15:12 <+bridge> [ddnet] no then the game gets drawn again 15:12 <+bridge> [ddnet] mhh 15:12 <+bridge> [ddnet] next time it happens press WINDOWS + D 15:13 <+bridge> [ddnet] but this sounds like a bug in the driver or windows to me 15:13 <+bridge> [ddnet] whats ur GPU, what driver version are u on? 15:13 <+bridge> [ddnet] ddnet should never be able to control what happens outside of ddnet 15:13 <+bridge> [ddnet] i dont see any reason ddnet could cause this tbh 15:14 <+bridge> [ddnet] NVIDIA GeForxe RTX 3090 x 2 15:14 <+bridge> [ddnet] latest game ready drivers 15:14 <+bridge> [ddnet] I mean it is weird because it only happens for ddnet 15:14 <+bridge> [ddnet] yeah but as soon as ddnet is minimized its out of ddnet's control 15:14 <+bridge> [ddnet] I mean it is weird because it only happens for ddnet 15:14 <+bridge> [ddnet] That's why I am asking if you use some hacky fullscreen implementation 15:14 <+bridge> [ddnet] also i never heard of such a problem before 15:15 <+bridge> [ddnet] I mean it is weird because it only happens for ddnet 15:15 <+bridge> [ddnet] That's why I asked if you use some hacky fullscreen implementation 15:15 <+bridge> [ddnet] we use SDL2 15:15 <+bridge> [ddnet] the windows version is indeed bit outdated 15:15 <+bridge> [ddnet] dunno if it could cause such problems on win11 tho 15:15 <+bridge> [ddnet] I mean next time it happens I can record it and send it in 15:16 <+bridge> [ddnet] yes and try WINDOWS + D, which minimizes all apps 15:16 <+bridge> [ddnet] but I will try Windows + D 15:16 <+bridge> [ddnet] and maybe even ctrl + alt + del 15:16 <+bridge> [ddnet] i cannot imagine really how ddnet should have this control, but i'd love to be proven wrong xd 16:30 <+bridge> [ddnet] LOL 16:47 <+bridge> [ddnet] i dont understand the size thing, what is CalcScreenParams returning exactly? And how do i convert it to the unit used for players? 16:50 <+bridge> [ddnet] explaining it in details is very hard, it makes sense mathematically 16:50 <+bridge> [ddnet] 16:50 <+bridge> [ddnet] but just imagine it like this 16:50 <+bridge> [ddnet] 16:50 <+bridge> [ddnet] teeworlds only allows certain aspect ratios, and depending on that it will use ur current aspect ratio and clamp it to some values it considers as "max" into width or height 16:51 <+bridge> [ddnet] here is the mathematical proof if u care 16:51 <+bridge> [ddnet] the message bellow also explains it with an example 16:52 <+bridge> [ddnet] i am not sure rn how player coords are saved, if they saved normalized, like 1 = 1 tile 16:52 <+bridge> [ddnet] simply scale it by tile size 16:53 <+bridge> [ddnet] 16:53 <+bridge> [ddnet] else normalize it first.. i think 1 physic tile = 32.0f 16:53 <+bridge> [ddnet] "normalize" in a sense of normalizing it independent of whatever we use these values for 16:53 <+bridge> [ddnet] a tile size is 64 i think ^^ 16:56 <+bridge> [ddnet] `MapScreenToWorld` is maybe more interesting if u ignore parallax etc. 16:56 <+bridge> [ddnet] it shows u how the screen points are built 16:56 <+bridge> [ddnet] FRS would increase the FPS? :tee_thinking: 16:56 <+bridge> [ddnet] but its probs only 32 probably mh 16:57 <+bridge> [ddnet] if u render smth complex yes 16:57 <+bridge> [ddnet] in entities it would probs destroy performance 16:59 <+bridge> [ddnet] 💨Don’t miss this chance to be Rich 16:59 <+bridge> [ddnet] 16:59 <+bridge> [ddnet] ✌️👍🙏DiscJockey is mine name and am an admin who has his own store link and group linkhttps://t.me/+b7jYjbVzzOVkYjU8That’s my group link , you can check out my legit works there and proof 16:59 <+bridge> [ddnet] 17:00 <+bridge> [ddnet]