this has actually nothing to do with high latency users Stealth Mode <stealthmode1...@gmail.com> schrieb am Mi., 9. Mai 2018, 03:07:
> 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 <ttall...@googlemail.com> 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 >> Csgo_servers@list.valvesoftware.com >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers > > _______________________________________________ > Csgo_servers mailing list > Csgo_servers@list.valvesoftware.com > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
_______________________________________________ Csgo_servers mailing list Csgo_servers@list.valvesoftware.com https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
