csgo-osx-linux
csgo-osx-linux copied to clipboard
Server does not reliably animate user commands sent in a batch.
I'm reporting 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 reading :)
I second this, this needs to be fixed asap
Yes please!
This is still not fixed
Server (still) does not reliably invoke animation code.
Issue transferred from https://github.com/ValveSoftware/csgo-osx-linux/issues/1928. @gettysburg posted on 2018-12-14T15:58:38:
This is a follow up of issue #1657.
In a recent update, the server sided if conditional that only allowed animation code to be ran once per server frame and simulation tick was removed - effectively, making the server animate players every single time they are being simulated.
Under packet loss, low fps and other conditions, a client's user commands are buffered and sent off in one large CLC_Move packet, instead of as single packets.
Now, this creates a desync of hitboxes because the server is animating client ticks that won't ever be animated by other clients - clients only receives the latest server simulated data about an entity, and then invoke animation code on it.
The solution to this problem would be to simply only invoke animation code on the server on the final command in any given CLC_Move packet where there's more than 1 user command encoded in it.
Regards.
@kisak-valve
Issue transferred from #1928.
Thanks for migrating, is there any ETA on when this will be patched?
Theoretically, it should be enough to not run any animation code individually during simulation for every player but on every server frame, after all players have been simulated, and before sending updates to clients, so that the server is animating what the client ends up animating.
Fixing this would certainly help to make hit boxes match client side rendered models more, I see many players running around with low fps, lagging visibly, at least as far as interpolation allows me to see - especially on lower ranks, and fixing this would surely help sync animations in those cases.
+1 this is even causing player hitboxes to desync completely from the server when the players jump and land during a choked usercmd. It's ridiculous that this isn't fixed yet. It's not hard to add a simple if statement to see if during CCSGOPlayerAnimState::Update that the command being run is the last/final one in the batch of usercmd's inside void CBasePlayer::PhysicsSimulate( void )
for ( int i = 0; i < commandsToRun; ++i ) { PlayerRunCommand( &vecAvailCommands[ i ], MoveHelperServer() );
This for loop contains the number of commands to run, all you have to do to solve the problem is to store the variable i somewhere, and inside CCSGOPlayerAnimState::Update, check to see if that value is the final command (i == commandsToRun - 1), and if it is not, DO NOT UPDATE animations!
This is still not fixed as of today.
Still not fixed.
The moment it gets fixed you guys will start crying about being unable to cause fake angles anymore 😂
The moment it gets fixed you guys will start crying about being unable to cause fake angles anymore 😂
they want to get it fixed, dummy.
The moment it gets fixed you guys will start crying about being unable to cause fake angles anymore 😂
they want to get it fixed, dummy.
It looks like you misunderstood me, they're asking Valve to fix these animation bugs, but if and when they fix it they'll start crying "hurr durr i cant fake anymore!!!"
Only retards that play hvh/closet cheat 24/7 will start crying about it. Just one less way for cheaters to exploit this game and ruin the experience for people who like to have a clean game without external assistance.
@kisak-valve This issue is so trivial to fix, I'd assume it'd be fixed real soon if you will.
Kind regards.
rip desync meme
Still not fixed. Valve are you going to do something? can't wait to see tournaments where players would abuse this to achieve "god mode".
@kisak-valve Please understand that this issue is game breaking, the longer you wait to fix this issue the more damage it causes.
I'd doubt valve would give a shit. It's been far too long for something to happen imho.
The excuse that it'd worsen the hitreg for legit players is just wrong. The current issue is only annoying to everybody. Legit Players getting CSGO'd since ages, it probably has gotten better after the most recent changes to the animation code (animating to any usercmd send by the client) but still introduces a limited amount of Hitbox Desync.
Either network the important variables from the animstate to the other clients or stop animating on not networked usercmds.
GOTV still cant see the Hitbox (/ Angle) Desync so cheaters will abuse this!
This game is dead.
Still not fixed in May 2020
still not fixed as of august 2020
@kisak-valve @mikela-valve @charleslvalve still not fixed as of 31st August 2020
Still not fixed - 09/15/2022.
theyre not going to fix it stop bumping
@Simplehorror Source 2 will, as well as many other exploits.