Don't use this, it's broken and unmaintained at the moment, unfortunately.

I could calculate the rates manually myself. niko, could you tell me your up/down speeds?

These files were moved to the app folder. But you shouldn't be messing with them anyways, you can use tf/cfg/custom.cfg and tf/cfg/modules.cfg to override the app.

are you using mastercomfig very low? that disables a bunch of hud elements

add a _c to the class file name.

Try messing around with m_limitedcapture_workaround and m_rawinput

GAME 5 WOOOOO

liquid are gonna do it

Well what are your settings?

Please use r_lod -1 so that models in the distance have lower LODs!

You need to rename your class configs to have a _c. So like scout_c.cfg.

User info cvars are transmitted to the server. You can't create new cvars, only the user info cvar entries with setinfo.

Some of the commands removed were not doing anything in recent builds of TF2 and was verifiably able to test their uselessness. Others were those being set to default valies that were not flagged to be archived.

setinfo creates cvars with the user info flag. All cvars with this flag are sent to the server on join and cvar updates, which can bloat network communication and slightly increase client/server memory usage.

I'm so glad that this has come up. It's been a problem in our community for far too long for far too many people, including me. I'm happy that others have been brave enough to speak out and it's really encouraging to me, but I'm not sure if I'm ready yet to speak here about some of the harassment I've faced from some members of our community. Maybe I'll share eventually, but regardless, I hope that we are able to come to an agreement and stand in solidarity against toxicity. It's just common sense, and it will help us grow if we are open, friendly and inviting to all, new and old.

Because, I am saying, in an ideal scenario where the server and networking are perfect, where 15.2ms can be used with no downside, 17ms wouldn't be that big of a deal anyway since the position delay from interpolation is from 2ms of movement (which can't be significant due to player velocities in TF2).

However, we aren't in a perfect scenario. You have server framerate drops, jitter, occasional packet loss, etc. That's where the extra 2ms makes a difference (and it's a very conservative difference, honestly it should be a higher lerp) vs 15.2ms.

I assume by 0 lerp you mean 15.2ms lerp for TF2, as discussed before.

Who says that they couldn't play better? Just because they're good (way better than you or me), doesn't mean their networking settings aren't bottlenecking them.

Also, your logic here doesn't really make sense. If all pros are using the lowest interp, then wouldn't that make it a non-differentiating factor?

And yes, again, you aren't actually giving us anything to work with here, just arguments that are becoming more and more nonsensical.

You're conflating a few issues. Let's go through each of them.

You ignored everything else in that material saying why the lowest interp (15.2ms) is not usable. That's what I was referring to.

Your perception isn't the thing that matters here. It's the fact that you made an argument (10ms interp is too high/0ms is better) based on a false perception, and despite being corrected, you continue to make that argument. Your feelings are entirely based on placebo with no actual reasoning and cause you to use harmful network settings. And despite numerous prompts from Degu and me for you to bring up other reasoning, based on networking logic, you instead essentially say lol a bunch as your argument.

There is no 0 lerp setting in my config. You have to realize that interp is determined from cl_interp_ratio and cl_interp. The greater of the two values is used. So, cl_interp_ratio is set to 1, which means, at a 66 update rate, you get 15.2ms lerp.

That's because on a local/LAN server, the client and server are synced in a different way, so none of that matters. Again, if you understood what interp is (the time it takes to smooth between server updates), you would know that 0 interp would make everything jittery and jumpy with no continuous motion.

The difference here is that the net_splitrate was based on logical intuition (server/client using the same packet code), rather than placebo prone feeling. I just could not demonstrably prove with absolute 100% certainty that the client was using that packet code path, as even with decompilation, the networking paths used are not clear due to legacy code/dead code that I can't really isolate.

The larger problem here is that you're comparing something that is harmless if it doesn't work and beneficial if it does work (net_splitrate >1), with something that is harmful if it doesn't work and harmful if it does work (interp <=15.2ms). Perceived benefit in my case has no negative impact on the conclusion, as there are no negative effects, yet in your case, perceived benefit on something that demonstrably with 100% confidence does not work, is actually harmful.

You're ignoring everything else written, so you don't understand what "as possible" means. Read about variance and packet loss and notice how the conclusion they reached was not 15.2ms lerp in that config.

I already clarified that net_graph was inaccurate, no need to hound degu over it for 4 more posts.