paging wareya

The one thing I still don't understand is why people advocate for different lerp values based on classes. My understanding is that it only really comes in handy if there's packet loss, which is a fairly significant issue that shouldn't happen to anyone, ever.

Can anyone chime in? I've read the section on interp over and over and still can't understand what the rationale is behind some peoples' choices in interp values. It just seems smart to keep it as low as possible.

EDIT: After some testing I realized that sometimes when using hitscan you want to simulate the advantages (yes I said advantages) a higher ping will give you (read: killing enemies after they think they're behind cover) by turning up lerp (usually as high as it goes?). I think that's incredibly unfair to do that, but hey it's doable with default server settings so I guess Valve knew what they were doing?

Server owners! You should reduce the max lerp ratio from its value of 5 down to something more reasonable like 2:
sv_client_max_interp_ratio 2

I'd suggest adding a comment about the cl_lagcompensation to disable this when in a LAN environment.

For the love of Justin no.
https://youtu.be/hP9yrLSL-G0

did I get paged

>cl_cmdrate 100

No, set this to the same value as cl_updaterate in all situations (except for choked settings e.g. cl_updaterate 20)

>cl_pred_optimize 2

This is fine but I want to note that lowering this can THEORETICALLY improve hitreg (by imperceptible amounts), particularly in obscure computing situations, at the expense of framerate.

>// Reset these to defaults (1, 0.1) if you don't like how the game acts when you rocketjump or get knocked around

:)

>cl_interp_ratio 1

Enjoy your bad hitreg against scouts on connections with high jitter.

It should be cl_interp_ratio 1.1 at a minimum unless you're going out of your way to shave off milliseconds of imperceptible animation latency reduction.

>extrapolate commands

Afaik these are locked behind sv_cheats. Did they change that? Remove them from the config if they're still.

>I'd suggest adding a comment about the cl_lagcompensation to disable this when in a LAN environment.

http://i.imgur.com/d8w4POp.png

I've always used cl_interp_ratio 1 and never noticed any issues with hitreg on scouts. Maybe they just always had good connections

>The one thing I still don't understand is why people advocate for different lerp values based on classes. My understanding is that it only really comes in handy if there's packet loss, which is a fairly significant issue that shouldn't happen to anyone, ever.

Packet loss is a scapegoat, and VDW is guilty of giving people just enough information to feel like they full understand very complicated topics. Jitter is the biggest reason that above-1 interp ratio is necessary (for hitscan). I've had long indepth arguments here about this already and I really don't want to do this for the third or such time. Tl;dr: jitter breaks the interp window and makes extrapolation kick in which makes animations happen in the wrong place.

http://teamfortress.tv/thread/21446/cl-interp-0-05/?page=1

http://i.imgur.com/BPIeVzl.png

You only have milliseconds to lose in return for accurately replicating animations. The only place that you actually want to reduce interp as far as possible is on projectiles, which is the whole reason that per-class configs exist.

inb4 muh placebo

>Server owners! You should reduce the max lerp ratio from its value of 5 down to something more reasonable like 2:
sv_client_max_interp_ratio 2

2 is reasonable, you're still not getting people who lower their update rates as well. It's a problem that the server doesn't give people enough to work with. Anyway, you're locked into whatever interp you spawn with now, and having high interp makes it basically impossible to react to what people around you are doing. It's ALWAYS an overall disadvantage to increase the latency of your view of enemy players, even if you get more lag compensation for it.

virgins ( ͡° ͜ʖ ͡°)

This debate is always so interesting. Is there any other game out the where network settings are looked into and analyzed this much?

CS, the arguments only ended once leagues fully restricted all net settings.

@wareya I have my interp ratio at 1 and my interp at 0.033 for hitscan. you'd recommend something like interp ratio 2 and interp at 0.0165?

[edit] nevermind, dug around some more and found this --

for projectiles its ratio 1 and interp 0. http://teamfortress.tv/thread/1601/cl-interp
for hitscan it's ratio 2 and interp 0.0303 : http://teamfortress.tv/thread/11394/interp-lerp-other-stuff

I don't understand it but I'll follow it blindly ;)

im curious

why not similarly restrict net settings in tf2? or why was it a bad decision in cs? or are those two things not mutually exclusive

If you restricted them in TF2 wouldn't you be fucking over either projectile class players or hitscan players

cs is a bigger esport and they probably want everyone to have the same network settings in order to stay consistent and also make it easier for people who know nothing about it.

I would use ratio 2.2 and interp 0.033 on hitscan because it adds a jitter buffer for dropped packets

a ratio of 2 means that (theoretically-)50% of times that a single packet is lost, it will still miss the interpolation window

ratio 2 is still fine

that feeling when somebody comes into your dojo and steals all your thunder

Doesn't ESEA lock cl_interp_ratio down to 1? I always set it to 1 for this reason. If they allow you to change it I might play around with other settings.

doesn't cl_interp_ratio merely multiply your cl_interp by that number
so you can get the same result by leaving ratio at 1 and setting your interp higher.

saying ratio 2.2 and interp 0.033 is misleading
the settings it means are cl_interp_ratio 1, cl_interp 0.033 (or cl_interp 0, cl_updaterate 66, cl_interp_ratio 2 which equals the same thing)

jitter buffer is the extra interp above 0.0303 which I would also recommend.
even on soldier I use cl_interp in the range of 0.016 to 0.02 for that reason.

Thanks for chiming in, everyone and wareya especially.

Since this just defines the max rate, what's the harm of overkill? The server will clamp it, won't it?

