Det er mulig dette er gammelt nydt, men syntes det var en god "artikkel" så dertfor poster jeg den:-)
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 Counter-Strike 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 Counter-Strike 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_updaterate (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 Counter-Strike 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 Counter-Strike 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 Counter-Strike 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.
Kopiert i fra
http://www.gpforums.co.nz[...]
--
Dokumentasjon er som sex: Når det er bra, så er det veldig, veldig bra; og når det er dårlig, så er det bedre enn ingenting.