You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I first referenced this on GitHub here: eukara/freecs#30
Duplicating here for visibility.
Quoting myself:
Since the VR input precision changes, it trips an anti-cheat measure (seen by sv_showpredloss 1) that is causing some movement packets to be discarded. Every time that trips with an anti-cheat warning, a movement packet has been discarded. He was aware of that being a problem right now with the VR extensions.
We're seemingly running ahead of the servers time (not ever meant to happen). If the client runs too slow or too fast, the server is supposed to attempt to correct it. Tweaking sys_clocktype can help on certain setups too (although it may cause issues on Win9x systems with longer uptime). Note that the gettimeofday setting may not deal with high frame rate (somewhere above 250 fps) well either.
Some CPUs and versions of Windows may cause CPUs to desync, which messes with clocks/timings in general.
Which explains why some people experience this more often than others, and some may not notice it at all.
I'll be on top of this and see if we can mitigate or work around these timing issues soon. Playing with the named cvars (or other time/precision related ones) might help for the time being
The text was updated successfully, but these errors were encountered:
I first referenced this on GitHub here: eukara/freecs#30
Duplicating here for visibility.
Quoting myself:
The text was updated successfully, but these errors were encountered: