Hitbox misalignment between client & server
Closed this issue · 2 comments
Hitboxes desync between the client and server in these scenarios:
-Players appearing out of dormant state: The server does not network the player velocity or any of the animation state information when first networking a client to a player. This causes the velocity on the client to be clamped due to a 'teleport' since the server did not network the player position while they were dormant, resulting in the player's upper and lower body as well as legs to not match the server for a number of ticks. Also players appearing out of dormant state while jumping is desynced in this case as the server does not network the amount of time the player was in the air. There are also other cases where this breaks hitbox sync but they are minor.
-Players standing on conveyer belts and moving objects: The server does not network the base velocity of the surface they are standing on, resulting in the client predicting their position incorrectly resulting in major judder and teleporting when standing on conveyer belts and other custom levels involving moving objects
-Players turning around quickly: The client runs code to allow the legs to smoothly shift into place in the function called DoExtraBoneProcessing while the server does not, resulting in the leg & feet hitboxes always being desynced from the server when a player is turning around.
-Players who do not have a frame rate at least as high as the server tickrate, those using cheats, or when experiencing packet loss results in complete hitbox desync up to 58 degrees away from the server hitbox in either direction: When clients do not send usercmds to the server at a constant rate (one per tick), the server will run all of the usercmds that the client sent in sequence. Each usercmd will get simulated by the movement code and then animated by the server's animation code. After all usercmds are finished running, the server will network the new player position and viewangles to other clients. Since the server only networks the newest information to other clients, they do not animate the missing data that the server did, resulting in desynced hitboxes in every single case, such as running, jumping, turning, firing, reloading, flashbang animations, crouching, and more. The hitbox is not usually desynced enough by a legitimate client to cause the hitbox to be desynced such a large amount as a cheat can, but there ARE edge cases where this can happen. The solution to this bug is to have the server only animate the final usercmd sent by clients. The server will still run movement code, but only the final one will be animated and sent to other players. The client code will still interpolate the player models resulting in a smoother appearance but the hitboxes will actually line up with the server in the vast majority of cases. There is no reason for the server to animate every usercmd as it will still appear as a laggy and teleporting player (depending on how many usercmds are being held back by the player) to other people. The server should also do a verification on all of the sent usercmd tickcounts prior to running them to filter out invalid ones so that clients cannot maliciously prevent their player from being animated.
Can confirm, this is a legitimate issue that Valve has to address.
Players appearing out of dormant stat
Many games work that way. They fix teleporting by using something called "interpolation".
for a number of ticks
In most cases it is just one tick. Unless there's another logic? Please send proof.
Players standing on conveyer belts and moving
This doesn't affect matchmaking, FACEIT, ESEA and others. There are no moving platforms there. But I got your point. Anyway, that's not an exploit but a bug.
Players turning around quickly
That's not an exploit but a bug.
Players who do not have a frame rate at least as high as the server tickrate
Well that's not even a bug. That is a bottleneck.
You have absolutely NO idea what you are talking about. This github is called csgo_bugs and you are closing legitimate bug reports.