Mobility yes, scarcity no. There are many times more qualified people who want to enter or stay in the gamedev industry than there are decent jobs in it. Valve would have no issue finding the talent if they're just looking for people who can maintain an old game, and for that matter getting a recognized name like TF2 would be a great addition to any gamedev's portfolio. And that's just one route, I've always thought it'd be great if they contracted out tf2 to another studio to focus on, but they could also acquire an existing studio entirely and get them on it.

My money's on the codebase just being a complete clusterfuck after a decade of patchwork, and it just being impractical for anyone new to want to learn how the whole system works (as a new hire, would you rather fix bugs on legacy code, or implementing features in exciting new stuff?). And until you know a system inside and out, the old adage is "what one programmer can do in one month, two programmers can do in two months."

is there some drama that ive missed? what's bad about this new players league?

If you want a news post, just have a somewhat presentable / official-looking group somewhere and email valve what you want posted. That's how everything on the news gets there, there's no "valve knows everything that happens in the community but only posts these things" conspiracy or something.

this is ridiculously outdated and so many little things will be broken / cause crashes that you shouldnt use it, after making adjustments for it to even work (this predates info.vdf, among many other things)

use this instead

The main guy who made it is mostly concerned with recreating / porting graphical effects from console games.

He also did this writeup on mario sunshine's water effects, which is pretty interesting on how they got around working with a fixed pipeline back in the day.

auto-update scripts can be converted to bash for the adventurous, this example demonstrates the idea and syntax but would require editing to work for tf2hud+ since it uses different folders and each do some different things. The versions of HLExtract may be different as well, I remember there being some versions that didn't work on linux, and some that work perfectly fine.

You don't need a script though, you can just extract the hud files from the vpk's (there are multiple options: 1 2) or download them (such as from here) and overwrite the old ones in the default_hudfiles folder. The auto-update script doesn't do anything other than extract files and place them in a certain folder, and that can be done manually if you want.

If you have a vtf crosshair (one that modifies the tf_weapon files like this vtf pack), there isn't really an easy way to my knowledge. You can easily script it to change color when you shoot, but not so much when you do damage.

But if you have a font crosshair in your hud, in scripts/hudanimations_tf.txt, edit the DamagedPlayer event too look more like:

event DamagedPlayer
{
    StopEvent AnimateHitmarker 0.0
    RunEvent AnimateHitmarker 0.0
}

event AnimateHitmarker
{
	// animate <elementName> fgcolor <color> linear <start time> <duration>
	Animate YourFontCrosshairHere FgColor "255 0 0 255" Linear 0.0 0.0
	Animate YourFontCrosshairHere FgColor "255 255 0 255" Linear 0.2 1.0
}

With the YourFontCrosshairHere being whatever it's called in hudlayout.res, the "255 0 0 255" being whatever color you want it to turn into (in this example, red) and the "255 255 0 255" being whatever it's normally colored (in this example, yellow), and the timings at the end there being whatever you want.

A similar concept applies for material crosshairs (as in a material in hudlayout), except you'd have to make another copy of the material (you can edit vtf files with one of these and make the vmt file like this) and have it be a recolored version. Then set up it up to be more like:

event DamagedPlayer
{
    StopEvent AnimateHitmarker 0.0
    RunEvent AnimateHitmarker 0.0
}

event AnimateHitmarker
{
	// animate <elementName> alpha <value> linear <start time> <duration>
	Animate YourCrosshairMaterial Alpha "0" Linear 0.0 0.0
	Animate RecoloredCrosshairMaterial Alpha "255" Linear 0.0 0.0

	Animate YourCrosshairMaterial Alpha "255" Linear 0.2 1.0
	Animate RecoloredCrosshairMaterial Alpha "0" Linear 0.2 1.0
}

If you've got any more hud-editing-related questions, you should try asking in:
https://www.teamfortress.tv/19073/hud-editing-short-questions-quick-answers

