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.

https://i.imgur.com/5HIyuDG.png

Alberta and to a lesser extent Saskatchewan (both firmly conservative) having growing separatist movements, since they're very angry about not getting a Conservative government (and ironically voting so Conservative means they have no Liberal seats, and therefore have no representation within the leading party).

Who knows if it'll eventually reach the levels that Quebec used to have (when it came to a referendum, 49.5% voted to leave) but I wouldn't call our politics sane right now.

Aye, how's the saying go? "Canadians don't vote for who they want, they vote against the people they don't want" or something along those lines.

Trudeau has had his scandals and isn't ideal, but a Liberal minority probably upsets everyone the least (Liberals happy that they still have government and don't have to deal with Scheer, Conservatives happy that it's only a minority government and they'll still get the say on a lot of split issues, Bloc and NDP happy that they got pretty good results and will be decently represented, Green happy that they've got another seat). People's Party doesn't really have anything to show for it, but the more surprising thing is that they got any media focus in the first place.

At least in PEI (where locally Conservatives form minority government with Greens as the opposition party) the general mood I saw was "I'm not excited about Trudeau, but I really want to avoid Scheer, and I'll strategically vote to avoid that." May and Singh appealed to a decent amount of voters here (especially with Bevan-Baker's support of May) but ultimately most people were alright with Trudeau and didn't want Scheer.

https://www.thebeaverton.com/2019/10/atlantic-canada-enjoying-the-2-hours-when-rest-of-canada-pays-attention-to-it/

Option 1: find the files for the hat inside the nohats vpk and delete them from there, so it loads defaults again
Option 2: use cleantf2+ and add the file names to dev/lists/nohats_weapons.txt so that they get ignored when generating nohats