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

?

if you have ~35ms interp and go onto a server with an updaterate limit of 40 then you suddenly have less than two messages of interp, and begone is jitter correction.

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?

What are you even talking about? ~35ms interp is the one for hitscan. When you go below two messages with hitscan settings you lose jitter correction. So yes the hitscan settings are also broken on updaterate capped servers, not just the projectile ones.

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.

You don't know what the server is doing with the update rate. People won't bother to go into console, check the value, etc. Even worse, do you really expect people to use different settings for different servers? Aren't you talking about ease of use?

The easy solution is to be redundant. There's nothing else you can actually reasonably do.

how cool would it be if source scripting allowed for conditional statements? so many possibilities

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.

>First off, I haven't encountered a single pub server that clamps cl_updaterate below 66.

I definitely have, several times.

Comp servers are not the only servers that exist and could reasonably be more non-comp players that use compeptitive customization than there are comp players.

>Just add your jitter to my recommended values.

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.

>otherwise they'd be adding an extra amount to the buffer size that is totally unnecessary.

You want to add more than is needed. Period.

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

Someone who's willing to follow instructions to reliably follow complicated errorchecking instructions time they connect to a server is sure good enough to do everything themselves as long as you tell them how. You're insisting on tailoring something for such a highly specific kind of person that said person doesn't exist. Go ham or go home. Fix your settings. There is literally nothing to lose by adding ratio values.

my net_graph mostly shows values of ~67 rather than 66 (fluctuating between slightly less than 67 and slightly more than 67).
so.. what/why is that? it made me figure that these servers used 67 in stead of 66, but i guess i'm wrong there as well :x

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

>I'm going for the common case here.

There is no common case. Every single last person's connection is different.

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

Have fun with giving people a config that gives them bad hitreg.

>Once again, most people have a group of favorites, a finite set.

Who is this "most" person? I don't know of anyone who literally only plays on their own server. The only people I know who play on exactly one server are 24/7map cancer pubstars.

>I'm expecting the user to find out what the worst jitter they get is among that group and set their lerp accordingly.

Then why are you distributing a config in the first place? According to what you're saying, you're clearly not helping the people who are going to write their own settings; you're just attracting people who don't know any better with the fact that you made a detailed comprehensive config.

You basically expect everybody to change their interp for every single server they go to. That is downright insane.

>I'm assuming your jitter, no matter what server you go on, will never exceed 7.5ms. What do you think?

Ridiculous.

>my net_graph mostly shows values of ~67 rather than 66 (fluctuating between slightly less than 67 and slightly more than 67).
so.. what/why is that?

TF2 runs at 66.6666~ ticks per second (200 per 3 seconds). If the display rounds to an integer it will show one or the other depending on what the engine is doing at the moment.

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

>I have to put SOMETHING down. I could leave everything commented out, of course.

You could put something down that works as a reasonable default.

>I'm expecting the user to find out what the worst jitter they get is among that group and set their lerp accordingly.

Their worst jitter will change over time because routing has nothing to do with anything that will remain static like "their ISP" or "the IP of the server they go to". Even to a single server.

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

Oh, I get it. I'm trying to tell you that 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. The resistance to including ratio was particularly ironic, because 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.

Getting people to tailor their settings to each last server they go to is so obviously useless. 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.

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.

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

Because I wrote this literally over a year ago (maybe even over two) as a fixed resource for dispelling hitreg boogeymanning. It's not technical documentation and it's not necessarily complete. It has a fixed topic.

I cannot fathom why you're trying to point this out unless you're going for some ad-hominem bullshit. I'm giving feedback on your network config, just like you stated to do in the OP.

>Those are mutually exclusive?

YES! If you think they're anything but mutually exclusive, you have no idea how users actually think!

>Is the idea of them downloading my useful config and then tailoring it to their needs so strange?

When you get to tailoring it for their needs you had sure better go further than "Come up with X esoteric value and add it to your interp". You would do a lot better to write a networking diagnostic utility that generates a config for people and executes it before they join a team. Of course, that's actual effort.

>The idea of having all relevant network settings in one config with explanations is strange to you, too?