https://mastercomfig.com/download
Either low or very low is what you likely want, and many add-ons might be worthwhile.

Add to your class cfg files:

// blocky shadows
mat_filtertextures 1; mat_filtertextures 0

This won't increase fps, but it will make lighting look pixelated.

https://github.com/JarateKing/CleanTF2plus
Things that remove models will increase fps, fullbright will increase fps significantly but break in sv_pure, and resized flat textures should help with GPU cache efficiency but I haven't benchmarked it.

what the fuck why

if they stacked he'd run at scout speed almost exactly, a patch in 2010 specifically removed this for this reason because that would be absolutely awful

https://github.com/JarateKing/TF2-Hud-Reference/blob/master/1-APPENDIX/StubbornElements.md#dashboard-dimmer

It's one of the hardest elements to do anything with for sure, but it can be removed with a little effort.

1. replace 1shot's resource/ui/scoreboard.res with m0rehud's scoreboard.res
   
2. copy m0rehud's resource/clientscheme.res and rename it to clientscheme_m0re.res
   
3. copy m0rehud's resource/m0re colors.res and m0re fonts.res to 1shot's resource folder as well
   
4. edit 1shot's clientscheme.res to include

   #base "clientscheme_m0re.res"

   at the top of the file.
   
5. copy m0rehud's resource/font/ folder into 1shot's resource folder.

It's by design. They aren't buying studios because they like what it's doing and want to see more, they're buying it for some combination of their IP / dev talent / existing fans. And when the fans leave or stop translating to sales (whether it be the studio itself making bad decisions or EA imposing things on them), there's no reason to keep the studio around--they own the IP and the cost of moving a dev is negligible.

But they don't just axe the company immediately; they need time to relocate individual devs without causing a panic. If it was recently acquired, there's probably some stipulation about not closing the studio until a certain amount of time or enough employees quit or some other conditions (afaik and iirc, I can't find any sources on this but I remember hearing this mentioned). And even if they don't have a particular reason to keep them around, it's better PR for EA at large to shutdown companies for "rapid loss of employees" or "underwhelming quality or sales." So projects are started with no expectation of becoming a finished or quality game and receiving continuously less direction from mid-level management, and it'll either be a failure or a flop and they can safely close the studio or it'll exceed expectations and they're getting even more out of it.

From another article about the same Visceral shutdown:

And it seems to be working for them, EA at large is doing pretty well for themselves even if not all their studios are. There's obviously a lot more going on behind the scenes (and there's no mention of shareholders or the like in it), but that's the best explanation I've seen for why they'll so consistently close studios, sometimes within a few years of acquiring them, and still pull massive profits.

That was all a bit of a tangent, but it's important to recognize that the studios on EA's chopping block aren't blunders that piss off fans, it's a calculated plan that's gotten them to where they are now.

As for Respawn Entertainment and Apex Legends, I haven't been following either but I don't think it's immediately comparable to the big names in EA. Games like Battlefront, Battlefield, and especially FIFA are very mainstream and casual players were hyped for them, so it was a fairly safe bet to load them up with microtransactions and still sell well (with battlefront 2 getting burned by being so extreme and blatant with it that even people not following it were hearing about it, and now they know the line they can't cross).

Apex Legends isn't in the same position, and everyone knows the game would die if it ever got bad with being significantly pay2win. I'd wager as long as the game is a moderate success, it'd only ever turn into "microtransaction hell" if the playerbase starts leaving and they just want to milk whatever extra from it and be done with it. I'd be skeptical too, both because if it's not a success then they could recoup costs by becoming pay2win, and because for all I know Respawn Entertainment could be on the way out, but it won't be "EA is just being EA again and ruining a good game."

For anyone looking for more information, there is also: https://github.com/JarateKing/TF2-Hud-Reference though it's not in video format.

