I assume this guide was made by you, right?

https://dl.dropboxusercontent.com/u/1811521/interp.html

Why does it not mention once that 2+ packets in the buffer are necessary for hitscan, and 1+ for projectiles? Instead, you give your settings in terms of "hitreg"? How about something like "Use cl_interp_ratio > 2 for hitscan classes, use cl_interp_ratio > 1 for projectile classes"

> there are "perfect settings" that while not actually perfect do generally serve well for their purpose.
...I guess you've been busy yelling at yourself for giving out "reasonable" values in between the time spent writing posts directed at me?

> you're trying to do two contradictory things at once: Provide a useful config, and get people to tailor their settings to their specific needs

Those are mutually exclusive? Is the idea of them downloading my useful config and then tailoring it to their needs so strange?

> if someone would bother to change their cl_interp to match their jitter on a particular server, they would understand to change any settings that get in the way.

The idea of having all relevant network settings in one config with explanations is strange to you, too? If they bothered to change cl_interp, don't you think there's a slight chance they knew what to set it to thanks to my config??

> Getting people to tailor their settings to each last server they go to is so obviously useless

Talk about beating a dead strawman. Knock it off already. It's not insane or ignorant or whatever you want to call me to say that there's a reasonable jitter amount that is 99th percentile for all servers in your region. Jitter is so wildly unpredictable that you can never set an upper bound and be confident it'll 99% of the time never exceed that? I'm tired of explaining this one.

> At the end of the day, all you can do is provide a common config, where you just end up with cl_interp_ratio 2.2 (for hitscan) again.

And I have! Isn't that great? Here's the link again: https://raw.githubusercontent.com/athairus/tf2-network-cfg/master/network.cfg

> cmdrate 66
> updaterate 66
> interp 0.033
> interp_ratio 2.2

> glhf

Something something what if jitter was higher than .2 / 66 something something
Something something bad advice one size fits all NOT something something.
Something something as long as athairus isn't the one who suggests it it's cool something something.

> Then why are you distributing a config in the first place?
Because there's more than just lerp in this config file?

> group of favorites, a finite set.

> literally only plays on their own server
> who play on exactly one server

> you're just attracting people who don't know any better with the fact that you made a detailed comprehensive config
I have to put SOMETHING down. I could leave everything commented out, of course.

> You basically expect everybody to change their interp for every single server they go to. That is downright insane.
I'm expecting the user to find out what the worst jitter they get is among that group and set their lerp accordingly.

I get the feeling you're misunderstanding me. These are reasonable defaults I set. I'm assuming that a person who doesn't touch the defaults didn't because they don't have to. Why? Because they've discovered their jitter is <7.5ms no matter which of their favorites they're on.

> Jitter is not something you can measure for your connection at large. Every single routing hop adds jitter. You'll get varying amounts of jitter to any different server you connect to. Treating it like something you can permanently quantify reeks of networking ignorance.

I'm going for the common case here. The servers you play on will each have their own max jitter, assuming the route between you and the server doesn't change.

> You want to add more than is needed. Period.

If that were true, we'd all be using the default 100ms lerp. I'm trying to use the absolute minimum I can get away with and so should everyone else.

> Someone who's willing to follow instructions to reliably follow complicated errorchecking instructions time they connect to a server

Once again, most people have a group of favorites, a finite set. I'm expecting the user to find out what the worst jitter they get is among that group and set their lerp accordingly.

I've changed the interp in terms of ratios now, I'm assuming your jitter, no matter what server you go on, will never exceed 7.5ms. What do you think?

First off, I haven't encountered a single pub server that clamps cl_updaterate below 66. And what comp server owner in their right mind would do so?? If such a server existed, I don't expect it to be the tier of server that having fine-tuned comp settings would even matter on.

Again, I picked cl_interp to be the way to set lerp because it makes calculations simple for the user. Just add your jitter to my recommended values. If they used cl_interp_ratio, they'd have to calculate their jitter as a fraction of the assumed cl_updaterate for each alias... otherwise they'd be adding an extra amount to the buffer size that is totally unnecessary.

Checking what update rate you're getting is as simple as net_graph 4. I'm making the assumption the user will be willing to do THAT if they care enough about network settings to use my config.

Well, the alias for hitscan with a value of 35ms is for servers with an update rate of 66, that's in the name. If you were on a server that clamps to 40, you'd want to use the alias for 40 ticks.

Wasn't that the point for projectiles (the only aliases that go that low)?

I was under the assumption:
hitscan: 2 / cl_updaterate + jitter
projectiles: 1 / cl_updaterate + jitter

Should they be 3, 2?

I chose option A because it's a simpler calculation for the user than to have to figure out 5ms jitter as a fraction of 1 / cl_updaterate

?

But I set it to -1 :(

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

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.

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

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

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

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

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

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