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

materials/vgui/replay/thumbnails/killfeed_icons/
scripts/mod_textures.txt
scripts/mod_textures_killfeed.txt
scripts/base/mod_textures.txt

this one's a bit more extendible / futureproof so it splits things up into different files and loads them in with #base, but it's functionally equivalent to colly's icons normally except they both point to "d_images" instead of half using "dneg_images"

Sorry lads but I didn't have as much time as I expected originally with my hud, so I wasn't able to get a whole lot done with it. If the deadline is extended I would give another effort to finish, but I don't mean to pressure the decision since I will (hopefully) have more free time but can't make guarantees.

That said, one big thing that got added was transparent damage numbers, to read stacked damage numbers easier and not be painful bright yellow (it's subtle, but it's a lot better than opaque damage numbers):

https://i.imgur.com/agr5yBE.png

it's available here:
Direct: https://github.com/JarateKing/jx-hud/archive/master.zip
Source: https://github.com/JarateKing/jx-hud

as it is it wouldn't be too bad to implant over another hud if ye don't want to deal with some default elements that I haven't gotten to changing (yet)

zoom_sensitivity_ratio is independent from your aspect ratio, so 0.793471 is what you should go for on any resolution.

I did some writing about it here as well: https://github.com/JarateKing/jarconfig/blob/master/docs/zoom_sensitivity_ratio.md

You're saying this as if climate scientists are somehow unaware of other time periods. In fact they are quite aware, and graphs like that are in-part based on their work in the first place:
https://pubs.giss.nasa.gov/abs/sc03000u.html
https://pubs.giss.nasa.gov/abs/lu08000d.html
https://pubs.giss.nasa.gov/abs/sc00100w.html

The temperatures in that graph are due to a variety of factors -- sometimes it is CO2, sometimes it's not (for the record, Scotese's graph says nothing about "solar levels" and the sun does not work the way you seem to think it works). And importantly, Scotese's methodology is not very well suited for reconstructing the global mean temperature as evidenced by how few data points there are (his area of expertise is in continental positioning). Better suited methodology will give you a global mean temperature graph like:

https://upload.wikimedia.org/wikipedia/commons/f/f5/All_palaeotemps.png

Which still has its problems (its logarithmic scale is kinda messy), but it does make it a bit more clear that the current rate of climate change is completely unheardof. We're projected to suddenly exit a very stable time period with a change of +8F by 2100. The shortest previous jump of the same temperature difference took several thousand years. What we are currently undergoing is not normal.

And in general, humans would not survive in these other warm time periods. If we are reasonably confident that the cause we're experiencing right now is CO2 related, that's what we should be focusing on. And that's the consensus of nearly every single credible person who's spent their life studying this.

I'm not sure if this is what you're referring to, but my understanding is that the EU is only blocking subsidizing coal mines. If the coal mine makes a profit then it's not a problem, but if it needs bailouts to keep running then it can't. Again, correct me if I'm wrong.

On that note though, you should be happy to hear that by 2020 solar and wind power will be priced competitively to fossil fuels, and continue to get cheaper. In a relatively short amount of time, it wouldn't even make economic sense to keep coal mining for energy anyway.

Yeah that's something that happens in science all the time. You can read the abstract to get an idea what it's about (I included it because it makes it clear that we are actively fine-tuning the accuracy of our models, which only works if the concept behind it is essentially undisputed and well-tested).

If you're not satisfied with that one, maybe the 3 other examples and the 3 meta-analyses going over thousands of papers should be enough for you