cl_cmdrate 101; cl_update 101 ;rate 20000 ;fps_max 99; max_shell 0 ;e_eax 1 ;net_graph 0 ;fps_show 0 ;sensitivity x.x; and the parameter ex_interp has always been controversial, because famous contests like cpl forbid the use of this parameter, otherwise it would be considered cheating

cl_cmdrate:

This parameter determines how many packets you - the client - sends to the server every second. Obviously, the higher the value, the faster the server responds to the commands you execute. If you have a broadband network and are its sole user, setting this value high won't do you any harm. If you and your friends are playing CS online in one place and you can feel a constant delay, then this command is the culprit. Most broadband (mainly ADSL) does not provide enough bandwidth for uploads, which is exactly what "cl_cmdrate" needs.

cl_updaterate:

"cl_updaterate" is quite similar to "cl_cmdrate", except that it does the opposite. It controls the number of packets you receive from the server side per second. Therefore, it relies on your download speed. The higher your "cl_updaterate" value, the higher your synchronization rate with the server. Since the server is the only one that can decide if you hit it or not, you certainly want to receive enough packets to stay synchronized with the server.

sv_maxupdaterate:

Just as "cl_updaterate" controls the maximum number of packets the client can send to the server per second, "sv_maxupdaterate "sv_maxupdaterate" controls the maximum number of packets per second that the client can send to the server, "sv_maxupdaterate" is the maximum number of packets per second that the server allows the client to receive. Therefore, it is pointless to set "cl_updaterate" higher than "sv_maxupdaterate".

sys_ticrate:

This parameter sets the number of frames that the server will calculate per second. The default value is 100. why is the server's FPS (frames per second) important? This parameter itself determines how you feel on this server. I'm sure we've all had the experience that some servers seem to be running on Deep Blue (or Aurora?) or Dragon Core. Longchip? Oh), and it's like we're playing a game on a LAN.

"sys_ticrate" is just a setting of your server's maximum FPS, which your server will generally not reach because your operating system doesn't allow it. There are many different ways to boost your server's FPS, but many of them require the cooperation of your server provider. Keep in mind that increasing the server's FPS will cause the server provider to overload the CPU of the machine, so most server providers won't do it. (For some reason, increasing server FPS on de_inferno and de_aztec can lead to CPU overload). The default FPS for Windows-based Half-Life servers is 64, while the default FPS for Linux-based servers is 50, and in some cases you can increase the server FPS up to 512. Whether or not to use such a high server FPS is debatable at this point, but in my personal experience. But in my personal experience, your game feels significantly better at 200 FPS.

Stability is key, and bouncing between 100 and 512 FPS will only make your game feel worse, so if your server is typically at 150 FPS, set the "sys_ticrate" to 150.

If you have remote control access to your server and want to know what the server is currently doing, then you should set the "sys_ticrate" to 150. If you have remote control access to the server and want to know the current FPS of the server, then type "rcon stats" in the command console. To check if your server has been boosted, temporarily set "sys_ticrate" to 10000 and type "rcon stats". If your server FPS is greater than 100, then your server is boosted.

ex_interp:

Before we begin, the Wechsler dictionary defines "interpolate" as follows:

Main Entry: in-ter-po-late (Main Entry: interpolate)

3. /p>

3: to estimate values of (a function) between two known values

