Hey setsul, I'm a bit confused on a few points and am wondering if you can clarify:

For possible cause 1, if it's determined at compile-time then shouldn't it be consistent?

For possible cause 2, it's true that storing 0.2 into an 80-bit floating point can cause this behavior, but why is it inconsistent depending on the system? I would've assumed that which instructions to use would be determined at compile-time, is this not the case? As well, you mention support for SSE2, but shouldn't essentially every processor used today support SSE2 (considering it was introduced by Intel in 2000 and became compatible with AMD in 2003)?

For possible cause 3, doesn't the snippet you provided for __ceill set the rounding mode and such, so this shouldn't be a concern?

I hope this doesn't come off as standoffish because I think we'd be better focused on figuring it out and hammering out the details than arguing about it, but I'm not fully following some of your points and they appear to me (in my admittedly poor understanding of the intricacies of floating point instruction sets) like they don't explain the observed behavior.

I've foiled your plans again, micwoj!

They are mostly fine. There's a few things I'd reword (saying logic is "Turing complete with restricted memory size" is not as accurate as saying "capable of forming DFAs") but the meat of it is identical, since scripting hasn't changed in years and the "state of the art" is the same as it was when I wrote the docs. The only thing I'd be tempted to add would be some of mastercomfig's conventions to slightly decrease load time, but in the grand scheme of things that's pretty minor and probably something that a program could handle anyway.

Sorry for this fix / patching being so late coming! I haven't been too active in the community and been busy with university and with work, so I haven't been putting in much time at all for tf2 stuff. I figured it was long overdue though so I made an effort to get to it.

The issues people have been having with resized flat textures should be fixed now, at least this is the case for everyone I've tried it with*. In addition, resized flat textures should appear flat** on sv_pure too, like the private flat textures mod that a few players have been using recently. I've also added the resized flat textures as a release for people who just want to download that, or if they're experiencing any more issues generating it.

Link for the direct download of flat textures here: https://github.com/JarateKing/CleanTF2plus/releases/download/1.0.0/flat_textures.vpk

* thank you members of the huds.tf and mastercomfig discord servers who volunteered to help on short notice, particularly Horse, jan, and Ta5k, in addition to the many other participants in other conversations about flat textures

** if you are close to textures you'll notice that they're not fully flat, but at any reasonable distance they will be. If you look at videos with the private mod, you'll notice the same thing.

Technical details:

• I was an idiot that used DXT compression for textures smaller than 4x4, when DXT compression works by dividing textures into 4x4 segments. Rookie mistake. I don't know why I wasn't getting the same issue on my machine, or why different machines seemed to have different issues. Switching to an uncompressed format (BGR888 and ABGR8888) should fix this. Unfortunately this means that if you choose not to resize textures, the filesize (and by extension load times and memory usage) will also increase -- it would be possible to optimize this for unresized textures but I don't think this is a dealbreaker, I'd wager most people will choose to resize.
  
• Making flat textures appear flat in sv_pure is a matter of enabling mipmaps, specifically what was done was setting the texture flag to enable mipmaps below 32x32. This does mean that if you look closely at textures you'll notice that they're not actually flat and instead are just resized down heavily (this has always been the case), but at a distance they appear / become flat (versus in the past where they would become grainey). As far as I understand it, the private flat textures mod uses the same technique (or maybe a slightly worse implementation of the same idea), and I've been told it's even a modification of CleanTF2+. But I was never given access to the mod so I can't be sure. I'm not really sure why someone would take a public open-source project, make a fix and improvement, and then not push the changes or get in touch with the original author. Though maybe they did try and get in touch but just weren't able to reach me :B
  
• There is a known issue where some flattened textures appear darker in sv_pure 0 now. I have some suspected leads but I figured it's more important to get something working out there, especially considering how many people interested in the mod are not the types who regularly play on sv_pure 0 servers.

Now why either of these things matter in sv_pure, where it should (and is) using the stock default textures using their own encoding and their own mipmaps, I have no clue. Not only that, but it seems silly to enable mipmap generation on textures that are already 1x1 and therefore can't have any mipmaps. How the source engine handles textures applied to brushes in sv_pure is full of mysteries. But it is what it is.

For league admins:

I don't believe this offers any actual, cheaty advantages -- it cleans things up and hypothetically leads to slight fps improvements (I haven't benchmarked but the common wisdom is smaller textures and mipmaps = better memory locality within GPUs = less cache misses = better performance GPU-side) without doing anything that offers material gameplay benefits. And likewise I doubt valve really cares either, since these flat textures rely on the same fundamental techniques as the old clean tf2 flat textures did (as well as at least one earlier flat textures mod), so we're talking about public methods that have been around for over half a decade now. But it's just the nature of CleanTF2+ that a lot of it runs in a gray area of what is acceptable and what is an exploit.

A lot of my stuff in the past has caused issues for leagues, and I've put in effort to make sure CleanTF2+ doesn't violate league rules, but I also know that I'm not very active anymore (outside of the huds.tf and mastercomfig discords, which would be the best bet to contact me) so if I'm not kept in the loop then CleanTF2+ might not be updated for some time (the metal footsteps being one example). I'm glad to help so if there are any league concerns about these, feel free to contact me through discord as that'll be the easiest.

I don't regularly check tftv all too often nowadays but I did patch cleantf2+ so that it doesn't provide the option to use metal footsteps.

Someone tech savvy could still easily modify it to add metal footsteps again, or just modify the file after it's generated, or copy it from someone else, etc. but anyone downloading cleantf2+ from now on will not accidentally get it.

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.