Many players in Dodgeball will tell you to change various config settings in TF2 for
a boost in performance or latency. And while there's absolutely some valid tricks to
gain a huge improvement for a very, very, very outdated engine trying to cope with
modern networking, there's also a lot of myths and misinformation that has been
spread over the Decades! That this has been a topic of discussion. I will attempt to
dispel some of them and give actual, objective, evidence based no bullshit advice here.
What even is Lerp?
Your game receives position updates from the server at a fixed rate (like 66 or 128 times per second) this is commonly known as "tick-rate". However, Those updates don’t arrive perfectly on time because:
- network jitter
- packet loss
- variable latency
- server tick timing
Are all a real concern for real-time internet servers that connect through various ISP's and countries.
So TF2 uses interpolation (lerp) to render gameplay smoothly.
Instead of showing you the most recent server position immediately, it intentionally draws the game slightly in the past, using a small buffer of time to fill in animation between packets.
If TF2 showed you only the raw positions as they arrive, movement would look choppy, rockets/players would teleport, hit reg would feel inconsistent, jittery clients would ruin the visual flow, player models would rubberband constantly.
Interpolation hides all of this.
How lerp is calculated
the formula is pretty simple:
lerp = cl_interp_ratio / cl_updaterate
example:
cl_interp_ratio 1 / cl_updaterate 128 = 7.8ms lerp
cl_interp_ratio 2 / cl_updaterate 128 = 15.6ms lerp
Why adding more lerp (higher ratio) helps stability
A larger lerp buffer gives the game:
- more time to handle late packets
- more protection against bursty jitter
- smoother visual motion during spikes
But the tradeoffs are:
- slightly more delay between real action and what you see
- slightly sluggish dodge timing
- slower response for deflecting rockets
This is why competitive players prefer "minimum lerp", while casual players sometimes use ratio 2 for smoother animation.
Why Valve designed it this way
Source for tf2 was designed in a different era of the internet (eta 2004-2007).
A lot has changed since, internet speeds were slower, jitter was far worse, packet loss was something to be expected, players came from dial-up/ADSL connections and source needed
clean motion for physics and hit reg. Interpolation helped with all of these.
Interpolation in tfdb (Dodgeball)
For normal tf2 gameplay, competitive players have for many years figured out that projectiles benefit more from lowering predictive interpolation than hit scan does.
so for many professional E-Sport players, a standard had become using different settings
per-class. Using what's called a class config. These can be found with many full suite configs
these days but can also be manually created.
For Hit-scan, the accepted wisdom has been to leave your
interpolation at 35ms.
cl_interp 0.035 + cl_updaterate 66
This ensures smooth predictions with minimal input.
Though for projectile based weapons and classes, players used
a lower ratio of 15.2ms.
cl_interp 0.0152 + cl_updaterate 66
for example on: Soldier, Demoman, Medic, Bow-Sniper, and notably, Pyro.
Why Pyro? Well aside the incredibly strong arsenal of secondary projectile weapons Pyro has,
Pyro also has a very strong ability with Airblast, reacting to and predicting the trajectory, speed and timing of projectiles fired at you becomes even more important in those scenarios.
For competitive play then, players have been using 15.2ms for Pyro.
Dodgeball on the other hand has some custom configurations that allow for 128 Tick on a server.
This allows for even lower interpolation possibilities.
cl_updaterate being 128 now, the lowest value tf2 will allow is cl_interp 0.0078125 (which you can simply enable through cl_interp 0).
Calculation
cl_interp_ratio 1 / 128 = 7.8ms lerp
So for Dodgeball servers that utilize 128 tickrate and allow a minimum cl_interp of 0.0078...
you can have a stable 7.8ms interpolation.
HOWEVER, for stable gameplay, it is important to note that not every connection is made equal.
Some servers, ISP's that aren't Tier1, or connectivity solutions (D-LAN, Wi-Fi, etc) are not ideal for such fast prediction timings.
there's a handful of settings that address this.
Settings for Wi-Fi / Mobile Hotspot users
cl_interp_ratio 2 leads to more stability and less packet loss. At the cost of a higher intepolation, though still minimal.
Calculation: cl_interp ratio 2 / 128 = 15.6 ms lerp
For many years, 15.2ms was the gold standard for Dodgeball, there's nothing wrong with this level of interpolation.
There's another important parameter often glossed over: rate
rate is the bandwidth by which your computer sends data and receives data from the server.
servers thankfully hard-cap this value but it can also be increased on custom configs.
However, generally speaking for stability, clients should be configured to use 60%~ of real-world upload bandwidth (in bytes)
So if my ISP gives me 10 Mbps Upload Speed, I should use:
rate 750000
if my ISP gives me 100 Mbps Upload Speed, I should use:
rate 7500000
Exceeding this may lead to stutter or significant packet loss.
You can calculate it by using this formula
10 Mbps * 125,000 = 1,250,000
1,250,000 bytes per second * 0.60 = 750,000
Settings for Ethernet (Fibre / Cable TV) connections
Finally, if you are fortunate enough to have home access to unrestricted fibre or cable ethernet
You can take full advantage of the maximum the server is providing you with
Settings should be
cl_interp_ratio 1
cl_interp 0
cl_updaterate 128 (it has innate fall-back for 66 tick servers)
rate (like discussed above)
Some other settings that may help you
There's some other dodgeball specific settings that users like @plutonium have helped optimize.
I'll list them here, personally, they've helped me but I can't define each one and what they do.
cl_lagcompensation 1 this should be based on your internet
cl_pred_optimize 2
cl_smooth 1
cl_smoothtime 0.01
net_maxpacketdrop 0
hud_escort_interp 0.1
net_compresspackets 0
net_compresspackets_minsize 0
net_maxroutable 1260
net_maxfragments 1260
net_splitpacket_maxrate 1048576
net_splitrate 1
net_maxcleartime 0
net_maxfilesize 64
Sources
Valve Community Developer Forum
JarateKing tf2.tv blog
nadeoki github tf2 repository
and input from Players, Developers, db server owners.