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.

What degu said. net_graph doesn't show you the server bounded interp, only the initial client side calculation, which is then changed based on the server telling your client to clamp your interp. If you really had 0 interp, players would be jumping around with no continuous motion, and you should realize that if you understood what interp did.

And pro players using something doesn't mean it's correct. Many people have misunderstandings of these commands and it's just what they've been playing with for a while. Many configs have clearly bad settings all over the place, like rate 60000, which is lower than the default rate of 80000, yet many pro TF2 players use configs based on those settings.

Please show me one YouTube video where it shows you need to lead targets with hitscan. With projectiles, it is a different story, and I think any demonstration you show with negative effects will have a super high interp to show the extreme effects. But as I said, there is no adverse difference in position within a few milliseconds due to max velocities in TF2.

It's obviously placebo in your case, if you say there's a difference past 10ms. The lowest TF2 can go is 15.2ms. There is a reason why interp exists, and why I have that recommendation. Extrapolation is much more harmful than interpolation, especially since you have server frame rate drops and variance regularly on most servers.

The latest version of the config has 17.9ms interp, not 21.

The server is aware of and accounts for client side interpolation latency, so the hitbox argument is invalid entirely for hitscan. And for projectiles, the difference of like 2ms latency does not adversely affect hits, as accurate trajectory is of utmost importance, rather than accurate position within 2ms, since projectiles have a travel time.

Those are low violence settings. Please turn on all violence_ cvars to 1 so you don't enable low violence mode, which enables this and other silly gib effects.

If you're using mastercomfig 7 with just modules and no custom settings, I just pushed a fix removing those violence_ cvars, as I had mistakenly kept them in while testing something.

Since all the game's voicelines use mp3 files, you can remove the miles library that Source uses for playing them. If you move bin/vaudio_miles to somewhere else (to back it up), the game will no longer be able to play voicelines, as well as music and some additional ambient sound effects.

If you want to restore the original behavior, just move vaudio_miles back to the bin folder.

I'm going off of memory here so this might not work, but I'm pretty sure it will.

edit, sorry the file name is bin/vaudio_miles, not bin/libMiles

Thanks!

This is an incomplete UI feature.

Not sure why that would happen.

I haven't found a good way to apply anti-aliasing settings.

Check tf/cfg/config.cfg and your regedit if on Windows (HKEY_CURRENT_USER\Software\Valve\Source\tf\Settings\mat_antialias).

tf/cfg/app/profiles/default/custom

mastercomfig 7.0.0-a.15