This is really a very good explaination and as i understand it – you can take
this also as an argument to finally force CS:GO to a specific tickrate.
I was always a bit confused why the argumentation for the tickrate 66 force at
CS:S (which is logical) was not used for CS:GO (with 64 Ticks).
Related to this i want to call up one specific point in a previous changelog...
-Limiting physics timestep to 64 to eliminate high tickrate physics bugs, such
as bouncing guns
As long as you give the choice to select the tickrate, the community will
always choose the higher value – regardless if it makes sense or not. The
competative part of the community will always discuss about it.
...but as we all should remember.......it took just some few days after the
tickrate force or fps cap... to end years of unnecessary discussions.
just my 2 cents
Cheers
From: Vitaliy Genkin
Sent: Thursday, May 02, 2013 6:56 PM
To: [email protected]
Subject: Re: [Csgo_servers] csgo update
The value for sv_maxusrcmdprocessticks specifies maximum user commands that
server will handle from a client in a single server frame tick.
E.g. if you run a 128-tick server with max 3 usr cmds per tick, but your client
runs at sub-64 fps then the client might experience incorrect prediction on
movement and what you refer to as “lag”. The solutions here would be to:
1) disable the user commands limit completely on the server with
sv_maxusrcmdprocessticks 0
This would use old behavior and allows clients with any low framerate or high
packet loss to fully execute all queued up movement packets on the server and
allows clients to maliciously inject additional movement packets for execution
on the server thus possibly attaining a higher than maximum movement speed or
movement speed bursts observed by other players.
2) increase the user commands limit to allow slack for clients running with low
fps with e.g. sv_maxusrcmdprocessticks 16
The higher the value the higher “movement burst speed” can be observed by other
clients and can be attained on a single server tick by a cheater or user with
severe packet loss or low fps.
When running 64-tick server with default setting of max 3 user commands per
server tick clients might observe incorrect prediction on movement when running
with sustained fps below 25 fps or when running at 64 fps but dropping 30% of
packets or a combination of these unfavorable conditions. Even when a local
client encounters incorrect prediction on movement all other players in the
server still see their movement as smooth and from other players’ perspective
the movement speed is always within max movement speed.
To diagnose the case of clients being affected by the setting of max user
commands you can use “sv_maxusrcmdprocessticks_warning” convar, setting it to 0
will spew all server ticks and clients for whom user commands are being
dropped, setting it to 1 will spew no more than 1 message per second, setting
it to default -1 disables the spew. Once you narrow it down to the client you
can disable competitive min spec on the server and capture the client statistic
with “net_graph 5” on the client. Let us know if you encounter clients running
at sustained fps >= server tickrate without any packet loss that experience
dropped user commands and we’ll be able to investigate further from here.
Thank you,
-Vitaliy
From: [email protected]
[mailto:[email protected]] On Behalf Of Loïc Péron
Sent: Thursday, May 02, 2013 9:23 AM
To: [email protected]
Subject: Re: [Csgo_servers] csgo update
sv_maxusrcmdprocessticks "3" makes players lag when moving.
sv_maxusrcmdprocessticks "0" fix it.
--------------------------------------------------------------------------------
_______________________________________________
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
