You have to take the custom materials for it and change hudplayerhealth.res' PlayerStatusHealthBonusImage's "image" to point to that custom material.

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

Short gif of the animated bg: http://i.imgur.com/gm9Blpu.gifv
The gif is a bit laggy but it's completely smooth ingame.

gonna try reworking the buttons but not completely sure what yet
getting the blur there with the animated bg was a bit of a bitch to get working too, but it's not resolution-dependent
layout is pretty standard (every button on the left with room for the console) but it works

I haven't tried, but if you can put it inside an editablepanel, you're good to go. I don't know how likely it is for that to work though.

If not, imo the best compromise would be to use refracts, and set up a fallback material for dx8 that makes the bg opaque instead. Not ideal, but it means it works sometimes and mostly works other times, vs having it break in dx8 or have to scrap the idea entirely.

testhudanim is a command that requires sv_cheats for no real reason (you already can trigger some animations at-will so if there's anything you can exploit it's already there), if it became a regular command it'd be a dream for hud editors (anything from class specific huds that can look completely different from eachother, to customizing the hud however you want entirely ingame through scripting / buttons, to just generally having pretty near complete scripting integration in huds). As a hud dev, removing the cheat flag on testhudanim imo is the best thing that could happen to huds.

Some other things that might be nice, nothing big and all easily doable but nice to have:

• Option to not have your crosshair disappear when you open the scoreboard
  
• Option to not have your crosshair resize when you're shooting the ambassador
  
• Some better system than having to replace autoexec.cfg / valve.rc if you want your hud to execute scripts
  
• Some better system than having to replace tf_english.txt / chat_english.txt if you want to change it
  
• Un-breaking the "welcome back, playername" and whatnot so that it works again
  
• Be able to change the default position and size of the console
  
• A command to reload clientscheme and whatnot, instead of having to exit out constantly to get it right

which one? there's a bunch, if one doesn't work you can try another
fontforge is my go-to with birdfont as a backup (both free), but if you just want to adjust kerning / glyph sizes pretty much anything will do it fine

My issue with the weird ammo positioning is because I want to get the ammo-in-clip to be directly opposite the health (to create a sense of balance). Right now it's centered the same way as the health, and the low-ammo rectangle is the same as the low-health and overhealed rectangles too (which works great for classes that have no clips and huge ammo pools like pyro or heavy).

To get a more standard ammo-in-reserve positioning, that'd either mean compromising on that (which I don't want to do, I find it helps me aim better), or having the ammo-in-reserve get pushed really far to the side:

http://i.imgur.com/UqziR2b.png

http://i.imgur.com/3GqXST5.png

I have been toying around with this idea though and I don't mind it:

http://i.imgur.com/izVZKh3.png

The low-ammo rectangle is subtle and very out-of-the-way, but you do notice it ingame.

it's extremely early in dev (pretty much everything I've done so far is shown in those screenshots) so I'll be planning on putting up a dl a bit later when it's not all early unoptimized garbage.

trying to do something clean and not too crazy
a lot of what's done is pretty hard to notice zoomed out, so you might need to open the images up

http://i.imgur.com/YwXQQau.png

lf feedback

The build quality of the keyboard itself is good for the price I've heard, but at the same time the switches in it are garbage (still better than your average rubber dome, but zorros are probably the worst out of any mx clone). You could try replacing the switches in it (a 120 pack of gateron switches is $35 here) but if you're going to be doing a project like that you may as well go all the way and get a community-made board.

Personally, if you like loud clickiness I'd go with a magicforce68 with outemu blues or a plugable tkl, or a magicforce with gateron switches if you want anything other than blues. It's a bit more of an investment, but you're getting more bang for your buck with those ones. And reselling a budget board is a bit silly, but either one could be resold for most of the original price if you don't think it's for you, whereas the velocifire would have a hard time reselling at all.

If you want it to play an animation from the start when you hover over it, afaik it can't be done. But the last time I tried was years ago and I may be wrong.

If you just want it to have an animation, and you're fine if hovering over it starts it at any random frame (since the animation will always be playing, it just won't be visible until you hover over it), you can just get an animated vtf or use vmt proxies to do what you want, and set that to be the button's border on hover.

Budget?

And increased the old rate of 6/sec to 10/sec, and made it change your max health instead of hurt you so now you can't just immediately heal it back with a medic or pack or sandvich, and added some currently unknown accelerated drain mechanic to stop cheesing it by bhopping (I think is the goal). And on the flipside, got rid of the damage penalty.

Overall I feel like it's at a lot lower power level than before it got reworked with a lot of its issues (all its downsides being basically entirely avoidable) becoming completely solved, I wouldn't call this basically the same as pre-rework.

I think we'll have to wait and see how significant the added air control is.

If it's just sv_airaccelerate acting like it's 30 instead of 10 like I expect, it won't actually have a huge impact other than making gaining speed from airstrafing easier. Even playing on a server with a huge sv_airaccelerate value doesn't help with dodging projectiles midair as much as one-handing a controller for the analogue movement (or, as a tester for aimpad's analogue keyboard, that too), I find at least. Of course if it turns out they meant something else by added air control, it could have a much bigger impact, but I can't say.

The air control attribute currently is in the game (attribute 610, mod_air_control), just not applied to any weapon, so it wouldn't be too hard for anyone with a server to test to see how it goes.

When I read it, I interpreted it as the first shot (the one that's 100% accurate normally, every 0.95s on the ambassador) is 50% inaccurate and every other shot is unchanged (100% inaccurate). So it won't make you any better or reward skill more, it'll only make long-range headshotting very inconsistent without having any real impact on closer ranges (other than headshots being slightly more inconsistent there too). It's pretty much just a straight nerf in this case.

I could be wrong and it could be "ambassador gets no completely accurate first shots, but every shot is twice as accurate otherwise" which also makes sense, but I'd think valve would mention they did a tradeoff for non-headshots being more accurate if they went with that. We'll either need to hear from vJill (this new communication is great) or wait until the update comes out, I guess.

If I'm understanding, you either need to copy the missing strings from english / your language, or do some free localization work for valve and make new ones of them yourself.

I don't know the details in depth, but Targem games uses their own format called TPAK for their games, so this script for QuickBMS is likely your best bet.