There is, currently (and has been for a long time, but that is another story), a bug that will lead to client / server hitboxes to become desynchronized from each other in certain situations.
It can also be exploited by malicious clients to deliberately de-sync hitboxes, in a way that is undetectable in demos and while spectating - the bug happens because of how, in certain conditions, client holds back movements commands (CUserCmds) for transmission at a later time - and how the server animates said "batched" user commands, all in a single frame. By default, it basically works like this on client: 1.) On every frame, engine determines how many movement commands to create, based on how long it took to process last frame. 2.) If your frame rate drops below tickrate, engine will create additional movement commands per frame to keep up with tickrate. 3.) If there's more than one movement command to be created on any given frame, the engine will delay networking of created commands until the final one has been created. Now on server upon of arrival of CLC_Move message: 1.) Server parses all movement commands contained in CLC_Move packet, and runs simulation for each packet, in the order they were created on client. 2.) During simulation, players are simulated based on their inputs sent with their movement command, i.e. buttons pressed, etc. 3.) During simulation, server will also update server side animations used by hit registration. *The problem is that animation code only runs once per frame - if multiple movement commands are queued for execution in a single frame, only the first one passed in to be animated will be processed, later ones will be ignored due to server still being in the same frame.* Fixing this would be as easy as only animating during simulation of the final, most recent command out of a batch sent in by a client. Only the last command out of a CLC_Move packet simulated by the server will be broadcasted to players, other commands are of no use to animation and hit registration, clients don't get to render them and there is no lag compensation record created on those. Here is a video that show this bug in action by a *malicious client*, however due to how the engine works, players on bad connections or with bad computers can trigger this bug too, and thus desync animations. https://www.youtube.com/watch?v=hL3gxRv_5Jk This video, also demonstrates a community made fix, which fixes this issue, it's code can be found here - credits go to my friend Dylan: https://github.com/click4dylan/CSGO_FakeAngleFix Thank you for your attention.
_______________________________________________ Csgo_servers mailing list [email protected] https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
