Time: 23:15:08 CET 14:15:08 PST 17:15:08 EST 06:15:08 Seoul 05:15:08 Beijing
BLOGS
Half-Life Net Code Explained Part II
Half-Life Net Code Explained Part II
Written by Andreas "bds" Thorstensson
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:
1. Current time + 1/cl_updaterate
2. 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:
1. Your client bandwidth doesn't handle all the traffic and you receive choke (as explained above).
2. 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_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 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 of Valve Software
* Martin Otten of Valve Software
* Zibbo of UDPSoft
* Perkele of UDPSoft
Written by Andreas "bds" Thorstensson
Half-Life Netcode Explained
Half-Life Netcode Explained
Written by Andreas Thorstensson
December 23, 2001
Introduction
I think Counter-Strike should be played as much default as possible. The colors, the textures, the shadows etc are all essential parts of a Counter-Strike map. Every corner and dark spot is taken into consideration when you create your tactics and your positions. That should not change. But I still believe that the personal aim skills should pay off and that you really hit where you actually aim. The more random the game gets the more frustrating it is for people that put alot of time into it to escalate on the skill ladder.
Behind the netcode
The server or gameworld gathers everything that is going on in the multiplayer game. The client sends information or packets with actions issued by the player, movement, firing and so on. The server receives the packets, calculates the information, is it a hit? is it a headshot? and then sends that information back to the client (player). The goal of the netcode is to make it work with every connection and to behave as smooth as possible.
The flaws of the netcode in HL
Everyone who played games with the Half-Life engine before the new netcode (before 1.1.0.0) remembers the game to be super accurate for players with low ping, and that you had alot higher ping with ISDN and modem compared to the new engine. In the new netcode Valve wanted the game to use less bandwidth to lower the pingtimes for ISDN and modem. To do this they changed the time the client sends updates to the server and the time the server sends the updates to the clients. With less client-server and server-client communication a smaller amount of bandwidth needs to be used. But because of that, the server-client and client-server communication is delayed.
With delayed server-client communication the players would move extremely jerky on screen. So they added interpolation. Interpolation takes the position of the semi-last known position of a player and moves it to the last known position during a period of time, interpolation time. On the other hand (and what Valve likes) with delayed server-client communication packetloss does not feel as bad.
In the old Half-Life netcode the client-server communication was based on client FPS (frames per second). The FPS decided how many updates were sent to the server. In the new netcode the case is not so. And with default settings the Half-Life engine bases the updates on a 30 FPS average.
The flaws of the HL server
There is a flaw of the HL server which makes it idle between every serverframe (update to the clients). This causes the game to be less responsive and adds higher pingtimes.
Default added lag
How much lag do I get by default settings?
Lets do some simple math here:
Server-client lag
An average HL server runs with about 20 fps (server frames) and default server-client update is 20:
1000ms / 20 = 50ms
Client-server lag
The default client-server update is 30
1000ms / 30 = 33ms
Interpolation lag
The default interpolation is 100ms
100ms
Total
50+33+100 = 183ms
Conclusion
So your actual latency is your ping + 183ms (in the worst case). A ISDN player will average about 230 ping.
Why do I hit at all?
Because Valve has added lag compensation. With lag compensation every packet received to the server is examined and its latency is reduced by the engine. So in this way it still "works" even with high ping. And it also (of course) works the same with low ping.
Why does it feel so smooth on my client even with high ping?
If you have played on a server with very high ping you feel that the weapons still are dead instant, when you hit that fire button the weapon reacts immediately and is being fired. In the new engine much of the multiplayer information is calculated on the client for visual effects. The client estimates were players are, it adds blood when you hit and also adds those bullet holes and marks on walls. But those are not true, they are only estimations and you never know if they are real. Only the server knows, and when you receive the correct update from the server the player that you aimed at will eventually die. And then you know for sure.
QuakeWorld worked great
The QuakeWorld server is very different compared to the HL server. It always sits waiting for packets to be sent to it. As soon as it gets one, it calculates the data and immediately sends it back to the client. Because of this QuakeWorld does not need interpolation. The only lag caused by QuakeWorld is the client-server updates (which are based on FPS as in the old Half-Life engine).
So lets compare added lag with other games:
Half-Life
As we said before adds up to 183ms lag.
QuakeWorld
No server frame delay and no server-client delay
Client-server communication is decided by client FPS which has a maximum of 72 in QW
1000ms / 72 = 14ms
No server-client delay
No interpolation
Total
0+14+0+0 = 14ms
Quake 3
The default server fps is 20 and default server-client update is 20
1000ms / 20 = 50ms
The default client-server update is 30
1000ms / 30 = 33ms
The default interpolation is 50ms
50ms
Total
50+33+50 = 133ms
What can I do?
So do I have to play another game to get accurate netcode? No you do not, the good part of all this is that you can tweak, or better put, "fix" those flaws.
Lets start with client commands:
cl_updaterate
Default: 20
Suggested: 20-100 depending on bandwidth, if your net_graph is falling and rising decrease this value.
cl_cmdrate
Default: 30
Suggested: Equal to your average framerate (remember max FPS in Half-Life is 99/100) or a divisor of it if your bandwith doesnt handle it. If you have a steady FPS near 99, make sure to put this value above 100.
ex_interp
Default 0.1
Suggested 0.05-0.1
Decreases the interpolation time, i.e the smoothing of the movement. The players will move more jerkily but more accurately.
cl_lc
Default: 1
Suggested: 1
Set to 0 removes the lag compensation totally, only works on LAN and with a very low ping.
cl_lw
Default: 1
Suggested: 1/0
Set to 0 removes the client-side behaviour of weapons and hits. A fired bullet (packet) is sent to the server and then returned to verify if it was a hit or not. Now you know for sure you did hit. But it only works fine on LAN and with low ping.
Now to server problems:
Thanks to Zibbo from UDPSoft who has released HLDS Ping Booster a fixed version of the HL server, you can increase the server fps heavily. The only drawback is that the server requires alot more CPU. You can then limit the server-client traffic with sv_maxupdaterate, default is 100.
So how much can I reduce the added lag?
Lets do the same maths again. Now we use the HLDS Ping Booster (maxupdaterate 100), we use cl_updaterate 100, cl_cmdrate 100 and ex_interp 0.
Server-client lag
A ping boosted HL server (with maxupdaterate 100) and server-client updates with cl_updaterate 100
1000ms / 100 = 10ms
Client-server lag
Client-server updates with cl_cmdrate 100
1000ms / 100 = 10ms
Interpolation lag
No interpolation
0ms
Total
10+10+0 = 20ms
Conclusion
From 183ms to 20ms with settings and the HLDS Ping Booster. Quite impressive.
Note: Using ex_interp 0 is not really recommended and is alot about personal taste, try values around 0.05.
Conclusion
I dont want to be a netcode/config cheater! Lets face it, why is it a cheat to make sure that what you see is also what the server sees? Take a basic example, with default cl_cmdrate and with an avg fps of 90 (quite common for the average player), only every 3rd frame you see on screen is true, the two other frames are totally ignored by the server (it does not know about them). How accurate is that? No wonder alot of people randomly says "useless game" while they are playing.
The commands are here, now just use them in a correct way. And last but not least, lets play the game as it was intended, with default graphics, sounds and models but with accuracy!
By Lauri 'Karvameduusa' Taskinen
Dec 7, 2008 21:56
Half-Life Net Code Explained Part II
Written by Andreas "bds" Thorstensson
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:
1. Current time + 1/cl_updaterate
2. 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:
1. Your client bandwidth doesn't handle all the traffic and you receive choke (as explained above).
2. 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_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 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 of Valve Software
* Martin Otten of Valve Software
* Zibbo of UDPSoft
* Perkele of UDPSoft
Written by Andreas "bds" Thorstensson
Half-Life Netcode Explained
By Lauri 'Karvameduusa' Taskinen
Dec 7, 2008 21:55
Half-Life Netcode Explained
Written by Andreas Thorstensson
December 23, 2001
Introduction
I think Counter-Strike should be played as much default as possible. The colors, the textures, the shadows etc are all essential parts of a Counter-Strike map. Every corner and dark spot is taken into consideration when you create your tactics and your positions. That should not change. But I still believe that the personal aim skills should pay off and that you really hit where you actually aim. The more random the game gets the more frustrating it is for people that put alot of time into it to escalate on the skill ladder.
Behind the netcode
The server or gameworld gathers everything that is going on in the multiplayer game. The client sends information or packets with actions issued by the player, movement, firing and so on. The server receives the packets, calculates the information, is it a hit? is it a headshot? and then sends that information back to the client (player). The goal of the netcode is to make it work with every connection and to behave as smooth as possible.
The flaws of the netcode in HL
Everyone who played games with the Half-Life engine before the new netcode (before 1.1.0.0) remembers the game to be super accurate for players with low ping, and that you had alot higher ping with ISDN and modem compared to the new engine. In the new netcode Valve wanted the game to use less bandwidth to lower the pingtimes for ISDN and modem. To do this they changed the time the client sends updates to the server and the time the server sends the updates to the clients. With less client-server and server-client communication a smaller amount of bandwidth needs to be used. But because of that, the server-client and client-server communication is delayed.
With delayed server-client communication the players would move extremely jerky on screen. So they added interpolation. Interpolation takes the position of the semi-last known position of a player and moves it to the last known position during a period of time, interpolation time. On the other hand (and what Valve likes) with delayed server-client communication packetloss does not feel as bad.
In the old Half-Life netcode the client-server communication was based on client FPS (frames per second). The FPS decided how many updates were sent to the server. In the new netcode the case is not so. And with default settings the Half-Life engine bases the updates on a 30 FPS average.
The flaws of the HL server
There is a flaw of the HL server which makes it idle between every serverframe (update to the clients). This causes the game to be less responsive and adds higher pingtimes.
Default added lag
How much lag do I get by default settings?
Lets do some simple math here:
Server-client lag
An average HL server runs with about 20 fps (server frames) and default server-client update is 20:
1000ms / 20 = 50ms
Client-server lag
The default client-server update is 30
1000ms / 30 = 33ms
Interpolation lag
The default interpolation is 100ms
100ms
Total
50+33+100 = 183ms
Conclusion
So your actual latency is your ping + 183ms (in the worst case). A ISDN player will average about 230 ping.
Why do I hit at all?
Because Valve has added lag compensation. With lag compensation every packet received to the server is examined and its latency is reduced by the engine. So in this way it still "works" even with high ping. And it also (of course) works the same with low ping.
Why does it feel so smooth on my client even with high ping?
If you have played on a server with very high ping you feel that the weapons still are dead instant, when you hit that fire button the weapon reacts immediately and is being fired. In the new engine much of the multiplayer information is calculated on the client for visual effects. The client estimates were players are, it adds blood when you hit and also adds those bullet holes and marks on walls. But those are not true, they are only estimations and you never know if they are real. Only the server knows, and when you receive the correct update from the server the player that you aimed at will eventually die. And then you know for sure.
QuakeWorld worked great
The QuakeWorld server is very different compared to the HL server. It always sits waiting for packets to be sent to it. As soon as it gets one, it calculates the data and immediately sends it back to the client. Because of this QuakeWorld does not need interpolation. The only lag caused by QuakeWorld is the client-server updates (which are based on FPS as in the old Half-Life engine).
So lets compare added lag with other games:
Half-Life
As we said before adds up to 183ms lag.
QuakeWorld
No server frame delay and no server-client delay
Client-server communication is decided by client FPS which has a maximum of 72 in QW
1000ms / 72 = 14ms
No server-client delay
No interpolation
Total
0+14+0+0 = 14ms
Quake 3
The default server fps is 20 and default server-client update is 20
1000ms / 20 = 50ms
The default client-server update is 30
1000ms / 30 = 33ms
The default interpolation is 50ms
50ms
Total
50+33+50 = 133ms
What can I do?
So do I have to play another game to get accurate netcode? No you do not, the good part of all this is that you can tweak, or better put, "fix" those flaws.
Lets start with client commands:
cl_updaterate
Default: 20
Suggested: 20-100 depending on bandwidth, if your net_graph is falling and rising decrease this value.
cl_cmdrate
Default: 30
Suggested: Equal to your average framerate (remember max FPS in Half-Life is 99/100) or a divisor of it if your bandwith doesnt handle it. If you have a steady FPS near 99, make sure to put this value above 100.
ex_interp
Default 0.1
Suggested 0.05-0.1
Decreases the interpolation time, i.e the smoothing of the movement. The players will move more jerkily but more accurately.
cl_lc
Default: 1
Suggested: 1
Set to 0 removes the lag compensation totally, only works on LAN and with a very low ping.
cl_lw
Default: 1
Suggested: 1/0
Set to 0 removes the client-side behaviour of weapons and hits. A fired bullet (packet) is sent to the server and then returned to verify if it was a hit or not. Now you know for sure you did hit. But it only works fine on LAN and with low ping.
Now to server problems:
Thanks to Zibbo from UDPSoft who has released HLDS Ping Booster a fixed version of the HL server, you can increase the server fps heavily. The only drawback is that the server requires alot more CPU. You can then limit the server-client traffic with sv_maxupdaterate, default is 100.
So how much can I reduce the added lag?
Lets do the same maths again. Now we use the HLDS Ping Booster (maxupdaterate 100), we use cl_updaterate 100, cl_cmdrate 100 and ex_interp 0.
Server-client lag
A ping boosted HL server (with maxupdaterate 100) and server-client updates with cl_updaterate 100
1000ms / 100 = 10ms
Client-server lag
Client-server updates with cl_cmdrate 100
1000ms / 100 = 10ms
Interpolation lag
No interpolation
0ms
Total
10+10+0 = 20ms
Conclusion
From 183ms to 20ms with settings and the HLDS Ping Booster. Quite impressive.
Note: Using ex_interp 0 is not really recommended and is alot about personal taste, try values around 0.05.
Conclusion
I dont want to be a netcode/config cheater! Lets face it, why is it a cheat to make sure that what you see is also what the server sees? Take a basic example, with default cl_cmdrate and with an avg fps of 90 (quite common for the average player), only every 3rd frame you see on screen is true, the two other frames are totally ignored by the server (it does not know about them). How accurate is that? No wonder alot of people randomly says "useless game" while they are playing.
The commands are here, now just use them in a correct way. And last but not least, lets play the game as it was intended, with default graphics, sounds and models but with accuracy!
« Previous1Next »
http://www.sk-gaming.com/rss/blog/Karvameduusa
