Hættið svo að væla yfir cfg haxi

“Half-Life Net Code Explained Part II
Written by Andreas ”bds“ Thorstensson <bds@geekboys.org>
2002-10-27
Introduction
I wrote my first net code column in December 2001. My goal was to explain some of the basic but still important net code commands to the public. I didn't want to explain everything in too much detail because I felt that the awareness of the commands was the most important factor. Now, almost one year later the column has been read by thousands and thousands of Half-Life and Counter-strike players all around the world. Some have just accepted what I said, some did not understand, some did not care and some dug deeper.

Words like ”config-hacks“ and ”interp-cheater“ are very common. False rumors are being spread. The information about what those commands actually do is incorrect in many cases.

My aim with Half-Life Net Code Explained Part II is to give a more detailed view of the net code. Both of version 1.5 of Half-Life and the upcoming 1.6 release.

Enough with the talk, let's get it on.

Explanation
I will start to explain the choke phenomenon since it has a vital affect on game play and net code settings.

Choke
Choke is determined as follows:

The next time a packet can be sent is:

Current time + 1/cl_updaterate

Current time + (number of bytes just sent / rate setting)

So, if you play with a high cl_updaterate value you are likely to get more choke if your bandwidth cannot handle it. Also, with a lot of players in the game world which means more data being sent you will also receive more choke (if your bandwidth cannot handle it). Finally, with a low rate setting, you also get more choke.
If choke is in effect, the server tries to see if it can send a packet to the client on every frame thereafter, rather waiting for the next multiple of 1/cl_updaterate, until the choke is gone.

Interpolation
The way the Half-Life engine uses interpolation is to store positions and times, when those (in game) positions were accurate, in its history. It then uses ex_correct to parse through the history for the best two positions (note that this does not have to be the two last positions). This means that a player moves at the same speed (the actual speed the player moves between those positions on the server) between its positions no matter what ex_interp value is used (as long as ex_interp set to 1/cl_updaterate or greater).

The only case when the player might move faster is after a huge drop of packets or if the player is under a great delay (because of latency) since he then is behind the game world and has to move fast into his correct position.

Commands
cl_updaterate/cl_cmdrate:
Why the default values are relatively low is because the game is designed to work for players with every type of connection and give them a smooth game play over the Internet. Another reason is that HLDS should work on most computers and not cause an immense load on the CPU.

As explained in my previous net code column the cl_updaterate and cl_cmdrate controls the server-client and client-server traffic. The higher values, the more traffic. However using low values won't create an inaccurate picture of the gaming world (that will only occur if the client starts to drop a lot of packets) because there doesn't need to be a one-to-one correspondence with the way the Half-Life engine works.

The bad thing about using too high cl_updaterate and cl_cmdrates is that:

Your client bandwidth doesn't handle all the traffic and you receive choke (as explained above).
The server you are playing on has to work under a lot higher pressure since much smaller and more movements are sent to the server for calculation which consumes CPU power and can cause server-lag.
The important factor here is to set values depending on personal choice and what your bandwidth and computer actually can handle. On LAN and in tournaments, these values should be set high for best consistency.
ex_interp
The much debated and dreaded cvar which has tons of myths around it. In Half-Life 1.5 the best value to use for ex_interp is default, 0.1. That is because of a small bug (on both the client and server) that affected how the interp was factored into the client and sent to the server (and because of that how it was factored into the lag compensation amount by the server). This lead to the 0.1 fudge factor being introduced which did an ok job at minimizing this bug. It worked best with ex_interp set to 0.1. Note that the ex_interp value of 0.1 is not hardcoded into the server as many people seem to believe.

As some of you already know the net code will change in Half-Life 1.6. The math which the client and server do for the lag compensation has been changed. This means that ex_interp now can (and should) be set to 1/cl_udpaterate (0.01 with cl_updaterate 100) to 0.1. Why the new formula is 1/cl_updaterate is because, assuming that there is no choke nor packet loss, players and objects will move continuously and receive the next update from the server right after they are finished interpolating. Note that to be able to get full effect of ex_interp 0.01 the server needs to be able to send 100 packets per second and most of the servers can't run that fast.

With the old bug you could get up to half of a players bounding box inaccuracy and even higher with ex_interp set to something else than 0.1.

sv_lan
After the CPL (and other events) changed their net code policy from default cl_updaterate and cl_cmdrate to higher values we noticed a lot of choke in LAN tournaments. This is because the HLDS forces rate to 10000 on every client when the server is ran in sv_lan 1 mode. This was in the beginning created not to cap the rate to 10000 but to raise the default value on clients from 2500 to 10000 and achieve a better feel while playing on LAN. This will be fixed in the Half-Life version. The Half-Life engine however caps the rate to 20000, so any value above that is ignored.

ex_extrapmax 1.2
Extrapolating occurs when the client does not have an end position to interpolate to. It then extrapolates a predicted position which the client is moved to. Extrapmax sets the maximum amount of time we will extrapolate the player (read: how far). If the position is outside this value the player will not be moved any further. The server does always count on a default position so changing this value doesn't do anything.

ex_correct 0
Another way to handle client interpolation and prediction. The server always counts on the default value 0. This will also be removed in the next Half-Life version.

ex_maxerrordistance 64
In conjunction with ex_correct set to 1 you can set the maximum radius distance a player is moved smoothly from position x to position y. If a player is moved out of this radius he will be moved immediately (teleported) to the end position. However the server always counts on ex_correct to be 0. And since ex_correct 0 will be removed this will also be removed in the Half-Life update.

sys_ticrate
This value caps the servers dedicated framerate. The higher the value the more packets can be sent to the clients.

sv_maxupdaterate
This value caps the server’s maximum updaterate. The higher the value the more packets will be sent to the clients (if the servers frame rate is high enough).

Conclusion
As I said earlier, the important factor is to set values depending on personal choice and what your bandwidth and computer actually can handle. The Half-Life engine does a good job of making the client- and server world accurate even with low settings. In a good environment (read: LAN events) where the servers and clients actually can handle these high values the game play will get even more consistent.

Thanks to these people for net code discussions:

Yahn Bernier
Martin Otten
Zibbo
Perkele
Written by Andreas ”bds“ Thorstensson
<bds@geekboys.org>”

Stolið feitt af http://www.geekboys.org/docs/netcode2.php

MurK-Kriss i