rbjaxter / budhud

A Team Fortress 2 hud inspired by whayay's yahud and rays' rayshud.
MIT License
186 stars 89 forks source link

Reliable way to fix lingered HUD animations #501

Closed qkeitoe closed 2 months ago

qkeitoe commented 2 months ago

I've always been annoyed by lingering HUD animations, especially because the only known (to me) way to fix them was hud_reloadscheme, which freezes my game for a couple seconds. So I came up with the following reliable way to fix them when they appear.

https://github.com/qkeitoe/budhud/commit/b36c9e28499ca10299638e666eeb713bc883a41b

Basically, triggering the event MenuOpen fixes all existing lingered health and/or ammo animations and doesn't affect any their ongoing animations.

This works due to the fact that the start time of each individual animation in the events used to fix lingered HUD animations exceeds the time of one loop of the ammo or health animations respectively.

https://github.com/qkeitoe/budhud/blob/eb5b1ceddecef5914e3f3590128ac7e591a41173/%23users/custom/scripts/hudanimations_custom.txt#L28

https://github.com/qkeitoe/budhud/blob/eb5b1ceddecef5914e3f3590128ac7e591a41173/%23users/custom/%23customization/_enabled/bh_animate_foreground.txt#L17

I've been using it since March and haven't encountered any bugs in any of the many HUDs I've used in that time.

Also, I already shared this way with Hypnotize, but apparently Hypnotize decided not to implement it in m0rehud. I don't know how you will feel about it, but I decided to share it after all. I guess it's not a very obvious way for a user and it will be hard to make users aware that it even exists, but yeah...

rbjaxter commented 2 months ago

I was actually thinking about this a few days ago, funny to see that someone else was thinking of the same thing. I've been trying to think of all the places you could sneak in a reset animation to resolve the issue.

If this doesn't affect voicemenu usage at all (one of the reasons I've never wanted to add uber tracking to the hud), I don't see any reason not to include it.

rbjaxter commented 2 months ago

I can't check how this would work in-game, but I'm curious to better understand why this wouldn't cause the health color to flash white as MenuOpen is triggered. For instance if you're in a low health loop, wouldn't triggering MenuOpen still visually show it being forced back to white before getting changed back to red?

I guess my brain doesn't understand how it'd know to differentiate between the looped animation and stuck health just from the loop time being a bit longer, unless a loop can't be interrupted by another animation being played

qkeitoe commented 2 months ago

I've added the StopEvent statement to the begging of each corresponding pulse event and made the start time of each individual Animate statement 0.5 that is greater than the time that elapses between successive triggers of pulse events in loops (0.4). If low health animation is running, then StopEvent statement will stop the event LingeredHealthFix and Animate statements won't be actually proceeded.

For safety 0.5 can be increased up to 1.0 for example. But even with the presented setup I couldn't make the added events interfere ongoing animations.

qkeitoe commented 2 months ago

I also tried to make the event TeamStatus_PlayerDead (or TeamStatus_PlayerAlive) triggers the fix but apparently this event can't trigger any event for any panel outside HudMatchStatus.

rbjaxter commented 2 months ago

Ohhh now I see, I didn't catch the added StopEvent. That's pretty clever!

rbjaxter commented 2 months ago

As far as I can tell I didn't break anything when I implemented it, so thanks again for coming up with this! If you run into any issues with how I implemented your animation fix, let me know