intransitive senses : to make insertions (as of estimated values) (intransitive verb) estimated values) (intransitive verb : to make insertions (as of estimated values)

You can't be completely synchronized with the server because you just receive a certain amount of packets per second. For example:Figure shows. As the number of data points increases, the interpolated graph will get closer and closer to the original circle.In CS we can think of this circle as a different position in a player in one second. From the server's point of view, it is a perfect circle, and the client has to interpolate to predict the gap between two packets.

This is where "ex_interp" comes in. The gap between the two packets is determined by Half-Life's prediction mechanism. The "ex_interp" is set to interpolate between two consecutive packets in seconds. As shown above, these small time periods correspond to the sides of the interpolation polygon. Because the interpolation is made on the client side, it's not exactly the same judgment as on the server side. Nothing replaces real packets, but interpolated predictions do a good job for the most part.

Recommended values for online games:

RATE:

I've confirmed that rate is a maximum of 20,000, setting it above 20,000 doesn't make any sense, and may even degrade performance.

Recommended value:

rate 20000

sv_maxrate:

This is usually set to 0. This is not optimal for online play. "sv_maxrate 0" automatically monitors the connection speeds of all players and caters to everyone. Assuming that Half-Life allows players to use more than 20000 "rate" values, if a player is crazy enough to set his "rate" to 9999999999, the server will honor his request. If a player is crazy enough to set his "rate" to 9999999999, the server will honor his request. This not only leads to wasted bandwidth, but also to server overload. Therefore I recommend a safer value of "20000". In fact, it is possible that "sv_maxrate 0" and "sv_maxrate 20000" will have the same effect, but it never hurts to take precautions.

Recommended value:

sv_maxrate 20000

cl_cmdrate:

The ideal value for this parameter should be the same as the server's FPS (not the client-side FPS as was originally thought). If you send updates to the server side that exceed the server's own FPS, usually those excess packets are discarded. So, setting "cl_cmdrate" too high doesn't do much harm, but it wastes your bandwidth.

Recommended value:

cl_cmdrate equal to or greater than server FPS

ex_interp:

Set this value to 0. CS will automatically set your "ex_interp" to " 1/cl_updaterate" (your command console will tell you that "ex_interp" is forced to XX milliseconds. (Your command console will tell you that "ex_interp" is forced up to xx msec.) This is because the time between two packets is exactly 1/(updates per second), which is the amount of time you need the client to interpolate the prediction. Adjusting "cl_updaterate" will automatically adjust "ex_interp" (when "ex_interp" is set to 0). I suggest you only modify "cl_updaterate" and let your CS modify "ex_interp" automatically. You can't set "ex_interp" lower than "1/cl_updaterate" now, and setting it higher will cause you to have to aim at the back of the person appearing on your screen when shooting at an opponent, which is usually considered cheating (sic ex_interp). This behavior is usually considered as cheating (the original word is exploit, because exploit is also a kind of cheating in European and American tournaments, so it will be directly translated as cheating here). For example, if your "cl_updaterate" is 101, the correct value of your "ex_interp" is "1/101=0.009" (9 milliseconds). Using the default value of 0.1 creates the aforementioned "cheat" (exploit again, lol ftw)

Recommended value:

ex_interp 0

cl_updaterate:

The practice for a long time has been to let the "cl_updaterate" to drop from 101 to a "choke" value that you can live with. You can see the "choke" with the command "net_graph 3". For me, "choke" is the last value I care about. Actually getting the optimal value for "cl_updaterate" is more complicated, as the server-side settings for CAL matches are all "sv_maxupdaterate 101", so one might think that "Ideally, this would be correct, but in reality it is not. Most servers in the US do not provide 100 FPS, which means that it is impossible for a server to send out 100 updates per second. Therefore "cl_updaterate 101" does not guarantee that you will receive 100 updates every second, except for making your "ex_interp" 0.009, which results in the game feeling like it is constantly changing for players. This leads to a constantly changing feeling of the game for the players. Since there's no (unless there's a remote control, "rcon stats") way to know the FPS of a server, we have to guess at the optimal value of "cl_updaterate". You might say: "It's good to set "cl_updaterate" to 101, so that we can guarantee to receive as many packets as possible". The problem with this is that it ignores the effect of "cl_updaterate" on "ex_interp", which should be set higher. should be set higher.

To find the optimal value for "cl_updaterate" (remember to set "ex_interp" to 0), drop the value from 101 until the character in the game has only a very slight jitter. The degree of "slight jitter" is just a personal preference, as long as your "ex_interp" is equal to "1/cl_updaterate", the character should be at the correct level. As long as your "ex_interp" is equal to "1/cl_updaterate", the character should be in the correct position in the game. You must adjust your "cl_updaterate" for each server. Don't be afraid to use a "cl_updaterate" value below 50. The prediction mechanism will do its job. Note: Most public servers will set "sv_maxupdaterate" to 30, which is when "cl_updaterate 30" is most correct.

Please note that adjusting the "cl_updaterate" from low to high does not work. Once your "cl_updaterate" is set to a higher value, "ex_interp" does not adjust automatically and you have to manually enter "ex_interp 0" over and over again. interp 0" over and over again. Here's a handy script I wrote to adjust "cl_updaterate":

Setting file for adjusting update rate

Recommended values:

"cl_updaterate " should be equal to the server's FPS and should not exceed the server's "sv_maxupdaterate" value.

sys_ticrate:

Finding the right "sys_ticrate" value requires some experimentation. First of all, it makes no sense to set this value greater than 100 if your server fps is not being increased above 100. If you happen to rent a high performance server (i.e. the FPS has been increased), then you can do something about the "sys_ticrate". While higher FPS is a good thing, setting the "sys_ticrate" above 200 is usually not a good thing. For example, if you set "sys_ticrate" to 9999, your server's FPS will fluctuate between 150 and 1000 depending on the current battle situation on the map. So setting it below 200 will provide a more stable gaming environment. Typically, each computer that serves its provider runs multiple Half-Life servers, so if the "sys_ticrate" of all of them is very high, it will take up a lot of CPU resources. And that makes every player on every Half-Life server feel bad. (And most likely your server provider will increase the monthly rent).

Lastly, the FPS of a server can only be a certain number. For example, my server can only work at 85, 102, 128, 170, 256 and a few other FPS and no other FPS values. If you set "sys_ticrate" to 100, your server will automatically pick the one that works at less than 100 (in the above case, it would be 85). So try setting "sys_ticrate" by adding 20 to 50 to the FPS you want.

Recommended value:

sys_ticrate 110-180, depending on the quality of your server.

LAN tournament notes:

The reason those organizers of LAN tournaments, such as CPL, use "cl_updaterate 101" is because they use high quality servers. If the server's FPS is raised above 100, then using "cl_updaterate 101" is a reasonable value. A quick way to see if your LAN server's FPS has been boosted is to look at player ping. a default server running at 50 or 64 FPS will usually give players a ping of over 15 milliseconds, whereas an upgraded server will give a much smaller ping, usually around 5 milliseconds. As far as I know, CPL, ESWC and WCG all use boosted servers.