Cover the entire background of your crosshair with pure black at alpha 1, so that you can't really see it at all but it's still there. This has always solved all my issues with white borders from blending alpha areas, imo is the easiest way, and doesn't require messing with the black border itself like Enderp's method.

I was going to mention the Point Sample vtf flag too, so I'll just elaborate on Enderp's description. Point Sample will make it completely pixelated--resizing doesn't blend colors any. So this should solve the issue of the white border when resized, and if it's a good thing it'd make the black and the yellow of your crosshair stop mixing together as it gets smaller. The issue with it though is that if you resize it to be small enough, it loses pixels and some sides might be smaller (and in the case of having black borders, you might start missing them on some sides). My opinion for Point Sample is that it's good for when a hud element is slightly resized because of resolutions, but not much else.

1) yes
2) hudlayout.res, CHealthAccountPanel a little bit down the file. Change its xpos/ypos to 0, wide to f0, and tall to 480 and you'd be golden.

What actually is some inside-only stuff that people wouldn't get? I hear it all the time but I can't actually think of anything we say that everywhere else tf2-related doesn't also say, or (for site-specific things like upfrags or the streamlist or something) should be pretty obvious just by looking at how the site's designed.

It's 4.1667ms per frame for 240hz, compared to 6.9444 for 144hz or 8.3333 for 120hz.

240hz compared to 144hz is approximately twice as good as the jump between 144hz and 120hz (2.777ms difference for 240hz-144hz vs 1.3889ms for 144hz-120hz).

I've never owned a 120hz monitor, only 144hz, so I can't really say how noticeable that is. But for people who have used both 120hz and 144hz monitors, that's what you should expect out of a 240hz monitor. It's diminishing returns for sure, but then again it's still there.

There is no such thing as an if statement for scripting. Scripters get around this by re-aliasing instead, so basically instead of 'something' checking if an event happened (which is impossible), we make it so that when the event happens the 'something' behaves differently (which is possible).

As long as you're only aliasing to a single command, you can alias within an existing alias, like so:

alias something "alias +prim slot2"

That changes the +prim command, like you wanted.

If it has multiple commands, you can't alias to it directly. This doesn't work:

// this will make +prim go to slot1 and nothing else, and then run r_drawviewmodel 0 and +attack after that
// don't use this because it's broken
alias something_else "alias +prim slot1;r_drawviewmodel 0; +attack"

But you can make an alias for those multiple commands to solve that problem. What you'd have to do for that is something like:

alias something_else "alias +prim switch_primary"
alias switch_primary "slot1;r_drawviewmodel 0; +attack"

So you know, that aliasing can still be at the end of something. So this would work:

alias something "some_command; another_command; alias +prim slot2; more_commands"

With the some_command, another_command, and more_commands being example placeholders.

I don't know what you want to do exactly, so I can't make the script for you. But hopefully that should help you do it.

Every competitive game has its rules and meta that differ from the base casual game.

Compare it to smash bros, new people catch on pretty quickly to rules like no items or going with stock, and even things like stagelists or the tierlists they can accept with little-to-no explanation even though they take a bit more knowledge of the game to actually understand why they are the way they are. And that's almost 1:1 with tf2 (replaced with nocrits, our maplists, and the basic class composition).

I don't see new people who might not even play tf2 at all do very well, but I don't think "btw competitive plays differently from pubs, here's a rundown of the big things" is going to be a problem to most people.

TF2: zoom_sensitivity_ratio 0.7934714131880923806199067
CSGO: zoom_sensitivity_ratio_mouse 0.818933027098955175

Those two settings are equivalent (because scoped fov's are different), as long as your regular sens is the same and you only ever use the AWP's first scope setting and never the second. It's pretty minor but that should help you adjust better and get used to aiming with different fovs more.

There are tons. tr_newbots, tr_aim, tr_arena, tyler_rocket_shooting, etc. and then a some more specific ones like tr_medic. Nowhere near as much as csgo, but they're still here too.

Corsair doesn't make the best peripherals. They aren't bad, don't get me wrong, but they aren't anywhere near what you can get for the same price. They appeal to the majority of gamers who don't know what they want in a mouse (the kind that look and see 10000 dpi and 16.8 million colors and think it's a great mouse because of those alone), so they don't go for features that make or break a mouse for people who know better (like a good shape, corsair mouse shapes are very awkward and hard to get used to and are easily their #1 issue).

Zowie's EC Series has very similar shapes to deathadders, though iirc EC1's are closer in terms of size while EC2's are slightly smaller (not by much though and it'd be an easy adjustment either way). I don't know about weight, but I can't imagine it being very different, and the sensor should be better so if anything it should feel better.

That's not how bindtoggles work, they only work by changing cvars' values. They don't really work with straight up commands, or alternate between them, like you're trying to do.

You're sorta close with it if it were a regular bind actually, but the 'bind q "slot1;slot2"' trick (which is fine if you only do the slots) only works because of a quirk with switching weapons, which doesn't extend to aliases. The game would interpret pressing q as "try to switch weapons, set r_drawviewmodel to 1, try to switch weapons, set r_drawviewmodel to 0" and will always set it to r_drawviewmodel 0 because of that.

