edit the animations and make the HudHealthDyingPulse event include:

Animate PlayerStatusHealthValue FgColor "255 0 0 255" Linear 0.0 0.0

And the HudHealthDyingPulseStop include:

Animate PlayerStatusHealthValue FgColor "255 255 255 255" Linear 0.0 0.0

Replace the PlayerStatusHealthValue with whatever label you want if the white text is actually a different label (unlikely), and change the FgColors set here to whatever it needs to be if you want it to be different from pure red / pure white.

In the future you should try asking https://www.teamfortress.tv/19073/hud-editing-short-questions-quick-answers if you've got a question about hud editing.

I'm not a lawyer but they're arguing that all they've done is copy the typeface (which is not copyrightable in America) and the letters (and IV is so simple and common that it's obviously not copyrightable), so they've done nothing illegal.

I don't know if this argument would hold, since the typeface itself is Trajan which doesn't have any fade or decay which were made by the album designer. Again, I'm not a lawyer, but I'd be surprised if this was treated as a new typeface rather than creative additions that were directly copied.

Fonts (the files) can be copyrighted, typefaces (the design) can't in the US. It's weird.

Move your monitor back like 5 inches. I don't think it offers any significant competitive advantage, but that's a stretch.

The target audience is "people who can afford top-of-the-line monitors" so getting a higher resolution and a size that's impressive is better than not in that regard, even if it's not better for competitive gaming.

It's a bit outdated, you can get the current version from: https://github.com/JarateKing/TF2-Hud-Reference/tree/master/reference

Also includes an auto-update batch file if you put TF2-Hud-Reference into custom, so you can instantly extract the whole base hud with that.

maybe you need to extend it by 3"

usually short extension cables are for putting the port in a more accessible location without huge amounts of loose cable being left over, or if there isn't much space around the port to let bulkier connectors work with it though

If you don't have any other viewmodels that end up in the same spot you want to keep (because they will also get affected) you can mod your hud to have modified transparent viewmodels that have the refract be fully opaque so it completely removes viewmodels, and just make it cover up the left hand.

For example, this mod will do it:
https://www.teamfortress.tv/26900/high-fov-left-hand-viewmodel-fix

Don't know how experienced you are with hud editing but if you want to do it yourself:
https://github.com/JarateKing/TF2-Hud-Reference/blob/master/0-TUTORIAL/2-Editing-Elements.md
https://github.com/JarateKing/TF2-Hud-Reference/blob/master/0-TUTORIAL/5-Materials.md
https://github.com/JarateKing/TF2-Hud-Reference/blob/master/1-APPENDIX/Refracts.md

a male-to-female cable is just an extension cable

If your AmmoNoClip looks the same as and is in the same spot as your AmmoInClip, then you can. Make a new label (called "AmmoAlways" or something) that looks like your AmmoInClip / AmmoNoClip. Then make your AmmoInClip's labeltext be "_______" or something, so that it becomes that line that separates them, and make the AmmoNoClip not visible.

This only works because if your AmmoInClip and AmmoNoClip look the same, you don't need to worry about them automatically becoming visible or not depending on what weapon you're using. So you can just use a new label that will always appear to replace both, and that means you can now use the AmmoInClip and AmmoNoClip labels for anything else you want to only appear with weapons with reserve ammo or no clips (in this case, the divider line for weapons with reserve ammo, and nothing extra for ones without).

Because this is label shenanigans, doing anything team colored wouldn't work. You could have a teamcolored imagepanel and then cover it up with a label, but it's not quite the same as the line getting smaller.

You can make another copy of the font you want to use, and edit it so that the - glyph is blank and has no width or kerning (note, if you just delete the glyph, tf2 will load defaults from whatever fallback font your system uses, which is not what you want).

https://fontforge.github.io/en-US/ or https://birdfont.org/ are two good free font editing software options. Should be a matter of opening the font, editing the glyph, renaming the font inside the editor (needs to be unique and different from the previous font, otherwise clientscheme can't tell them apart), and exporting as otf or ttf (whichever the font originally was is the safer bet). Then it's no different from adding another font to clientscheme.

If you want to make the font size smaller you can delete every glyph other than -+0123456789, since those are the only ones that'll appear in damage numbers and it doesn't matter if everything else gets defaulted to arial or whatever, but this is optional.

There isn't actually a whole lot you need to do to make a hud compatible with linux. https://github.com/JarateKing/TF2-Hud-Reference/blob/master/1-APPENDIX/LinuxSupport.md
Basically just make sure to use lowercase folders and files, and if font size needs to be exact then make all fonts be 80% as big for linux.

The tags themselves have little to do with it, but iirc they are:

