70 looks fine, but I use 84 myself.

personally I use irc over SSH so sounds aren't a possibility for me
IDK about OP though, just throwing that out there

I just put that in the vanilla HUD's animation file from scratch and it worked. Actually, I took out the pointless line from the stopper event, but that shouldn't have affected anything.

oh lord this has the missing parts of RXP HUD
too bad I'm too lazy to port them ;_;

Most of TF2's performance issues come from the entity system, and bad map optimization (only on certain ones; the three big granlands maps don't have problems) from what I remember.

that is only a temporary solution

all these wrong boarded topics

Engie limit: 0

Are you sure you overwrote the HudLowAmmoPulse etc that were already in the animations file? Also, make sure that AmmoInClip and AmmoNoClip refer to real text displays in the stock HudAmmoWeapons.res, and if they don't, rename the ones in the .res or animations file to match the other. Your call. I don't know any of the labels in the stock HUD's files, and I don't feel like extracting that stuff myself to check.

EDIT: It might be an indentation issue. If source engine is picky enough, it might be freaking out if you didn't put tab indents at the beginnings of the lines between the braces.

make process a CTF map, get rid of everything past 2/4 and put the flags on those points

texture resolution is one of the least things to worry about with source engine

holy shit this is so creepy with the torchlight II main screen background music

preformatted text (like, code!) breaks

indented
    with
        spaces

indented
	with
		tabs

Here's a rundown on how the basics of how the HUD animation system works. Here's the overheal color pulse (modified) from my copy of RXP's HUD:

http://64.vg/src/a16f2f33335ed5c1013a796143e4bea9

HudHealthBonusPulse and HudHealthBonusPulseStop are called by the game itself when you go above 100% health and when you go below it, respectively. The "starter" event calls an infinite loop between Loop1 and Loop2; Loop1 does the actual animating and Loop2 basically makes Loop1 repeat itself.

In the original RXP HUD, it loops between the starter event (HudHealthBonusPulse) and the loop event. The stopper event kills any event that might be running that sets the color (Animate) of the health # shadow (PlayerStatusHealthValueBG).

More info on that itself: "Animate" is a command that changes some attribute of an HUD object over a certain time, from one value to another, given some interpolation. There's a description of the interpolation methods at the start of the file:

http://64.vg/src/0cd034ef8000931b8e7d162a37b8a8d1

Personally, I think Spline and Linear are the only ones that should be used for pulses.

Here's what I found in my HUD does for low ammo display:

http://64.vg/src/07006f9ce536065684836727913b8609

Now, this can't be right. My HUD doesn't have any image telling me when I'm low on ammo. That must be disabled in HudAmmoWeapons.res. Well, let's take a look at that:

AmmoInClip
...
AmmoInReserve
...
AmmoNoClip

Wow, I guess they couldn't merge weapons without reserve ammo with ones that do have such. Anyways, let's try making AmmoInClip and AmmoNoClip's FG color orange when I get low ammo, like my health number does when I'm low on health:

event HudLowAmmoPulse
{
	Animate	AmmoInClip	FgColor	"Orange"	Deaccel 0.0 0.075
	Animate	AmmoNoClip	FgColor	"Orange"	Deaccel 0.0 0.075
}
event HudLowAmmoPulseStop
{
	StopEvent HudLowAmmoPulse 0.0
}

Wow, that orange is really, really gross, and it sticks after I get more ammo again. I'm going to try out a theory that "StopEvent" fast-forwards to the end of the animation, and leaves it there, and see if I can fix it assuming that...

http://64.vg/src/77c734eb87f60c0058322ae2bcdce343

Wow, that didn't solve anything AND the light orange is transparent. I guess I have to reset the color to white manually.

http://64.vg/src/d056f37ebf0fbe912a42776282bf22bf

And it works! Though, it can definitely be simplified a lot:

http://64.vg/src/b0a5347c0391a93543ebea07dd46d99c

Actually, since we don't have to reset the color in the "pulse" itself, we can just get rid of the loop entirely. Well, if you actually want a pulse, you need a loop. You can name it whatever you want. Don't be unreasonable though. Here's what I have finally:

event HudLowAmmoPulse
{
	Animate	AmmoInClip	FgColor	"LighterRed"	Linear 0.0 0.0
	Animate	AmmoNoClip	FgColor	"LighterRed"	Linear 0.0 0.0
}
event HudLowAmmoPulseStop
{
	StopEvent HudLowAmmoPulse 0.0
	StopEvent HudLowAmmoPulseLoop 0.0
	Animate	AmmoInClip	FgColor	"TanLight"	Linear	0.0 0.0
	Animate	AmmoNoClip	FgColor	"TanLight"	Linear	0.0 0.0
}

Very simple and consise, but I (we?) learned a lot making it like that. Also, apparently,RXP's "Yellow" is close to the normal offwhite that the ammo/health numbers use. Fancy, huh? I like the way these colors look. You can do whatever you want, but make sure to NOT change the names of the start and stop events. TF2 only calls specific named events; if you change their names, TF2 won't know how to find them, and it'll just call an empty, blank event, and do nothing.

basic understanding of structured programming required