You'd need to add some actual toggle logic to it, such as:

alias "primary" "slot1; r_drawviewmodel 1; alias switch1and2 secondary"
alias "secondary" "slot2; r_drawviewmodel 0; alias switch1and2 primary"
alias "switch1and2" "secondary"
bind "q" "switch1and2"

That is assuming that you always use "primary" and "secondary" to go to that weapon, and you don't want your melee to change that up any (as it currently is: use primary, go to melee, pressing q will go to secondary).

My goto crosshair switcher for reference: http://gamebanana.com/scripts/8541
It doesn't immediately support what you're asking for but is a good base for that sorta thing.

Binding within an alias is perfectly valid, but isn't really good practice. It'll fuck things up bad if someone ever wants to switch the bind and forgets within the alias, or wants to bind it to multiple keys. It's a pretty small adjustment to go through an alias, but is a lot more portable if you ever want to change things later or re-use it or anything like that.

The only magic number for an fps cap is whichever one stops your computer from overheating (and when it overheats frames become much less consistent, on top of all the obvious issues of overheating). That and stops you from going into the 1000 fps range where things mess up for some reason iirc.

If you do have an fps cap, it's pretty much entirely unrelated to your monitor's refresh rate. The technical explanation basically boils down to fps (even capped) being much less consistent than refresh rates, and because of that it never aligns accurately, so there's never a cutoff point where more fps stops being smoother in terms of monitor hz. And as long as your fps is relatively consistent, higher fps will always mean more smooth mouse movement, though a consistent 100 would be better than an inconsistent 100-200 for most people for example.

Anyway, cutting it off at your hz exactly is usually pretty bad (60hz could have delays anywhere from ~0ms to ~16.67ms), cutting it off at twice (or *2+1 for the most part) reduces the max and average delay by half (on 60hz again, to ~0ms to ~8.33ms), three times would reduce it further (~0ms to ~5.56ms), and so on. For that reason you'd want to set it as high as you can, even if it's not a multiple of your monitor hz, because you'll get lower delays that way.

tl:dr if you want to set a cap, set it to the highest you can go in terms of fps while still being pretty consistent. Setting it to something based on monitor hz is based on a misunderstanding of how monitors work, and isn't what you should look at.

Though I can't really speak about fx's memory leak issue with not having an fps cap, I've never heard that before, and I've never used an fps cap either except for testing. Fps caps should be pretty individual though (there are so many different computers and different specs out there), so I'd recommend testing without a cap too.

Keep in mind, negative mouse accel (the inherent kind being talked about there) is when your mouse goes so far in one frame of tf2 that it actually hits the edge of the screen. Anything less than that and it's not an issue, since tf2 resets the mouse position to the center every frame. If you were running multiple monitors, and clicked during one of those sweeps, you'd be effectively alt-tabbed. In other words, if tf2's fps is 200fps, you'd need to be moving your mouse over half your screen in 5ms (on your desktop where tf2's sensitivity setting isn't factored in, but still 6/11 windows sensitivity with no mouse accel).

Something like this vid happening (except that's due to sensor issues, not due to screen-distance issues). Unlikely to result in a full stop unless you stop moving at just the right time, but you'll definitely feel it if it's there.

Of course, you can hit it for sure, and if you do you should lower your dpi down some. But unless your DPI is really high you should only hit it when you're turning around and never when aiming, so it'll break your rhythm but won't fuck up your shots. And a mouse sensor (especially laser mice) can still come with hardware negative accel, which is the bigger issue to look into I'd say.

tldr: don't use extremely high values for dpi, but anything low enough that you wouldn't hit the edge of your screen in a single frame (without tf2's sens factored in) is fair game.

A hud that does it would be weird and pretty broken, since iirc you don't know what order players will join in, and overlaying it would require reloading the hud. A stream overlay would be better because it wouldn't require a hud_reload, but the only good method (without valve helping out) would be plugins so it automatically replaces names (and would also work with the class ordering option for when someone switches classes and teamswitches without some manual labour swapping them around).

I think (as long as statusspec stays maintained and updated for future updates, which correct me if I'm wrong that's the plan) just getting a big list of prem/invite/whatever else gets casted players and forcing an alias on them (even if they normally play with their actual name, just to be sure) would be the best solution. The technology is already there, we just haven't made use of it yet.

Ingame sensitivity is a scalar multiplier. It doesn't discard steps or anything like that, it just makes them result in less angular movement. The source engine's angles to go 6 decimal places (or 9 digits total) so rounding differently wouldn't really be a thing either.

As long as your mouse doesn't add hardware accel at 1600dpi or any sensor accuracy issue like that (which are mouse sensor issues, not a tf2 issue), it shouldn't cause any issues.

The white rectangle is only there because it's not on dx9, since it's a refract material. The quake font and heart health are customizations too. I'm not a fan of prismhud anymore, I stopped working on it because I knew I could do better, but I don't think it's horrible (when it's not literally broken from dxlevel).

Things like the cp icons though are broken because of dx7 from what I can tell, keep in mind too.

For those who don't check reddit, there was this thread posted a day ago.

It sucks that once again reddit's the only place getting a proper response from valve, but it's a lot better than no communication so I'm not complaining.