try refunding it anyway

matchmaking on custom maps confirmed

>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

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

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

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

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

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

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

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.

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.

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.

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