click4dylan
commented
4 years ago Players appearing out of dormant state are ALWAYS desynced, cheating or not. Read the code in the animstate code on the leaked 2018 source code of csgo. Place a breakpoint in the code when players come out of dormant state. You will see that the position of the player is from their last networked location (possibly across the entire map). Instead of networking the velocity and using this for animating, they take the distance between the current position and the last networked position, clamp it and set that as their velocity. This results in the players having the run animation at full speed, even if they are not moving or are slowly moving. This will take about 2 seconds to finally sync with the server because of the way the code is written to gradually slow down and ramp up player velocity. And since the server does not network the amount of time players were in the air, players who are jumping or falling while being dormant and then not dormant will have a desynced hitbox until the player hits the ground, finishes the animation and then idles or jumps again.
Also, your sv_pure bypass 'fixes' will never be truly fixed unless valve actually adds a heartbeat to the sv_pure file checks. The code is completely useless and anyone with a brain can bypass it with 1 line of code injected into the game
kkthxbye-code
swoopae
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.
EXAMPLE and USER-MADE FIX for the following issue: https://www.youtube.com/watch?v=hL3gxRv_5Jk -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.