cl_interp 0.0182; cl_interp_ratio 1.2 or cl_interp 0.0166; cl_interp_ratio 1.1

>can it hurt to set cmdrate or/and updaterate to anything between 67 and 100?

Can it help: no

Is there a chance that it could hurt if valve has a related bug: yes

99%+ of servers cap cmdrate/updaterate at 66 anyway.

Even if they didn't you wouldn't want your client to think that it's above 66.666~ (the actual tickrate of the engine)

cmdrate 66
updaterate 66
interp 0.033
interp_ratio 2.2

glhf

>You don't have to talk down to me

How is that talking down to you? Metaphors make domain-specific information easier to understand.

>Maybe a form that has spots for max jitter (to affect lerp), upload/download speed (rate and command/update rates), and any other important factors.

Forms are fine but most people don't even understand what "jitter" means.

>Just to be clear, you're saying that for hitscan weapons it's ideal to have at least 3 packets in the buffer at any given time so jitter correction can do its job, while for projectile weapons, 2+ will suffice?

Yes, in short. Not like I know whether jitter correction actually works correctly, though; I'm making a lot of "I really hope valve didn't do something incredibly stupid" assumptions here.

>Interesting, so I assume the engine is taking that late packet and interpolating it as if it came in when it was expected to, which can only not screw things up if the packet was not already being used for interpolation.

I'm not going to explain this in detail but basically jitter causes something where even if you're interpolating you can be interpolating something behind or ahead of where the server thinks you think it is. And if you try to correct for this jitter with less than two ticks of time (meaning three messages) in the interpolation buffer, you get more artifacts, because you're changing the data that you're interpolating over while you're interpolating over it.

>And this is all good for hitscan stuff only, I assume?

What? You mean having jitter correction? No, that's good for everything generally speaking, it's just that there's this nasty thing called "latency" that you need to add more of to make up for jitter, which is bad for things that aren't lag compensated such as projectiles.

>Soft message timing correction? What's that?

It's not "a thing". It's just having message timing correction that isn't "perfect" and manual. Think of a series of messages as a bunch of pennies in a line on the table, now you keep the first and last ones in place and make the ones in between equidistant. Unless valve decided to implement the interpolation window in an incredibly convoluted way with every single individual message time intact, raising your interp will necessarily smooth out the distance between each penny on the table.

(edit: By the way, even though that's assuming they didn't take a convoluted approach, it's still supposing them to be in a bad situation where they aren't properly fixing message timings.)

>I'm assuming you've done a lot of work on some Source engine mod, right? Where did you learn all this?

Lots and lots of caffeine, argument with my superiors in development, and working on networked game engines.

Of course, I'm amateur because nobody but an amateur would care so much about such highly specific things.

>your player position appears lag compensated ahead by an amount relative to your latency+interp.

Just going to say: No. Interp has absolutely zero effect on your viewport.

Also, the discrepancy he was talking about wasn't implying predicted rockets at all. He was just saying that the rockets are further in the past just like the players. It increases the discrepancy from your viewport's predicted state.

Unless he like totally went off the deep end and started spewing bullshit that happens to make sense if you give him the benefit of the doubt and fix his words.

Discrete message timing correction. Can't do it without at least two frames of interpolation buffer. The reasons for that restriction are long and many, but basically, if you try to correct the timing of messages when you're under two messages behind the server, you will cause shifts in interpolation speed in the middle of interpolation. This is even more problematic than it sounds.

Worst case scenario, being more messages behind also gives a soft message timing correction unless valve decided to implement the interpolation buffer in the most convoluted way they could reasonably do so.

The whole entire statement I made was about projectiles.

Think before you try to point someone out.

>Can you come up with a reason to push it any higher, like justifying two ticks' worth or more for hitscan?

Yes: Higher interp always results in better hitreg. Also, if you lag out, you're going to want that extra interp anyway.

It's true that it's a tradeoff, but in the span of a single frame, when you're already playing online, there's no reason to push it just so you can be one more frame ballsier with dodging rockets. That's just asking for bad gamesense.

>Don't worry about leading shots, this extra time is compensated for server-side along with your ping time. (new)

THIS DOES NOT AND NEVER DID APPLY TO PROJECTILES IN TF2. PROJECTILES ARE NOT LAG COMPENSATED. CHRIST.

>wareya, could you explain what you meant about other scouts with high jitter causing extrapolation on your client?

In the first place I never said anything about the jitter of other players. It has an effect but it's nowhere near as important as your own jitter.

"Enjoy your bad hitreg against scouts on connections with high jitter." is not "Enjoy your bad hitreg against scouts who are on on connections with high jitter."

>If you're bothering to change your cl_interp manually you should always keep the cl_interp_ratio at 1 so you don't have to worry about it whatsoever.

This is wrong because the server can change your updaterate as well. Go onto a 32man server that limits updaterate to 40 and suddenly you're really going to want that cl_interp_ratio.

>Note that cmdrate shouldn't change from the server's tickrate, it doesn't really have anything to do with interp iirc

It affects the way that the server queues your input commands. That's about it.

>I don't see how this can be, rockets are not client side.

The fact that they're not client side is literally the only reason in the entire world that could make interp matter to them. He was referring to the fact that high interp increases the discrepancy between your inputs and your projectiles, because projectiles aren't predicted

High interp on rockets also makes them disappear mid-air in front of the target they hit, or rather, the explosion events are not delayed like the positions are.

The REAL problem is that interp effectively adds latency to enemy player positions/movements, which means that high interps = you're further in the past = it's harder to react in time to what they're doing. Rockets aren't lag compensated. You already know this, though; this is just here for semantic completeness.

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.

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.

>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.

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

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

>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.