[$WIN32]	not xbox
[$X360]		xbox
[$WINDOWS]	windows
[$OSX]		mac
[$LINUX]	linux
[$POSIX]	mac and linux (I haven't been able to verify this, but it sounds about right)

You'd use them whenever you want to do something differently between different versions, but if you just want the same hud in all there's very little you actually need to change.

I haven't finished it or made a formal release yet but I've been working on something that (among other things) should auto-generate nohats. Headsfeet is wip but the entire process is there, just not the list of things that need to be removed.

https://github.com/JarateKing/CleanTF2plus

If all you want is nohats, it should be a matter of:

1. download zip
   
2. unzip into tf/custom/
   
3. run generate.bat
   
4. type 'y' for the "would you like to remove hats?" question, type 'n' for everything else
   
5. wait a minute or two

I haven't checked with the new hats, but unless they're put in a really weird spot (that I'd just need to add to a list and then it all works) they should get removed.

seems to be an issue with the file that gets loaded with #base, so just use that with another hud.

save this in the resource folder as stupidshadows.res:

Scheme
{
  Fonts
  {
    StupidShadowsFont
    {
      "1"
      {
        "name"			"A font that does not exist"
        "tall"			"20"
        "additive"		"0"
        "antialias"		"1"
        "shadow"		"1"
      }
    }
  }
}

Then add this to the top of clientscheme.res:

#base "stupidshadows.res"

Why does this happen? Who knows! But it works with all huds now.

I didn't test it with any different settings, but it was consistent with mastercomfig low.

That said this is really broken and should be banned. Scope removal is a hud mod too so there's no reason this shouldn't be bannable.

I don't want to bump this thread every time I make a change (because I do pretty frequently) but I did add something worth updating about: a stat list that contains the amount of times stuff like minmode, #base, if_mvm, etc. appear in every hud file. It should hopefully make it a bit easier for hud devs to search for any file that's affected by these, without having to check every file. Currently it just goes over those three mentioned, but it's not too hard to change the script that generates it if anyone has any requests.

And mods, thanks for the pin!

Yeah, something I noticed with refracts was that nearly everyone treated them as magic that just happens to do a few seemingly unrelated things. They're not very intuitive and I wouldn't expect anyone to figure out how they work just by looking at them, but once you know what a refract actually is, all the ways they're useful make a lot of sense.

In other words it's the exact type of thing a tutorial should cover. A lot of tutorials were written before refracts were even a thing, but still, I thought there should be a tutorial for advanced techniques like that.

It would've been nice to get to use all the goodies the wiki section gives you, but it only really works well for documentation about a project and not so much a tutorial where the documentation actually is the project. I do have some plans for how to make it a bit nicer to navigate though, so hopefully it shouldn't be a problem.

Thank you for your contribution! Always good to see people working on this.

Most hypotheticals I see being brought up are more along the lines of "every way to use this weapon I can think of is actively bad for the game, even if they're not gamebreakers and I don't think many people will try it." And theorycrafting is usually wrong, but if everyone thinks a weapon is somewhere between pointless and bullshit, it's pretty unlikely it'll end up worthwhile.

And that's really the core of it:

Most people would argue the exact opposite. These are weapons that have not been proven to be beneficial to the game in any way. In all likelyhood any impact they do have on the game is a net negative, even if they're relatively negligible and rarely happen because no one uses them (in the best case). We have nothing to gain and only things to potentially lose, not the other way around.

The world's not ending because of some unbans that may turn out to do absolutely nothing, but every time we decide "well people are now used to putting up with the last whitelist, let's unban more" it seems like a bunch of risks are being taken that:

• do not have enough testing to see their full impact on the game
  
• in the best case will not matter because ideally stupid weapons just never get run (and is effectively the same as keeping them banned in that regard)
  
• in the worst case makes things a problem for the next few weeks, before everyone realizes it's completely broken and has to be banned again
  
• are decisions being made without most of the community's input
  
• are decisions most of the community doesn't agree with
  
• doesn't seem to actually have a good reason to happen in the first place, or didn't get us any closer to the goals it was supposed to the first x times we tried (helping valve balance weapon, getting valve to support the community more, getting more new players, etc. None of which changing the whitelist has done).

With how blatantly overpowered the atomizer was back when it was unbanned with the first global whitelist, I don't think a night of playtesting will even tell you that much.

It's all up to preference

Just fiddle around with

tf_dingalingaling 1 //enable hitsound
tf_dingaling_volume 1 //volume
tf_dingaling_pitchmindmg 100 //low damage pitch
tf_dingaling_pitchmaxdmg 100 //high damage pitch
tf_dingalingaling_repeat_delay 0 //how long it takes for another hitsound to play
tf_dingalingaling_last_effect 0 //0-8, killsound

https://github.com/JarateKing/TF2-Hud-Reference#readme

Some of the hud illuminati noticed that a lot of old hud tutorials were out of date, no longer being contributed to, and impossible for anyone else to add to. A lot of advanced techniques were developed in the past few years too, some never being written about at all, let alone being included in a tutorial. And certain resources, like mana's base hud git repo or doodle's file list, haven't been up to date in years. So for the past few months some of us have been working on a new hud tutorial to fix those issues.

This features:

• A tutorial to teach the basics of hud editing, that should be enough to get someone started.
  
• An appendix of extra info, technical elaborations, and advanced techniques that can be helpful even to experienced hud developers.
  
• A list of all hud files present in the default hud, with a quick description for most.
  
• A list of all hud animations present in the default hud, with a quick description for some.
  
• A reference copy of the default hud.

In addition, this hud tutorial is:

• Open to contributions from others: pull requests welcome.
  
• Easily updatable through scripts: when an update happens, both the reference hud and the file list can be updated with a single click each.
  
• Continuously being worked on: it's in a state where it can be public, but it's a WIP that has sections continuously being added or modified.

Links:
Tutorial
Appendix
File list
Animation list
Base hud reference

If you find any issue or something to contribute, either message me, create an issue on github, or fork the repo and make a pull request.