You know how in fighting games, after you get hit, a portion of the health goes from white to red for a second, until it finally goes away once the entire combo is done?
You can see here where once the fighter gets hit, the healthbar changes a portion from green to red, then to nothing
I’ll check that out. I’ve been using ProgressTimer and that works fine as a progress bar, but if LoadingBar does that extra interstitial-like effect, it sounds like it could be just what I needed. Thanks
Tried it out, it works just like ProgressTimer, but you lose some customization. Is there a setting I’m missing to have it do that effect I’m looking for?
Sorry, now that I reread your question it’s the interstitial effect you want… I apologize. In that case, I think you need to create a modified version of progress timer or loading bar and change the update function to have the interstitial effect but I expect you were looking for a more elegant solution (which I don’t have–sorry again!)
Using ProgressTimer is the perfect thing, but you can also use a LoadingBar.
The difference is, that the former is derived from a basic Node, and the latter from an UI node.
You don’t need to modify anything. The health-bar effect is just two progress timers/loading bars layered on top of each other.
The red one is underneath the green one. The red bar you see, is the difference in the percentage between the two progress bars:
Player takes a hit -> green bar is set to 80% immediately -> the red bar appears with a 20% difference -> the red bar is set to 80% over time to get that animated decreasing effect.
The effect is pretty trivial. Two progress timers/loading bars. The first one is acting immediately to the decrease in health, and the second one is using an animated decreasing. Just always decrease to the same amount.
If there is a new hit, while the red bar is still decreasing, the animation is stopped and the bar it is set immediately to the old percentage and the animated decreasing begins from this position.
I wrote a wrapper class that has two progress timers, front and back. They both have the same properties, only the back one has a different sprite (in my case, a color inverted one). On the wrapper class, I use most of the ProgressTimer’s methods to set scale or set position to apply to both at the same time, and then a helper that scrolls the back progress timer after a set duration.
I can replace that, my scene’s got a scale function that tests the current viewport against a given viewport and scales it appropriately. Its so 1 looks like 1.5 on a viewport that’s 50% bigger. I’ll remove it because it’s not relevant here so much.
That code hasn’t been tested, I ripped it out of my game, and renamed a bunch of stuff so it’s more generic.
I’m trying to find a good way to handle queued actions. It works if the scroll_to_percent calls happen 1 second apart, but you’re right that it fails if you call it too soon.
I think I’d need to constantly push back the front_timer and then only update the back_timer once the front_timer is done its action. I’ll look around for a callback sequence or something.
There is no need for pushing anything.
Just add a callback to the front timer’s sequence, which calls the back timer’s action. This guaranties, that the back timer will always be called after the front timer and only if there was an action.
Say the percentage changes to 90 from 100%, the front will change to 90 over 1 second, and then the back with follow through after another second has passed. The problem comes if I want the front_timer to change to 80% before the 1 second has elapsed (and the back_timer to have caught up).
Currently, the back is just lagging 1 second behind, but I’m looking to have the back_timer wait until the front_timer has completely stopped moving. So instead of back doing the exact same changes 1 second later, I’d like the back_timer to wait for as long as it can before moving to where the front_timer is.
Just introduce a boolean variable like “isActive”, which is set/unset by the starting/ending back timer. The front timer checks it, stops the back timer and sets it to the new front timer percentage immediately.
This is the same behavior like in the video.
Even easier, when using a sequence action. Every time you start a front timer, stop the sequence action, set the back timer to the front timer percentage and create a new sequence action.
This is exactly what happens, when you add the back progress action to the sequence action of the front timer.
I’ve been fooling around with this even more. I think the whole mixup here is because I’ve been calling scroll_to_percentage each frame, even when nothing has been happening. So I’m going to do something like your isActive check to make sure I should update the progress bar. That way I can call the stopAllActions on it, because I know it’s not going to be called unless it needs to.
The sequence is created, when the player is hit. The sequence will update itself.
No need to use isActive either, if you are stopping the sequence and create a new one every time the player is hit.
So I got it working as I am looking for, all thanks to your consistent help. I added a target_percentage that gets checked before it does its scrolling, so if the percentage is the same as the last time it was called, it’ll just return without doing anything.
Part of my problem was that I was calling this->back_timer->stopAllActions(), but the sequence with the TargetedAction pointed to the back_timer was running on this->front_timer, so the stopAllActions call had no effect.