Sorta, sorta not. For most "crazy ideas" about huds, the answer is "if you really know what you're doing, and you're willing to sacrifice a lot." Just by looking at it:

Most of the overlay / background stuff wouldn't be too bad, it'd just be some materials to put in hudlayout.res or hudplayerclass.res. The hard parts wouldn't be making the actual hud elements, it'd be making the textures look right and making it work good on all aspect ratios (if you decide you want it to work on other ratios).

The health could be done, either with a custom healthbar material (that wouldn't work on sv_pure servers) or with the bonuscross healthbar trick using refract materials (similar to how magnum hud does it, it's outdated but it's a good example of lots of advanced techniques).

If the mana is supposed to be ammo, you hypothetically could make it work with some specialized blockfonts (again, magnum hud would be one of the few references) for weapons like miniguns or flamethrowers with no clip and 200 ammo. It'll be wrong for any weapons with different ammo though (you could set it up to work with any specific weapon / amount of ammo, but it won't work for any others, and making it work for weapons with clips would be significantly harder). More likely, you'd just ignore the mana bar and put regular ammo numbers like any other hud.

Run meter might be ubercharge or some weapon's charge meter? Same with the xp bar. These wouldn't be too bad to set up, it'd be more a matter of making them look good when you don't have them.

I don't know what the rest would be used for. The skill icons and the item hotbar don't really have anything that can apply to a regular hud. You could probably add the class icon/model over one of the skill icons which wouldn't be hard at all, and I'd assume you could finagle the weapon quickswitch menu or the non-fastswitch menu to look good on the item hotbar (I can't comment on if it's possible to make them list items horizontally, I've never tried, so this may not be doable) and then write some scripts so that it always appears when it doesn't interfere with anything else (switching weapons and shooting).

None of this would be expected from a new hud developer. Even out of experienced hud devs, very few would be able to handle any of the harder stuff here. I can't explain everything that well either, so don't worry if not everything makes sense, the tldr is that "it's technically possible but certainly not easy."

In the future, https://www.teamfortress.tv/19073/hud-editing-short-questions-quick-answers is a good thread for questions like these.

Some real quick testing, changing it to include +reload like so seemed to work:

// ...
alias +atk2_null "-attack; +attack2; spec_prev; alias checkm2 +attack2; +reload"
alias -atk2_null "-attack2; checkm1; alias checkm2 none; -reload"
// ...

I think this'll only be a bad thing with things that autoreload already screws up (some scout primaries losing the existing ammo in clip when reloading) but I haven't looked into it much.

If you want to see layers upon layers of logic, check out my vaccinator script.

I used to use this for a long time incase anyone wants it.

// null-cancelling attack script
// taken from https://github.com/JarateKing/jarconfig/
alias none ""
alias +atk1_null "-attack2; +attack; spec_next; alias checkm1 +attack"
alias -atk1_null "-attack; checkm2; alias checkm1 none"
alias +atk2_null "-attack; +attack2; spec_prev; alias checkm2 +attack2"
alias -atk2_null "-attack2; checkm1; alias checkm2 none"
alias checkm1 "none"
alias checkm2 "none"

bind mouse1 "+atk1_null"
bind mouse2 "+atk2_null"

It's been a long time since I've played seriously with this though, so I can't remember any specific use cases where it's better / worse, I only remember it being slightly different from regular m1/m2 and generally preferring it on demo.

What does this even mean? Null movement scripts just change what happens when you're pressing two keys at once, why would using a mechanical keyboard change that?

On any modern keyboard with more than 2KRO, a mech will be functionally identical to a membrane keyboard with similar key travel (actuation point will be different, but in terms of timing is so minor that it really won't matter). The way you naturally move might not benefit from it, but that has absolutely nothing to do with your keyboard.

https://i.kinja-img.com/gawker-media/image/upload/s--Mv2vfyYk--/c_fit,f_auto,fl_progressive,q_80,w_636/18ixnyy5rpgsijpg.jpg