CS2D General Why does CS2D rely on client time?
Why does CS2D rely on client time?
10 replies I seen multiple threads about speedhack detection kicking in when system time on the client computer is changed. (for example if the client syncs NTP or time is changed by some means, either manually or via GroupPolicy)
I cannot find any thread where this question is answered:
Why are CS2D caring about CLIENT system time at all?
Shouldn't the server have the final decision of what time it is? Then that type of speedhacks that uses system time changing wouldn't be possible, since the game would follow the "server clock" anyways. When using Lua for time (Check samples) it automatically uses your time. I'm not sure if this is the sole reason, and it probably won't be. But it's the only explanation I have so far as I can't see any other reliance of the clock on CS2D.
Perhaps it has something to do with USGN? But lua scripts are run server-side and shouldn't rely on client time neither? Thus "time" should return the server clock and not the client clock. Well no, it shouldn't. If you're playing on a server which is 3 hours ahead of you and returns their clock that would make no sense. Since changing your time does make the game trigger a "speed hack" state, it would be common to believe that cs2d does indeed grab the time and compare it with it's own clock speed.
If say you were using a program to make it run faster, when it compares it with the clock and realizes that it's clock speed is running way faster than the system clock, then it triggers the speed hack state and your game ends.
The only downside to this is that you aren't able to change your system time, but to be honest I've never touched the clock in my life, dls might affect some people but it hasn't for me yet. I guess DC needs the client time to calculate FPS and eventually stop FPS drops by drawing less.
By modifying the system clock you can modify your FPS and "speedhack" that way. But why would it affect the game?
Isn't the server controlling the player position anyways? Eg the server knows where the player can be based on elapsed time for when it received position packet x-1 and it received position packet x, and the player cannot send a position that is more far away than the server expects the player to be based on normal speed.
Thus speeding up the client code should not have any effect on gameplay.
Same with fire rate. If the player sends a "shoot packet" at time X milliseconds, any shoot packets for Y milliseconds further should then be ignored where Y is (1/(fire rate in rounds per second)) * 1000. Actually cs2d does have that, it's called 
mp_trace, but most servers have it disabled or set very low.
Also cs2d is the game with one of the best lag compensations I know, that's why it can be abused with so much with speed hacking. DC Admin 
Offline
Of course CS2D DOES NOT rely on client time / the system clock of the client. All relevant timings are controlled and checked by the server. Everything else would be a huge vulnerability.
The system clock is only used for client sided speedhack detection and nothing else.
There's also server sided speedhack detection (actually there are multiple different detections and checks) but it's necessary to work with thresholds in order to avoid false positives which are caused by delays, high pings and packet loss. So the client sided protection is an effective addition to the server sided protection. But how are false positives bad if you only correct the behaviour?
For example, lets say the server decides the player moved too long in regards to a specific time.
Take a example: The player moved 100 pixels in direction 60 degrees but based on calculations, the player can only move 50 pixels in direction 60 degrees in that time.
Then you can set the player position to 50 pixels away from last position with direction of 60 degrees on the server, and send the "corrected" position to the client.
Thus, it wouldn't matter if it lagged so the player moved 52 pixels in a time where 50 pixels would be allowed due to lag, since the player wouldn't notice that his position was "corrected" with 2 pixels. Thus thresholds aren't necessary. DC Admin Offline
Players with serious lags and high pings of course do note those position corrections and it makes their movement ugly and laggy. mp_trace works this way and many people with bad pings / connections complained about the bad gaming experience so I was forced to disable it by default. You didn't consider that the corrected position needs time to travel from the server to the client as well. Interpolation etc. is required for the corrected position and it leads to wrong corrected positions whenever the player changes direction while packets are on their way. It really isn't as simple as you described it. It works fine for people with low pings but there are too many players around that think that pings of 200 or higher are still good for playing action shooters... they are not.
mp_antispeeder even kicks players when they are too fast in a certain timeframe. 
1 
