Like you said netcode bug that has been around for a long time. Kudos to Dylan for developing a fix independently. And for you attempting to show this mod team what is flawed in their product. Will this fix work for higher latency users as well?
-Stealthmode On Tue, May 8, 2018, 16:38 William Kane <[email protected]> wrote: > 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
_______________________________________________ Csgo_servers mailing list [email protected] https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