Oh, and this is something the wiki did NOT cover: choke. Choke occurs when the server cannot send data quickly enough to clients, right? I suppose that may imply the server can't receive data quickly enough from clients, either. Even in a choke situation, shouldn't your client be sending as many updates as the server can receive and consume? Or is consistency rate-wise more important?

Okay, okay, I copy-pasted that one :)

Just to be clear, we're talking about the other players' connections, right? You're implying the server doesn't interpolate or extrapolate the other players' positions, right?

Good catch, I'll remove that.

Well, like I said in the OP, I wanted people like you to vet over my cfg file and teach me anything I haven't learned right.

As for interp and jitter... makes sense. If a packet comes 7.5ms too late, then there's 7.5ms of extrapolation to be done once the window runs out. With that said, if you know your jitter will never exceed JITTER, then:
ideal lerp = 1/cl_updaterate + JITTER.

Like you said before, high jitter from enemy scouts leads to extrapolation happening for those guys. Can you explain the mechanics of that?

Okay, then let me revise my advice:
sv_mincmdrate 66
sv_minupdaterate 66
sv_client_max_interp_ratio 2

The thing about the high interp that gives me an advantage, I noticed pubbing as a heavy, is when I get the jump on them. I get a nice fat advantage as they run away behind cover.

So anyway, what else should I read to understand Source networking as well as you do?

for your cfg

rate 100000 is overkill already
rate "500000" = equivalent of fucking dead corpse

cl_smoothtime 0.01667 // 16.67ms (1/60sec, set to 1/[fps of monitor])
broscience (so is fps_max = monitor*2+1 btw.) (and who uses 60hz?), just use 0.01 if you're using cl_smooth 1.

sv_client_max_interp_ratio 2 = unecessary and pointless when they can just set a giant cl_interp number.

I could set it to INT_MAX to make you feel better :)

I do, because I don't have a few hundred at the moment to throw around for a new monitor.

And don't broscience me :)
How can you even tell if there's any difference between a sub-frame to interpolate and one whole frame? Assuming that the game is vsynced, just for argument's sake.

This clamps what the client sets. It'll mean that the client can set whatever high number they want, but lerp will be upper-bounded to 2 * cl_updaterate

We should have a FAQ for this to avoid having to dig old topics to get the answers again

It'd make nice tldrs for scrubs like me that know nothing

I mean i dont want to ask stuff that probably has been answered million times

rate 903468349634908 > 500000 amirite?

that's what makes it broscience. you can't assume the games framerate is in sync with the monitor hz because it won't be. no one uses vsync because its terrible.

I would imagine there's other issues but we don't even need to get into them to know it's a bad setting.

are you saying 2*66 = 132ms or 2*15.15 = 30.3ms?

>doesn't cl_interp_ratio merely multiply your cl_interp by that number

No, it uses the higher value between cl_interp and cl_interp_ratio/cl_updaterate.

Sorry if you had just misspoken.

>the settings it means are cl_interp_ratio 1, cl_interp 0.033

Technically, cl_interp_ratio 1, cl_interp 0.033 means cl_interp 0.033 and ratio 2.2 also means cl_interp 0.033.

>Since this just defines the max rate, what's the harm of overkill? The server will clamp it, won't it?

There can still be esoteric bugs left in the engine.

>You're implying the server doesn't interpolate or extrapolate the other players' positions, right?

What? How can you even get that from what I said?

>If a packet comes 7.5ms too late, then there's 7.5ms of extrapolation to be done once the window runs out.

Misleading/wrong. It's not 7.5ms of extrapolation to be done, it's 1/tickrate+7.5ms window that extrapolation will take place. The engine works in frames, not spans.

>Like you said before, high jitter from enemy scouts leads to extrapolation happening for those guys.

What? It's not just high jitter from enemy players, it includes your connection to the server too; that's the most important and controllable part. Don't even get me started on how messy Source input prediction is. That's a whole other 10 page topic worth.

Just increase interp enough that you're safe. A ratio of 1.1 or 1.2 is usually perfectly fine.

>sv_mincmdrate 66
>sv_minupdaterate 66

RIP literally anyone who wants to play on a poor connection.

>broscience

lol indeed

>This clamps what the client sets.

It doesn't clamp cl_interp. That's the whole problem. People can have as high of interp as they want. Like I said, source doesn't actually have enough restriction settings to be meaningful.

1. Sure, why not? It doesn't really matter

2. That sv defines the maximum lerp clients can use. 2 * 15ms = 30ms max lerp with that setting, regardless of how it's set (cl_interp vs cl_interp_ratio)

3. Units, bro. Units. 2 seconds * 66 ticks/s gives 132 ticks, which means nothing in this context. The second one is the one I'm talking about.

It doesn't define the max lerp clients can use. It defines the maximum for that setting. It doesn't actually restrict cl_interp. It's even right there in the variable name.

I'm sure we can reach a concensus friends. what settings do we need for 120/144hz users who don't use vsync? assume
good internet because nobody here should be playing on dial up.

is there a discrepancy in settings because esea forces cl interp ratio 1 and wareya is pushing for interp ratio greater than 1.1?

no just raise cl_interp since esea can't cap that (my net config at https://dl.dropboxusercontent.com/u/1811521/interp.html has cl_interp for each ratio)

monitor doesn't matter as long as your interp is high enough to not cause constant extrapolation, tf2 doesn't run at 60 ticks anyway and even if it did a 60hz is probably 59.94 instead.

Minor point, but trust me on this, it's not 59.94 either. It can be anywhere between 59 and a little above 60, depending on the pixel clock and timing parameters.