csgo-osx-linux icon indicating copy to clipboard operation
csgo-osx-linux copied to clipboard

Server does not reliably animate user commands sent in a batch.

Open gettysburg opened this issue 6 years ago • 22 comments

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 :)

gettysburg avatar May 08 '18 20:05 gettysburg

I second this, this needs to be fixed asap

click4dylan avatar May 08 '18 20:05 click4dylan

Yes please!

Sikarii avatar Jun 14 '18 19:06 Sikarii

This is still not fixed

click4dylan avatar Jul 09 '18 00:07 click4dylan

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 avatar Dec 14 '18 16:12 kisak-valve

@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.

gettysburg avatar Dec 21 '18 23:12 gettysburg

+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!

click4dylan avatar Dec 21 '18 23:12 click4dylan

This is still not fixed as of today.

gettysburg avatar Mar 18 '19 18:03 gettysburg

Still not fixed.

L3D451R7 avatar Apr 18 '19 08:04 L3D451R7

The moment it gets fixed you guys will start crying about being unable to cause fake angles anymore 😂

rundacode avatar Apr 18 '19 10:04 rundacode

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.

buxy-xyz avatar Apr 18 '19 13:04 buxy-xyz

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!!!"

rundacode avatar Apr 18 '19 13:04 rundacode

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.

xelorp avatar Apr 18 '19 14:04 xelorp

rip desync meme

ghost avatar Apr 22 '19 00:04 ghost

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".

L3D451R7 avatar May 22 '19 19:05 L3D451R7

@kisak-valve Please understand that this issue is game breaking, the longer you wait to fix this issue the more damage it causes.

gitfury avatar Jul 01 '19 05:07 gitfury

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!

somebodyfrom2013 avatar Jul 15 '19 12:07 somebodyfrom2013

This game is dead.

ic23 avatar Feb 21 '20 17:02 ic23

Still not fixed in May 2020

click4dylan avatar Apr 28 '20 01:04 click4dylan

still not fixed as of august 2020

NuclearC avatar May 21 '20 18:05 NuclearC

@kisak-valve @mikela-valve @charleslvalve still not fixed as of 31st August 2020

swoopae avatar Aug 31 '20 14:08 swoopae

Still not fixed - 09/15/2022.

gettysburg avatar Sep 15 '22 13:09 gettysburg

theyre not going to fix it stop bumping

Simplehorror avatar Sep 16 '22 17:09 Simplehorror

@Simplehorror Source 2 will, as well as many other exploits.

gettysburg avatar Jun 07 '23 23:06 gettysburg