I saw over at UKTerrorist that the entire lot of ex_ cvars has been explained by a SoGamed forum post featuring an e-mail by Yahn of VALVe (click through below if SoGamed is too slow). If you've never heard of them, a lot of pro-level players like to tweak the netcode with the ex_ series of variables; naturally there's a lot of debate about their undocumented effects, if any.
Because the site is extremely slow due to a whole mass of replies being shown at once, CS-Nation has also posted the e-mail from Yahn (click through below). Very interesting stuff.[break="click here to read valve's explaination of the ex_ cvars"]
Because the site is extremely slow due to a whole mass of replies being shown at once, CS-Nation has also posted the e-mail from Yahn (click through below). Very interesting stuff.[break="click here to read valve's explaination of the ex_ cvars"]
ex_correct: default is 0, when set to one, instead of interpolating player position on client tries to physically simulate other players so that they smoothly steer back onto course if you drop packets. This isn't accounted for on the server for lag compensation so it can only hose your aim. This stuff was an experiment I was running on a different way to handle packet loss vs. the visual display, it should have been removed a long time ago when we did the TF1.5 netcode changes.Thanks to Mell1n for e-mailing Yahn and posting the reply to SoGamed.
ex_extrapmax: when we interpolate players on the client, sometimes we don't have the data to continue interpolating so we start extrapolating packet loss causes this). The extrapolation fraction is clamped to this value ( default 1.2 ). Again, the server doesn't take this into account for lag compensation, so I wouldn't mess with it.
ex_interp: The amount of interpolation to do on the client ( range 0.0 to 0.1 ). This determines how much interpolation to do ( 100 msec or 0.1 is the default ). This is factored into an overall "view latency" for the player and that latency is clamped to 0.0 to 0.1. I'm not sure why the cpl likes 0.5 when the code is more closely tuned to 0.1 as the default.
ex_maxerrordistance: Only applies if ex_Correct is 1, this looks at how far off the physical simulation has gotten from the true player origin and if it's greater than this distance, we teleport the player to this spot. The server doesn't take this into consideration since we assume ex_correct 0 on the server
cl_nopred: This used to be active, but it's not longer hooked up to the prediction code so it doesn't do anything. In the old days, you could turn off client side prediction of player movement (and weapon firing effects) with this. It was removed a while back due to exploits.
I'm going to have our engineers remove the following settings from the next update:
ex_correct
ex_extrapmax
ex_maxerror distance
cl_nopred
And I'm going to consider removing the cvar for ex_interp and forcing the value internally to 0.1 as it was designed to be. There's really no reason end users should ever have to mess with these things.
Comment