I tried doing this code for the rest of my scenes and it worked for everything aside for this one below:
I used a global variable to change my characters health (100) and put it in that variable and save it before it changes the scene so that on the next scene the length of the life bar is the same.
First, you could move HealthStatus action above paint effect type “Circular” (that shouldn’t change anything here but is a good practice).
The second is to check if the condition “when paint effect of transition ends” is not fired sooner than you think.
The third idea is to check the value of Neu.Health::Health() when you release the EnterMitosisButton and to see if it has expected value AND type.
If everything is ok, I think we will need to see more of your health bar logic on the Mitosis scene.
These are the only times that I used the health bar in my Mitosis scene:
I’m just confused why it worked until Mitosis and the rest of other scenes
EDIT: I might have found a way
I added this at the beginning of every scene and it seemed to work. Thank you @gigakoks
EDIT: Well I was wrong lol
EDIT: Nope, I was not wrong, it’s working now sorry lol
If you switch back and forth between scenes, try using “trigger once” instead of “at the beginning of scene”.
On the side note, I think your logic needs a bit more thought to be given into it. For example, you should stop setting the width of heath bar every time your object is colliding with something. Instead, you could create only one action without conditions and place it above all events, so it will constantly look for changes of health value and you wouldn’t need to repeat this action for every collision you create.
Thank you for this, I will keep this in mind. 
Better yet, use the conditions that are part of the Health extension:
Is health just damaged
Check if health was just damaged previously in the events.
Is just healed
Check if the object was just healed previously in the events.
@gigakoks without conditions your idea would not be looking for changes, it would simply be changing the health bar based on the formula every tic, even if it is the same. That means it would be calculating health/maxhealth * 314 or whatever, at all times. While not enough to slow the game down it would be a better practice to only do that calculation when needed (i.e. health has changed value)
As you said, my solution would not make any noticeable difference in performance so in this case I would opt for cleaner code instead of unnoticeable raise in performance.
The performance gain now isn’t really the point… it could become noticeable if you were to decide to update a large number of objects and introduce more calculations. And I don’t agree that slamming the value in every tic is cleaner, either. Having a very obvious condition like “updateHealth is True” is, I think, more readable than just a formula floating out in the ether.
Consider you now want a nice effect for when your health bar changes. Like, when you get damaged you want pieces of it to fly off or something. Now you need that trigger anyway, unless you want to have the width updating in one event while the effect is happening in another.
What you wrote is an example of overengineering.
