Netcode Guide
From Tactical Wiki
Written and published with permission by narcissist/warnis/coris of Semper Fi.
Intro
REG OMG is a thing which is pretty common to hear on NS-servers around the internets. If you've found your way here in the first place probably means that you have fiddled with your rates already and (hopefully) have got some clue what the different commands do, so I won't give very in-depth explanations about the different commands dealt with in this small guide.
Contents |
[edit] Data controlling rates
rate
rate this command controls the amount of data the server sends to you. The variable itself is bound to all Half-Life based steam-games and stored in via a registry entry (thanks for this info Ed|Rush!), so changing it via the userconfig will be pretty much useless. What it actually does is to tell the server how many bytes per second it's allowed to send you (bytes, not bits. I've seen sites claiming it's bits. One byte consists of 8 bits, so if this were to be true you'd be using about 1.7 kpbs of bandwidth / second.). It's a general misconception that this should be set to 20000 (max value, even though some people claim that the max setting is 25000 which is false). There's is no ns server in the world that will be able to send you 20000 bits per second. After speaking to puzl (ns developer with great experience in server administration) I found out that the best setting for this command is between 12000-15000 (which is about 14 kbs / second), but as long as you stay over 10000 you're fine.
cl_cmdrate
cl_cmdrate controls the amount of packages your clients send to the server. Set it to 5 above your fps to send the server as many commands as possible. If your upload can't handle this, then set it as high as you can without experiencing choke/loss or ping spikes.
cl_cmdbackup
cl_cmdbackup sets how many times you should send each package to the server. Leave this at the default setting "2" since a higher setting will waste your bandwidth.
cl_updaterate
cl_updaterate tells the server how many packages to send you per second. This command actually works two ways. You want to receive a lot of packages since it will give you more correct player locations and therefore better hit-registry, and others want you to use a high setting as well. If you don't you'll base the packages you're sending to the server on old data which will result in bad hitreg on you as well. Set it to half your fps if your connection can handle it.
[edit] Rendering controlling rates (ex_)
This is where most guides go wrong. When we set our render rates we want to see as correct positions of player models as possible. Most guides try to achieve this by setting ex_interp to 0 (so it sets itself correctly, 1/updaterate) However, if you use an interp setting of 0 you'll run into problems. I'll explain why later on.
ex_extrapmax
ex_extrapmax is used to smooth out player movements in situations when you aren't getting enough information from the server (either due to loss, or the player using low rates) to interpolate the player movement. We don’t want this happening at all. Even if it smoothes out player movement it will cause your hit registry to turn shit because you're only doing rough estimates/guesses where the player will be, which might not at all correspond to where the player is located according to the server. Leave this at the default value, 1.2. Extrapolating leads us on to our next (and last) command, ex_interp.
ex_interp
Now for the cause of extrapolating happening, and where most guides go wrong: ex_interp. Many guides found on the internet will tell you to set this to “0â€�? since it will minimize the amount of interpolated (estimated) frames. This is completely wrong. In a perfect world where the server sent you the packages on the exact right frame, this would work wonderful. However, it doesn't work this way. Servers won’t send you the package on the exact right frame when you expect to get them, which causes you to extrapolate. This results in a lot worse hit registry than you should be getting (see ex_extrapmax explained above).
After I had read Net code Explained Again by Cameron Lloyd (which claims you should set your cl_updaterate to match the server sv_maxupdaterateto and then set ex_interp to 0 to get rid of extrapolation) I noticed, when doing as said in the article, my hit registry went down the drain. So I started to test other ways to get rid of extrapolation and found that the best way was to leave ex_interp at the default setting “0.1�? and then setting my cl_updaterate to half my fps. This would send me as many packages as the server could, but not trying to interpolate for each of them. This resulted in the client not having to extrapolate at all resulting in much better hit registry. After some testing I noticed that it could be left at 0.05 (which actually is the correct value for an updaterate of 20). Most servers could send me enough packages to interpolate correctly for this setting, while not having to extrapolate at all. This is what gives me (and many others I've given this tip to) the best hit registry.
Even if it's not a pretty solution, it works.
How do I know if I'm extrapolating?
One might ask him/herself after reading this. This is how you find out.
Start off my setting your net_graph to 2. This will give you a nice graph in the bottom right corner.
If you are getting yellow dots as showed in the picture to the right you are extrapolating. Try setting your ex_interp and cl_updaterate to higher values to get rid of this (if your cl_updaterate already is half your fps, then raise ex_interp instead).
You want your net_graph to look like this. As you can see, we aren't extrapolating.
[edit] So what rates do you use?
There are the rates I'm using (with a fps of 120, I run ns with developer turned on).
cl_cmdbackup "2" //default value cl_cmdrate "125" // fps + 5 cl_updaterate "60" // half fps rate "15000" ex_interp "0.05" ex_extrapmax "1.2" // default value
[edit] Sources
HL Net code (aka Rates) by Ed|Rush Net code Explained Again by Cameron Lloyd Half-Life Net code Explained Part II and CS Net code explained (articles no longer exist) by Johannes Jaba Greiser
If you find any grammatical or spelling errors (since english isn't my mother tounge and I haven't got word installed), feel free to drop me an email at: warnis@gmail.com
--Wuss 18:10, 27 Mar 2006 (EST)
Return to Natural Selection
