interp interp_ratio rate updaterate cmdrate tickrate fps TV

Hello,

Firstly, sorry for my bad english...

Secondly, for game developers or technical people : have fun with the link below.
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Valve source engine is used for this games :
        Counter Strike: Global Offensive
        Half-Life 2: Deathmatch
        Counter Strike: Source
        Day of Defeat: Source
        Team Fortress 2
        Left for Dead
        Left for Dead 2

Thirdly, for non technical people, see below, I explain how it works (it's a resume with explications of the link above) :

- The server simulates the game in discrete time steps called ticks/seconds. So, a tickrate 128 means the server simulates the world every 7,8 milliseconds (128 times by second), a tickrate 64 means every 15 milliseconds. Simulates the world means calculates positions, all events...

- The ONLY COMMANDS NETWORK THAT TO TAKE CARE for client are "rate", "cl_updaterate", "cl_cmdrate", "cl_interp", "cl_interp_ratio", "cl_predict", "cl_interpolate" and "cl_lagcompensation" :

=> "rate" :  If the server try to send data with higher data rate than the value of rate (in bytes/second), it's bad because there will have "packet loss". In theory, the value of rate should be the value of your connection bandwidth. For example, with a connection which have a maximum download rate equals to 1 Mbytes/second, you should have 1 Mbytes = 1 * 1024 KBytes = 1 * 1024 * 1024 bytes = 1048576 bytes/second (yes, 1 Mbytes = 1024 Kbytes and 1 Kbytes = 1024 bytes but no care). With this, you should write in your cs go config rate "1048576". BUT, in the real world of the real universe (with war, starvation and justin bieber), there is no games which send 1 Mbytes/second at each clients. So 400000 is enough, even 128000.
    Examples :
    rate 128000 means 0.12 Mbytes/second
    rate 400000 means 0.4 Mbytes/second

=> "cl_updaterate" : The value of this, 128 for example, means "hey server, I'm a client, send me 128 times/second an update of the world". Two limits : the server never send you more update of the world than the tickrate of the server (it can't send you 128 update/second if it simulates 64 times the world/second... science bitch) and it can't send more data than the "rate" value of your config (packet loss !!!). The best value is the same than the tickrate of the server, nothing else (Valve servers are 64 tickrate, and the most of dedicated server are 128, so change it with the console before to connect to the server)

=> "cl_cmdrate" : The value of this, 128 for example, means "hey server, I will send you 128 times/second an update of my input (mouse, moving, ect...)". No limit for this value. BUT, useless to send more update than the tickrate server (you can send 128 update/second if you want but if the server simulates the world 64 times/second, you have 128-66 updates useless... I let you compute, science bitch). The best value is the same than the tickrate of the server, nothing else (Valve servers are 64 tickrate, and the most of dedicated server are 128, so change it with the console before to connect to the server)

=> "cl_interpolate" : Set to 1, it means activate the interpolation (explication of interpolation below with "cl_interp" and "cl_interp_ratio"). Set to 0, means no interpolation, so the two commands below do not effects. The ONLY VALUE TO SET HERE IS 1, nothing else. You have JUST NO REASON TO DESACTIVATE INTERPOLATION.

=> "cl_interp" : More complicated. There is several mechanisms used by the valve source engine and client software to have a good game sensation (fluidity...). Like the documentation says : "If the objects (entities) in the world were only rendered at the positions received by the server, moving objects and animation would look choppy and jittery. Dropped packets would also cause noticeable glitches. The trick to solve this problem is to go back in time for rendering.". So, by default, client (your software game on your PC) doesn't display the last update of the world received by the server, not the second last, but the second second last (I don't know how it names in english). The problem with this command is it's complicated to compute the right value for each server. Indeed, a value equals to 0.1 means your game displays you the data received 100 milliseconds before the last data received (unit of cl_interp is second, 0.1 second is equals to 100 milliseconds). This value works only with a cl_updaterate equals to 20. Indeed, with updaterate equals to 20, you received an update every 50 milliseconds (1 second = 1000 milliseconds -> 1000 / 20 = 50 milliseconds), so with a "cl_interp" to 0.1, your client go back in time of 100 milliseconds, which matches with 2 updates (50 milliseconds + 50 milliseconds = 100 milliseconds... science, ect, ect...). You need to adapt the cl_updaterate to the tickrate of the server and to adapt the cl_interp to the cl_updaterate..., even for Valve it's shitting. So, they introduce the command "cl_interp_ratio" to make it very simple. The ONLY VALUE OF THE "cl_interp" command is 0, nothing else.

=> "cl_interp_ratio" : Like I said before, to make interpolation (interp = interpolation if you didn't understand) very simple, the interpolation is computed like that "interpolation period = max( cl_interp, cl_interp_ratio / cl_updaterate )". This equation means "interpolation in second is equals to the maximum value between the cl_interp command and the division of the cl_interp_ratio command by cl_updaterate command". We have positionned "cl_interp" to 0 just before (if you don't understand, you didn't read explications of "cl_interp" bad student), so "cl_interp" will never be the maximum. The command "cl_updaterate" must be change to match with the tickrate of the server (if you don't understand, you didn't read explications of "cl_updaterate" bad student). So, there is this "cl_interp_ratio". It's very simple. You want to go back in time of 2 updates ? OK, cl_interp_ratio equals to 2. Final point. Instead of calculating the time in second to go back in time of 2 updates from the server, you just indicate the number of updates you want to keep. Now, I see you arrive : "So I need to have the less interpolation possible to have the last representation of the world and the hitboxes !! " NO, NO and NO. Why ? Cause the "lag compensation" (see below). SO, a good value for "cl_interp_ratio" is 2. With this, you keep the fluidity in your game, the protection of packet loss and it isn't a disadvantage compared to others.

=> "cl_lagcompensation" : Between the representation of the world you have on your monitor and the situation of the world on which the server works, there is a HUGE difference. But, don't panic, the server knows the interpolation (if you don't know what it is, you didn"t read explications on "cl_interp" bad boy) of each players and the ping of each players. So, the server take care of the differences of configuration of each players. If you shoot a guy, you can sometimes have the sensation than your crosshair isn't on him. But the server calculates this : Command Execution Time = Current Server Time - Packet Latency - Client View Interpolation. Command Execution time means there is a difference between the time of reception of updates that you send to the server (the real time of the real world of the real universe) like mouse input and the time which it really happen (the simulate time). To compute the simulate time from the real time, the server take care of your ping (the travel time of the date between client and server), and of your interpolation time. So, THE UNIQUE GOOD VALUE FOR THIS COMMAND IS 1 (it means lagcompensation activated).

=> "cl_predict" : It's another mechanism used by client software to have a good game sensation (fluidity...). If the value is 1 (it means input prediction activated), your client (software game on your PC) will extrapolate your position between after the sending to the server of an update of your input, moving... before to correct it with the next update from the server. I can't find best explication than the valve documentation :
"Lets assume a player has a network latency of 150 milliseconds and starts to move forward. The information that the +FORWARD key is pressed is stored in a user command and send to the server. There the user command is processed by the movement code and the player's character is moved forward in the game world. This world state change is transmitted to all clients with the next snapshot update. So the player would see his own change of movement with a 150 milliseconds delay after he started walking. This delay applies to all players actions like movement, shooting weapons, etc. and becomes worse with higher latencies.
A delay between player input and corresponding visual feedback creates a strange, unnatural feeling and makes it hard to move or aim precisely. Client-side input prediction (cl_predict 1) is a way to remove this delay and let the player's actions feel more instant. Instead of waiting for the server to update your own position, the local client just predicts the results of its own user commands. Therefore, the client runs exactly the same code and rules the server will use to process the user commands. After the prediction is finished, the local player will move instantly to the new location while the server still sees him at the old place."
So, the best value for "cl_predict" is 1.


To conclude :

I see you arrive : "So, I need to desactivated interpolation and input prediction to have the last representation of the simulate world !!!". NO, NOOOOOOOOOOO and NOOOOOOOOOOOOOOOOOOOO. YOU NEED TO HAVE ALL OF THIS ACTIVATED.
The input prediction with interpolation and lag compensation (if you understand nothing of this words, read all explications above) together give a good sensation of playing (fluidity...) WITHOUT DISADVANTAGED you compared to another players. The lag compensation use your ping in the computations of the server to avoid the difference between players.

Another things : tickrate 128 or 64 ? NO CARE, because all players play on the same server. They will never have more updates than you even if they set their "cl_updaterate" to 128 on a server with a tickrate 64. The cl_updaterate and cl_cmdrate must be adapted to the tickrate server for not be disadvantaged.

Another things number 2 : think that with a tickrate 64, have 100 fps is enough, really, really and really. No need to have 150 fps, 200 or more. The only disadvantaged is to have less fps than tickrate cause your game doesn't display all informations it can. But you don't know what updates are really displayed or not so... it's not a big disadvantaged, just a reason to rage maybe :).

Another things number 3 : In offline competition, the only difference is the good quality of the network compared to internet. But, the interpolation must stay activated because even if the lost of network packets is more rare than on internet, you keep the fluidity with the two updates that you keep in reserve. However, the extrapolation (cl_predict) can be set to 0. Indeed, if you look the most of pro config, they are for perfect connection (in offline competition). So, their cl_predict is 0, because the ping is insignificant.

Another things number 4 : For the spectator mode (GOTV), the documentation says : "If you follow a player in "First-Person" as a spectator in a game or SourceTV, you don't exactly see what the player sees Spectators see the game world without lag compensation.". So don't cry, it's normal if you don't understand sometimes how the player shoot a guy or if you see weird things.

Another things number 5 : See with net_graph 1 if you have 0 choke and loss. If yes with the configurations above, you just have no reason to criticize the game. It's juste you are bad. Training, training and training, that's all.

Once for all, that the explanations of these commands.