// *** STILL UNDER DEVELOPMENT ***

// Everything you need to know about network settings, straight from the source (hue)
// https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
// https://developer.valvesoftware.com/wiki/TF2_cvarlist
// CFG by: athairus

// THE FORMAT:

// "Valve documentation"
// My comments

//
// Server to client data
//

// "Number of packets per second of updates you are requesting from the server"
// By default this is 20, the highest you can go is the hard-coded server tickrate, 66
// If the server wants to send a packet to you but lacks the bandwidth, that missed packet will show up in the choke counter
// Choke is bad. Lower your cl_updaterate if it's ever non-zero
cl_updaterate 66

// Place net_66 in your main config file
// If the server you're playing on chokes, try a lower one
alias net_66 "cl_updaterate 66; cl_cmdrate 66; alias net_hitscan net_hitscan_66; alias net_projectile net_projectile_66"
alias net_40 "cl_updaterate 40; cl_cmdrate 40; alias net_hitscan net_hitscan_40; alias net_projectile net_projectile_40"
alias net_33 "cl_updaterate 33; cl_cmdrate 33; alias net_hitscan net_hitscan_33; alias net_projectile net_projectile_33"
alias net_20 "cl_updaterate 20; cl_cmdrate 20; alias net_hitscan net_hitscan_20; alias net_projectile net_projectile_20" // default

// "Max bytes/sec the host can receive data"
// ~100KB/s, totally overkill as I usually see ~20-30KB/s max
// Nothing wrong with overkill here!
rate "100000"

//
// Client to server data
//

// "Max number of command packets sent to server per second"
// By default, the max amount the server will let you send is 66
cl_cmdrate 66

//
// Client prediction (your guy)
//

// "Perform client side prediction."
// Predict what your inputs will do to the server's simulation, from the client side.
// Default 1 (on). You'd be insane to turn this off. It'd delay your inputs by dozens of ms with no benefit
cl_predict 1

// "Optimize for not copying data if didn't receive a network update (1), and also for not repredicting if there were no errors (2)."
// This should never be changed, default is as good as it gets
cl_pred_optimize 2 

// "Perform server side lag compensation of weapon firing events."
// Tell the server to compensate for the fact your inputs do not reach the server instantly (based on your ping),
// pretty much mandatory unless you like leading your shots...
cl_lagcompensation 1 

// "Smooth view/eye origin after prediction errors | Smooth client's view after prediction error over this many seconds"
// Prediction error smoothing: when your client doesn't have the correct picture of what's going on 
// with your character's position on the server simulation (as the server always has the final say), 
// smoothly move your character over cl_smoothtime seconds to its rightful place.
cl_smooth 1
cl_smoothtime 0.1

//
// Client entity interpolation (everyone else on your screen)
//

// Buffer the snapshots received from the server by (lerp) seconds, interpolating between snapshots whenever it's time for the renderer to render.
// Default server configuration limits setting this to between 1 to 5 ticks (15ms to 75ms).
// Note that cl_interp is only clamped at the _lower_ bound by sv_client_XXX_interp_ratio

// You get two ways to set it: explicitly or as a function of the tick rate.
// The final value aka "lerp" = max( cl_interp, cl_interp_ratio / cl_updaterate (=66) ).
// You can think of the interpolation buffer (lerp) length as additional time added to your ping.
// It's in your best interest to keep lerp as low as possible.

// lerp corrects packet loss
// The lerp buffer will interpolate across two packets if a packet in the middle that should be there is missing
// Packet loss is serious. If you're losing packets regularly, play on another server or call your ISP because something's up...

// lerp corrects jitter
// When packets come to your client later than they should, their position in the lerp buffer must be shifted backwards in time to their rightful place
// If the packet was already in use for interpolation, then some undesirable acceleration of interpolation happens
// To avoid this, for hitscan weapons, have at least 2 packets in the interp buffer at any given time. The 'newest' one can be shifted back in time to its rightful place without affecting what you're seeing on-screen
// For projectile weapons, this doesn't matter as much since projectiles are all server-side. Having 1 packet in the buffer is fine.
// Note that the flamethrower counts as a projectile here.

// "Sets the interpolation amount (bounded on low side by server interp ratio settings)."
// Value is in seconds
// Set to 0 to not have it not be a factor in final lerp calculation
cl_interp 0.1 // Don't use

// Handy aliases to put in your class configs
// Assume a jitter of 10ms max on any server you'll ever connect to (net_graph 4, check "var" to confirm), adjust if that's not true
// Remember that you might use lower cl_updaterate values if the server chokes (see above)
alias net_hitscan_66 "cl_interp_ratio 2.66; cl_interp 0.0403"
alias net_hitscan_40 "cl_interp_ratio 2.40; cl_interp 0.060"
alias net_hitscan_33 "cl_interp_ratio 2.33; cl_interp 0.0706"
alias net_hitscan_20 "cl_interp_ratio 2.20; cl_interp 0.110"

alias net_projectile_66 "cl_interp_ratio 1.66; cl_interp 0.0252"
alias net_projectile_40 "cl_interp_ratio 1.40; cl_interp 0.035"
alias net_projectile_33 "cl_interp_ratio 1.33; cl_interp 0.0403"
alias net_projectile_20 "cl_interp_ratio 1.20; cl_interp 0.060"

// "Sets the interpolation amount (final amount is cl_interp_ratio / cl_updaterate)."
// Use the aliases above
cl_interp_ratio 2.0