You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reproducable on Godot Engine v4.3.dev6.official [89850d5]
System information
Windows 11
Issue description
A BlendSpace2D with a transition configured to reset the animation, does not reset the animation depending on if the blend_position changed.
Whenever the blend_position stays the same, the animation is properly started at 0, if the blend_position is different, the animation is started somewhere inbetween the start and end, causing keyframes to not trigger, in this case a texture only gets set after the animation restarts naturally.
Steps to reproduce
Create an AnimationPlayer and set up some animation that set a texture on the first keyframe.
Create an AnimationTree with two BlendSpace2Ds, for idle and moving. Set up the blendspaces with animations for each direction. Set the blend mode to CA (BLEND_MODE_DISCRETE_CARRY )
Set up a script that sets the blend position and a way to transition between the two states.
Run the project and see that the texture only changes when the blend position remains the same between states.
Minimal reproduction project (MRP)
This project demonstrates the issue with a progress bar (the progress in the animation), and two color changing cubes with a different color for each direction.
The top cube is a ColorRect, and the bottom a Sprite2D.
Animations with keyframes are set up to change the appearance of both cubes, but the Sprite2D only changes whenever the animation actually passes the keyframe, to demonstrate it changing only after the animation ended and starts to loop.
The expected behavior is that both cubes instantly change color (through the keyframe at 0), whenever any direction is pressed.
What actually happens is, the animation doesn't start from 0 when the blend position changes.
Pressing only one direction (eg. right, right, right, right), shows the animation properly resetting to 0.
Alternating directions causes the animation to not start from 0, causing the color change to be delayed until the animation loops.
Although the behavior of dev6 and the current master is different, I found a bug in the force continous behavior nonetheless, so I sent a fix as #93185.
Tested versions
System information
Windows 11
Issue description
A BlendSpace2D with a transition configured to
reset
the animation, does not reset the animation depending on if theblend_position
changed.Whenever the blend_position stays the same, the animation is properly started at 0, if the blend_position is different, the animation is started somewhere inbetween the start and end, causing keyframes to not trigger, in this case a texture only gets set after the animation restarts naturally.
Steps to reproduce
idle
andmoving
. Set up the blendspaces with animations for each direction. Set the blend mode toCA
(BLEND_MODE_DISCRETE_CARRY
)Minimal reproduction project (MRP)
This project demonstrates the issue with a progress bar (the progress in the animation), and two color changing cubes with a different color for each direction.
The top cube is a ColorRect, and the bottom a Sprite2D.
Animations with keyframes are set up to change the appearance of both cubes, but the Sprite2D only changes whenever the animation actually passes the keyframe, to demonstrate it changing only after the animation ended and starts to loop.
The expected behavior is that both cubes instantly change color (through the keyframe at 0), whenever any direction is pressed.
What actually happens is, the animation doesn't start from 0 when the blend position changes.
Pressing only one direction (eg. right, right, right, right), shows the animation properly resetting to 0.
Alternating directions causes the animation to not start from 0, causing the color change to be delayed until the animation loops.
mrp-blend-position-bug.zip
The text was updated successfully, but these errors were encountered: