I mean, given mastercoms' and waldo's testcases, I think the logical conclusion to make is:
- projectiles by themselves are not different with 0 interp
- projectiles appear ahead of you in 0 interp but behind you with normal interp
- in normal interp, you don't appear ahead of where you actually are serverside
- logically, in 0 interp you are visually behind where you actually are serverside

There may be some further testcases that can shed more light on this or expose any currently unknown effects (and you are free to figure out those testcases) but this seems pretty convincing to me. If normal interp is always about the same or maybe a bit behind your serverside position, and 0 interp is even further behind than that, it stands to reason that 0 interp is actually unintuitively worse than normal.

There seems to be a culprit in the code that causes this behavior as well:

https://media.discordapp.net/attachments/439606056457338881/747073822519459870/unknown.png

(if your interp is too low, then this expression won't evaluate and your movement will be a tick behind -- credit to mastercoms)

As far as the current understanding of the game is, the exploit doesn't help or is actually worse for all the reasons given in this thread so far (ping, accurate player positions, etc). If you find that's easier for you then alright, but it seems to be because your position is slightly behind where it actually is, and regular 15.2 interp is the closest you'll get to your actual position. Using a higher interp might be able to get you the same delay you've grown accustomed to.

In exchange for not having these settings available, the patched exploit means that cheaters don't have as much room to abuse backtracking. And I get why some people don't like that the settings they're used to are suddenly not possible, it does suck. But as someone who made mods that got patched because they relied on exploitable methods (old clean tf2, because someone released a wallhack on gamebanana that used the same technique), it happens and you'll live -- something like this is overall an improvement.

I really want to call out this behavior because this is what drives away modders and makes people want to stop associating with the tf2 community. Someone tries to help the community at large, and gets met with one step away from direct insults. Someone tries to get a better understanding of how things work, but because it's not in-line with how things have always been done, they get met with hostility. Someone (with a track record of saying conventional settings are actually harmful or mostly placebo, considering how many launch options people would swear by that turned out to not actually exist in the first place) says a conventional setting may actually be harmful or mostly placebo, and then gets jumped on with "no you're wrong, I don't know any more than that and don't want you to look into it more, but you're wrong" instead of any useful conversation.

Like okay, you think mastercoms is wrong and you have a testcase that seems to show differently for whatever reason (if projectiles appear the same in mastercoms' testcases, perhaps the difference is in player movement?). What's hard about saying "hey what about x testcase, this shows a difference and seems inconsistent with your other test case, perhaps there's more to it" instead of "stop arguing in bad faith, here is a different testcase with no further elaboration or exploration, you should stop making yourself look like an idiot".

Mastercoms is going through everyone's testcases trying to figure out what's different, trying to develop new testcases to isolate variables, reading the sourcecode to try and determine any potential causes of discrepancies, and genuinely trying to further the understanding of the game. And if she's wrong, cool, we will all have delved deeper into understanding the source engine and collectively know more. Arguing with "hey nope, you're wrong, stop trying to figure things out" is the least constructive approach to take.

Like is it so hard to just

Are there any circumstances that it reliably fails? I could only get it to fail when I used too small of a wait, I thought 5 would be sufficient but maybe not

Haven't tested, does pinning or anim locking fix it?

There isn't a standard way, but you could probably do something like edit the MenuOpen event to start a loop that animates health/ammo, and then run "voice_menu_1;slot10" inside your class configs so that MenuOpen is reliably triggered whenever you play. If the bonus/dying animations affect the same stuff (ie. both do stuff on fgcolor) you would have to stopevent the passive loop on pulse, and then startevent the passive loop on pulseend again, but it should all be doable.

The alternative would be to set "HealthDeathWarning" in hudplayerhealth.res to "1.0" so that the HudHealthDyingPulse event runs whenever your health is less than max, skipping the need for adding anything to class configs -- but is overall worse since it doesn't work when you first start playing before you've taken damage, and means you can't have a low health animation.

It's a neat idea and I'm interested in the results

The BonusPulse event runs when you have more than your regular amount of health. The opposite, DyingPulse, runs when you have less than whatever HealthDeathWarning in hudplayerhealth.res is set to (in percentages). They then call a loop so that they keep repeating until their PulseStop events run, when your health is neither too high or too low.

These are called in code and there isn't any real way to modify them, other than what was mentioned.

it can be removed the same way as nohats does things. I would just find out what the capture point holograms' models are and then copy over one of nohats' null vtx files.

I'd just recommend learning how to do it yourself. Hud editing is fun and knowing how to do it means you can play around with it on your own.

As far as I can see, to turn the new into the old, all you'd have to do is:
- move the teamcolored healthcross panels into a line below the health, and copy that over for the ammo
- remove the outline stuff for health/ammo numbers, and just keep the shadow
- use the minmode stuff for the charge meter

There might be more since I'm just looking at the screenshots on github, but overall it'd be a pretty good beginner's mod.

OCaml shouldn't be too bad once you solve a few problems in it. Functional programming languages like the ml family are all different than imperative / oo languages, but I find once you understand how they want you to think of the problem you're solving they aren't very bad. Main thing is to understand you're not defining a step-by-step process, you're defining a transformation.

Of course this all depends on if you're doing a comparative languages course (very baseline level of understanding, can honestly just do the bare minimum and then focus on other languages) or a compiler course (very in-depth).

seems to try and do multiple things (graphics cfg and stuff like null-movement) all mixed together and not clearly separated. I'd recommend separating them out and trying to be more focused with it, like:
https://github.com/mastercoms/mastercomfig - very well focused on doing everything graphics
https://github.com/JarateKing/jarconfig - focused on many gameplay scripts

---

As for some specific stuff:
do I use "autoexec_performance" or "pretty_gfx"? There's a lot of overlap between them, but there's also a lot of stuff that is in one but not the other, and it's not really clear what's what.

// Net graph script for TAB
alias "+netgraphscores" "net_graph 4; +showscores" // can change to 1 for fps improvement
alias "-netgraphscores" "net_graph 0; -showscores"
bind "TAB" "+netgraphscores"

I'd recommend going with something more like: https://gamebanana.com/scripts/9167 - the scoreboard script you have is a pretty common one but it can be done better
I wouldn't have a bind like that in the middle of the script where it's hard to find, as well. If I didn't have scoreboard on tab, I'd be very confused why tab randomly became scoreboard using this script.

incrementvar mat_managedtextures 0 0 1

incrementvar will increase the setting between a min and a max bound. The bounds here are 0 and 0, so this should always set this to 0. May as well just be "mat_managedtextures 0".

fps_max 300 // can't tell difference between this and 0

fps_max 0 disables the frame limit. 300 puts a cap at 300 fps, which is obviously not going to be different if you don't get that much fps but some people do and a 300 cap is very different from uncapped.
There's a decent bit of valid debate around whether this should be 0 or 995 or whatever you can reliably get stable (and some wrong arguments about 2x your framerate or whatever) but in general this isn't the sort of thing that's just found in the middle of your cfg (in autoexec_performance, it is at the bottom of pretty_gfx).

I haven't given it a thorough lookthrough (I didn't read through all the actual graphics settings and I'm not the best to comment on them) but in general this cfg doesnt appear to have any clear direction it wants to go in. Seems more like a hodgepodge of random settings from other things rather than actually trying to improve on what's already out there. I don't mean to put it down but cfg's are among the hardest thing to make good in tf2 and require a lot of effort to be decent, and I'd recommend trying to deeply understand what other people have done and how they can be done better before working on your own.

Yeah, if you look at what processes are actually causing the high latency interrupts, it's mostly networking / ports / graphics stuff that you'd expect to spike (especially when we're talking about <1ms spikes).

Interrupts should only ever really be a problem if they start distorting audio (what LatencyMon is intended to diagnose), or if you want to squeeze out that extra couple fps.

Seems like a compiled list of other people's advice, not necessarily based on any deep insight on the author's part. Some of the advice is good, but some is based on a misunderstanding that's stuck around for a while.

ie. Timer resolution is something you can set and it does affect tf2, but it shouldn't improve tf2's fps any -- afaik the only waits that appear in tf2 is for the fps cap (and the same is true for most other games too), and that just means when you hit your fps cap your frame times will be more precise (it has a similar mean but smaller standard deviation than without changing the timer resolution). Which really doesn't matter, slightly less variation in your fps won't do anything.

The main advice is to reduce interrupt-to-DPC latency, which has a small impact. If your DPC latency was 1.0 microseconds and you reduced it down to 0.5 microseconds, that's roughly equivalent to increasing fps from 60 to 66 (using some quick testing, you'd have to check your DPC count to calculate it for yourself). The guide mentions 0.4 being good but 0.3 being ideal, and that difference is about the jump from 60 to 61.25. All in all we're talking relatively small gains.

I'm not recommending against the advice, but if you're going to great lengths for any fps increase you can find, you can get bigger gains by running tf2 under linux where most of this guide doesn't apply anyway.

The input latency in the guide is measured in microseconds, which (when you consider that there's usually a few thousand interrupts a second) will translate to some amount of milliseconds every second. Not much, but it's not next-to-nothing like nanoseconds would be.

Ah yes, the real cause of racism is that white americans are afraid of loud noises.

The whole "trust me I'm scientific, I posted one statistic and then extrapolated wild conclusions with no backing" schtick is a real stupid trend. It should be pretty telling that these types never cite their sources. Those statistics come from Project Implicit, and these are the the conclusions that they make in their paper Exposure to Racial Out-Groups and Implicit Race Bias in the United States (2015):

Any attempt to definitively say "yes this is why that is" is unscientific mumbo. The actual researchers' best estimation is:

Which does not suggest anything you're saying.

Mastercoms and I discussed this a bit and experimented with it, and I figure it'd be worth sharing results here. I went as far as writing a program to roughly mirror what tf2's fps_max does (same method for frame limiting, but no frame logic or threading or anything like that). The model could be improved to be more accurate, but it's good enough to tell if frames are consistent or not.

Compared to the expected frametime from fps_max, individual frametimes would vary anywhere from ~3ms slower (under cap) to ~1ms faster (above cap). Over time, these would average out to slightly lower than fps_max (<1ms under). These numbers depend on a few things (what you set fps_max to does change these a bit, for one), but it's a significant variation in any case.

This is alright for most of fps_max's uses, since most of the time you don't really care about this variation. But monitors absolutely do, especially when you're talking about "matching frames to monitor refreshes." fps_max 2x or 2x+1 is based off this idea, and the idea doesn't work out in reality.

TLDR: fps_max isn't consistent enough for monitors, don't use 2x / 2x+1 or any other fps_max based off your monitor refresh rate. Mastercom's advice of being slightly higher than you can get ingame is what you should follow.

You just need to keep your fps below 1000, so you can go closer than 800. I don't know the details of the problem since I've never gotten close to 1000 fps, but it might already be fixed, or it might still be a problem with the variations mentioned above (so something like 997 might be safest).

As mastercoms mentioned a bit, your load times are affected by your fps_max -- things load faster if they have to spend less time re-rendering menus. Ideally there'd be another fps_max for menus (like in csgo and dota) but there isn't anything like that in tf2 currently.

if you don't have anything fancy like gsync and you don't worry about overheating, uncapped will always give the least latency

any magic number (like x2 or x2+1) is based off the misconception that your frame renders will roughly line up with your monitor refreshes. They don't, and even a stable capped fps has very inconsistent frame times (they just average out to slightly below the cap, but individual frames can vary significantly), so you're gimping it unnecessarily.

Now if you do worry about overheating, or you really want a consistent capped fps for some reason, anything above 144 will be mostly fine, though increasing it higher as long as it's stable is generally better.

Mastercomfig doesn't touch model files itself, just some model locations listed out in a text file as easter eggs for events. For example: https://wiki.teamfortress.com/wiki/Saucers It doesn't remove much, but it's pretty harmless to have as a file, and stays updated easily.

Mods that actually nullify the model file itself (like this, nohats, cleantf2+, etc) can remove a lot of props / cosmetics. It's more powerful for modders but also more work and requires work to keep updated.