ESOUI - smooth health bar animation

ESOUI (https://www.esoui.com/forums/index.php)

- Lua/XML Help (https://www.esoui.com/forums/forumdisplay.php?f=175)

- - smooth health bar animation (https://www.esoui.com/forums/showthread.php?t=4857)

smooth health bar animation

I'm attempting to create a smooth health bar animation for a personal project. The goal is to eventually make it as smooth as possible, smoothing over the jumps when you do get health back. If that makes sense. Here is what I have at the moment:

Lua Code:

function Animate_SetWidth(self, changeWidthTo)
    -- Make sure we have a timeline & animation.
    if ( not self.animation ) then
        self.timeline  = ANIMATION_MANAGER:CreateTimeline();
        self.animation = self.timeline:InsertAnimation(ANIMATION_SIZE, self);
    end
    local width = self:GetWidth();
    local height = self:GetHeight();
    self.animation:SetStartAndEndWidth(width, changeWidthTo)
    self.animation:SetStartAndEndHeight(height, height)
    self.animation:SetDuration(500)
    self.animation:SetEasingFunction(ZO_EaseOutQuadratic)
    
    self.timeline:PlayFromStart()
end

So that brings me to my questions:

Is this the best way to achieve what I want?
And is there a way to stop it from the start-stop animation when regaining health/magicka/stamina?

EDIT: Changing the duration to 2 seconds makes it a little less jerky but makes it seem much slower.

EDIT2: Is possible to animate a statusbar rather then creating a blank control and adding on a backdrop?

1. Timelines/animations are what the game uses internally for pretty much all its animations. So, yeah, I'd stick with that for normal animations. I did some animation for CyrHUD manually, but I wanted a slow change over 10-15s, so updating at 1fps was plenty.

2. There's a stop method on the timeline:
http://wiki.esoui.com/Controls#AnimationTimeline

E1: Perhaps play with a different easing function. Without increasing FPS, "smooth" is pretty much entirely dependent on how fast/slow your transition is. Easing functions trick you by going fast for part of the progress then slower for the rest, which can appear smoother overall.

Some of the ones I found:
ZO_LinearEase, ZO_EaseOutQuadratic, ZO_EaseInQuadratic, ZO_BezierInEase

I couldn't find the exact signature for if you wanted to write your own, but the first parameter was "progress". You could probably hook one of those to get an idea of the in/out of the function. My guess is you'd feed it the actual time progress (either 0.0-1.0 or 0-100) and it'll spit out the adjusted/visual progress (same range).

E2: You can create a custom animation instead of using the size animation. It basically triggers an update for it with progress, and you can set whatever property you need:
http://wiki.esoui.com/UI_XML#CustomAnimation
http://wiki.esoui.com/Controls#AnimationObjectCustom

Thanks for your response! :)

I'll check out how the custom animations work!

(Found a way to see ESO's code and they do it by OnUpdate so there may be another option for later on)

Lua Code:

local progress = {}
 
local function CreateSmoothProgress(control, value)
    progress[control] = value;
end
 
local function SmoothProgress()
    local increment = 0.2
    for control, value in pairs(progress) do
        local ctrlMin, ctrlMax = control:GetMinMax();
        if ( value < control:GetValue() ) then
            control:SetValue(control:GetValue() - increment);
        else
            control:SetValue(control:GetValue() + increment);
        end
    end
end
 
EVENT_MANAGER:RegisterForUpdate("SmoothProgress", 0, SmoothProgress)

As an alternative to using the animation system I wrote this. It's fairly smooth but if you change the incremental value (i.e. 0.2) to something closer to 1 then it jumps past the end of the statusbar (the leadingedge) and makes a shadow in front of it. Not sure how to combat that. Ideas?

I'd try to stick to the Animation system if at all possible. Unless you're careful, you can easily do too much in an OnUpdate and cause an FPS drop. For example, that code runs every frame whether it needs to or not. Also, you're not guaranteed to actually hit your end value but could end up oscillating above/below. That part could actually be what's causing the shadow. Furthermore, that's rather brittle and doesn't allow you to change a set duration; it will change at the same speed whether you need to go a small part of the bar or the whole thing.

The animation system will handle register/deregister of the update handler for you. It's also more keyed to how long the animation is, which is more critical. The player should be able to look at the bar after .3s, .5s, probably 1s at the most and see the correct value. And if it's a small change, you can still take that time and have a smoother animation.

Quote:

Originally Posted by Sasky (Post 21860)

I'm still trying to figure out how to make it work the way I want it to. So I'm sure you can imagine that there is going to be bugs in my code that I have to get through... :)

Quote:

Originally Posted by Sasky (Post 21860)

Also, you're not guaranteed to actually hit your end value but could end up oscillating above/below. That part could actually be what's causing the shadow.

Agreed, is there a solution that you could suggest? I'm coming up short of a decent solution.

Quote:

Originally Posted by Sasky (Post 21860)

Furthermore, that's rather brittle and doesn't allow you to change a set duration; it will change at the same speed whether you need to go a small part of the bar or the whole thing.

The idea is to have the same speed. I do realize the drawbacks for this.

Quote:

Originally Posted by Sasky (Post 21860)

The animation system will handle register/deregister of the update handler for you. It's also more keyed to how long the animation is, which is more critical. The player should be able to look at the bar after .3s, .5s, probably 1s at the most and see the correct value. And if it's a small change, you can still take that time and have a smoother animation.

You don't really see the correct value for the default attribute bars until their animation is completed anyway. I expect the same will happen no matter how you animate your bars. Unless you're happy with the bar jumping back and forth without anything smoothing. As a side note; my function looks similar to the default attribute bars. Obviously I want it to be more smoother then that though.

Again, thanks for the feedback! :)