Closed qkeitoe closed 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.
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
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.
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
.
Ohhh now I see, I didn't catch the added StopEvent
. That's pretty clever!
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
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...