Considering that the explanations give the impression of being necessarily correct despite giving misadvice like "NOTE: If you (practically) never lose any packets, then you'd pretty much be okay with lerp = 1 / cl_updaterate (=66) for ALL CLASSES.", not to mention that they're ridiculously long and full of jargon that users will not actually understand properly, yes.

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

Or you could put out a networking essay to replace all of the incomplete and misleading ones that already exist, wouldn't that be useful!

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

This literally retorts nothing that I've said about how telling people to "base their settings on their jitter" is useless. If anything it only compounds how ridiculous it is to tell people to bother doing so.

>And I have! Isn't that great?

Sure! It really is! Now you can stop acting mighty and not pretend like the earlier half of this argument didn't happen!

>Something something what if jitter was higher than .2 / 66 something something

Something something completely missing the point of "self-aware turnkey solution"

>Something something bad advice one size fits all NOT something something.

Something something pot kettle black

>Something something as long as athairus isn't the one who suggests it it's cool something something.

Something something ego

I did not expect a networking thread to get this heated

> Of course, that's actual effort.

The subtle little jabs you've added to your comments in this thread don't help to keep things constructive. I'm not claiming that I'm innocent of them, but let's both just take it down a notch, huh?

> Considering that the explanations give the impression of being necessarily correct despite giving misadvice like ...

Something I missed when I was trimming earlier based on what I learned so far. It's gone.

> not to mention that they're ridiculously long and full of jargon
> Or you could put out a networking essay

Why not both. Handy to have explanations in the same file as you edit.

> This literally retorts nothing that I've said about how telling people to "base their settings on their jitter" is useless. If anything it only compounds how ridiculous it is to tell people to bother doing so.

Here's the way I see it: play on your favorite servers, notice how high the jitter goes
Server 1: 4ms
Server 2: 1.5ms
Server 3: 5ms
etc.

Take the max, add a little extra (or double it, why not) and that sounds like an entirely reasonable value. Do you have a better alternative?

Is having interp ratio 1 why I go through enemy players when I bump into them on na servers or is that unrelated? Normally I can bump into players while strafing on european servers to jitter my own model and make me hard to hit but if I try it on NA servers I literally just spaz through them.

listen here yeah? my interp is better than your interp motherfucker

Sorry, I'm confused. e.g. for hitscan
Should I use either one of these:

> interp 0.033
> interp_ratio 2.2

or both together?

Both because it helps keep you from having worse hitreg on misconfigured servers

Ok thanks, but say if you were certain it was a correctly configured server is that the optimal setting anyways?

Yes there's no harm in using both settings at the same time

@Wareya In that guide you say you wrote an year ago, that "Soft" interp settings for hitscan oriented gameplay you advise cl_interp 0.05 / c_interp_ratio 2, but whenever people ask you what's the optimal config for an ideally well configured/ fast reliable connection, you answer cl_interp 0.033 / c_interp_ratio 2.2, that would match the "Normal settings" of said guide.

Which one (hitscan oriented) would you say nowawadays works the best? It's such a small fine-tuning I'm not sure I could blame it on the settings itself rather than my aim. Thanks!

hey on the bright side the next time someone brings up interp, we can just link this thread.

tldr!

should I use this config? y/n

>Which one (hitscan oriented) would you say nowawadays works the best? It's such a small fine-tuning I'm not sure I could blame it on the settings itself rather than my aim. Thanks!

It's definitely a small fine-tuning.

In the old config it doesn't end up mattering unless you go on a server with clamped updaterate. Knowing that this was a "problem" with my old config is the reason I insist on using a correctly matching ratio for the cl_interp now.

It won't affect anything on competitive servers, if that's what you're asking. But 2.2 is better because it behaves the expected way on clamped servers.

The latency starts getting nasty above 50ms which is why I considered it a reasonable tradeoff to use 0.05 and ratio 2 at the time. In that case it would always use 50ms interp unless the server clamped updaterate at a value below 40. But 2.2 on 40 only results in 55ms, which is 5 extra ms, which is nearly imperceptible when you're already at 50ms, and the setting is meant to be as smooth as is reasonably possible anyway.

That was a good question!

#89

It's oll korrect