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

This was already solved on Discord. They forgot to set their rates using the rate generator.

Hi, what version of the config did you install? 6.9.0?

Profiles are in the works.

New format was revealed for this week's Summer Skirmish. Pro players queue up for pub solo matches and get points for the tournament based on kills and if they win.

https://www.epicgames.com/fortnite/en-US/summer-skirmish
https://www.epicgames.com/fortnite/en-US/news/summer-skirmish-week-2-standings-friday

Yes, the checkbox is to say "i want to set this setting manually and override what this module sets", and then the toggle is what value you're setting the option to.

Yes I saw, I'm still looking into it.