ya that's what I meant. :)

it can be misleading for some people is what I mean, not that it's wrong^
because he was asking about cl_interp_ratio being limited to 1 in ESEA, which is a different from the ratio 2.2 you're talking about

k thats what I thought^^

1. (rate) because you can lag/get dos'd from the server. If it uses that much bandwidth something is wrong and you don't want to let it.

2/3. (sv settings) I only asked about the calculation because I was confused when you said it limits your lerp. your post couldn't be right unless my math was wrong. I know I can use 100 lerp, 67 updaterate, on default sv_client_max_interp_ratio (5), but the math says 14.9*5=74.5ms.

so sv_client_max_interp_ratio can't limit cl_interp/lerp is what I was getting to

wareya, could you explain what you meant about other scouts with high jitter causing extrapolation on your client? Are you implying that the server does no interpolation on its part when the laggy scouts fail to send data to the server regularly?

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. cl_interp_ratio is a leftover from old versions of the Source engine where they removed the ability to set cl_interp manually and you could only change your interp by changing your updaterate (or messing with the ratio). The server-side restrictions actually used to be perfect but they never added any more after giving back the ability to change cl_interp manually again.

The reason why soldiers use low interp is because your client-side projectiles are delayed by your interp amount (ex: cl_interp 0.3 would delay your rocket graphic coming out by 300ms). If you use high interp values as as soldier, your client-side rockets will not exactly match where they actually are. I'm not 100% sure on this though (haven't checked into it since 2009).

The way I approach my network settings is as follows:

cl_cmdrate and cl_updaterate should always be set to the server's tickrate. (66 for TF2)
rate should be set to whatever your connection can handle (50k+ is typical these days)

If you want a truly optimal interp for your own specific connection, then go play a few games in your usual environment (favorite pub server/the usual server you play 6v6 or HL at the usual times), record them locally with OBS or whatever other software and leave net_graph open the entire time. Go through your games afterwards and watch your net_graph's packets/second and look for the lowest amount you get (typically in big fights). Set your interp based on that value.

example: Bob had a night of games with his team, skimmed through it at triple speed and found that the lowest packets/sec he got all night was 44, and he had no packet loss. Therefore he would set his interp at 23ms.

The other network settings (ex: smooth) don't really matter that much for 99% of people so I wouldn't worry about it.

I assume you're saying set updaterate/cmdrate's max to the absolute observed low to keep it consistent and smooth, right?

So, this is bupkis?

Just saying guys, if you're gonna contradict Valve's documentation, you'd better offer proof because I'm more inclined to believe them than you :|

That's also completely correct. There are multiple ways to change your interp. That's how I used to adjust my interp back in 2005-2006 when bad server admins would restrict interp_ratio but not updaterate. I'd be forced to run an updaterate of 45-50 to counter my own jitter because I couldn't change my ratio.

Nowadays though you can just keep updaterate at 66 and change cl_interp to whatever useful value you want (as long as it's not bounded by cl_interp_ratio), so I recommend that method instead. Note that cmdrate shouldn't change from the server's tickrate, it doesn't really have anything to do with interp iirc (been a while).

Valve has several mistakes in their documentation (which can be proven), but this isn't one of them.

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

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

> In the first place I never said anything about the jitter of other players.
To be fair, your sentence could be taken both ways...

Anyway, I'm revising my advice on lerp to this: the ideal lerp = 1 / cl_updaterate + (absolute max ping jitter). Can you come up with a reason to push it any higher, like justifying two ticks' worth or more for hitscan?

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

> // You can think of the interpolation buffer (lerp) length as additional time added to your ping. Don't worry about leading shots, this extra time is compensated for server-side along with your ping time. (new)
> // It's in your best interest to keep lerp as low as possible.

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

Calm down, friend. I was not specifically talking about projectiles.

The whole entire statement I made was about projectiles.

Think before you try to point someone out.

All right, let's talk about something else. How does a higher lerp lead to better hitreg? What's the mechanics behind that?

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.

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

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.

And this is all good for hitscan stuff only, I assume? Projectiles get that low interp because we need the fastest and least lag-compensated snapshots of the server's state that we can get?

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

Soft message timing correction? What's that?

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

im referring to

your own rockets are displayed in the same manner as an enemy rocket, as in they spawn and are tracked on the server and the server relays where they are to you. the server also relays where the players are to you.

I don't see how the discrepancy he describes is possible. I mean they may not appear where they actually are, but neither does anything else cause lag. the rockets you see are in the true position, they are correct relative to enemy players.

the thing that is not correct here is where you appear to be, the rockets will feel weird because they are being shot from your true position while your player position appears lag compensated ahead by an amount relative to your latency+interp.

(and that with the delay is why soldier sucks at high ping/interp)

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

> Think of a series of messages as a bunch of pennies in a line on the table...

You don't have to talk down to me, I'm a C programmer with a bachelor's in CS. Half the reason why I'm so interested in networked gaming is because a personal project of mine involves netplay between two emulators, and some (not most but some) of the principles I think apply here. This is me getting my feet wet.

As I look at your page, I can't help but wonder if you could give your advice in a more user-oriented way. 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.

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?

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

I'm so confused right now.
Did you guys come to a conclusion on what the ideal net settings would be for hitscan with a fast reliable connection?

cmdrate 66
updaterate 66
interp 0.033
interp_ratio 2.2

glhf

someone just get wav or chrisasterx in

can it hurt to set cmdrate or/and updaterate to anything between 67 and 100?
i was under the impression that any server with 66 would simply restrict yours to 66, and thus it wouldn't matter if yours were set to 67+
but reading through these posts, i'm guessing i was wrong?

You guys know there is actually a quote feature in BBCode, right?

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

what about projectiles ? or it stays the same ?

cl_interp 0.0182; cl_interp_ratio 1.2 or cl_interp 0.0166; cl_interp_ratio 1.1

Okay, so I've redone the interp section, adding handy aliases to put in your class configs:

wareya, I set cl_interp_ratio to -1 to get it out of the way. Because the final calculations for cl_interp involve jitter, I think it's best to not define it in terms of ratio, but to simply add max jitter to 1 / sv_updaterate.

But I set it to -1 :(

EDIT: So, that'll clamp net_projectile_66 and nothing else...

it makes all 66tick settings behave unexpectedly

- Have settings that break on partially misconfigured servers
or
- Have settings that work properly everywhere except for seriously misconfigured servers (both clamped ratio and clamped updaterate)

Take your pick