as far as save goes you can do /save <password> and /load <password>, doensn't have to be the same team # to load a save but the tees need to have the same name. You can save, swap names, and load if you want to swap while /swap is disabled(edited)
Why is the position server authoritative? Why not use client authoritative?
Yes it means cheats are more effecive, but it means that we dont lagg around the map cos we lost a single packet(edited)
Sk3tch12E
Why is the position server authoritative? Why not use client authoritative?
Yes it means cheats are more effecive, but it means that we dont lagg around the map cos we lost a single packet (edited)
i think what you're describing is a model where the client sends some state processing to the server, and the server works out what the best position is based on previous frames + what other clients are describing. unfortunately, since the client is open-source, anyone could write their own state handling code and bias the server to alter game physics and that's something that's extremely sensitive in the community and prone to exploitation
unfortunately, since the client is open-source, anyone could write their own state handling code and bias the server to alter game physics and that's something that's extremely sensitive in the community and prone to exploitation
unfortunately, since the client is open-source, anyone could write their own state handling code and bias the server to alter game physics and that's something that's extremely sensitive in the community and prone to exploitation
Already seen it lol
my point is more along the lines of why does it matter so much? At least in kong and ddnet. Cheaters can be caught and weeded out from leader boards
lynn
well i guess since there's no auth you could still reverse-engineer the protocol for client-server layer code, so yes you're right lol
i think the only way you could make antiping more effective is to consider client frames as a source of truth for the server, which as i said before, custom clients could fuck with so much xd
23:08
but it's not a bad idea really it's just very hard to execute
23:08
and being an open-source game it's even easier to figure out how to exploit it
23:09
im not sure if there is a facility like the buffer shown in that talk in ddnet, or if everything is client-side
23:10
or if inputs are compressed based on the fact that human players are normally pressing the same inputs after frames with new input