Blendspace2D BLEND_MODE_DISCRETE_CARRY freezes or doesn't carry

[nezvers]

Godot version:
3.2.2

OS/device including version:
Windows 10

Issue description:
Making pixel art game with AnimationPlayer animating frames in Sprite (using discrete mode - frame by frame). Running has a blend for aiming diagonally and forward (like NES contra). When changing blends they restart animation position using BLEND_MODE_DISCRETE_CARRY but in some cases can freeze whole node (all running animations but then all animations are frozen in the same position).
Happens in the editor too.

Steps to reproduce:
Have a couple of animations (frame by frame in Sprite) that have common visual cues. Set the blend mode to carry.
While Blendspace2D is playing, change blend_position.

Minimal reproduction project:
AnimationTreeBug.zip
Move with arrows and Enter used for a secondary blend.
Notice that when flipping in MOVE state with UP and DOWN dot that goes around is staying in the same place.

[Calinou]

This issue was confirmed by latreides in https://godotforums.org/discussion/25912/is-discrete-carry-functional.

[latreides]

I get the same results in both 3.2.3 and 3.3.3 RC7

[rune-scape]

I'm also running into this bug in version v3.3.stable.official.
Before I found this issue already existed, I made my minimal reproducible project:

DiscreteCarryBug.zip

and a video of it:

discrete_carry_bug.mp4

I expect the number to go from 0 to 7 and loop, spending .1sec on each number, but it flutters around whenever the blend_position changes enough to switch animations. At the end when the mouse moves in fast circles you can see it gets stuck on the last frame and doesn't recover.

With this bug there seems to be no way to easily implement a properly synced 8-directional sprite sheet animation and use it with AnimationTree's state machine travel and transitions. This seems like a somewhat basic and common feature, I'm surprised it's not working.

[rune-scape]

I found the errors (there are 3):

godot/scene/animation/animation_blend_space_2d.cpp

Line 526 in 9018e8b

from = blend_node(blend_points[closest].name, blend_points[closest].node, p_time, true, 0.0, FILTER_IGNORE, false) - length_internal;

should be:

from = length_internal - blend_node(blend_points[closest].name, blend_points[closest].node, p_time, false, 0.0, FILTER_IGNORE, false);

I don't know why length_internal was being subtracted from the result of blend_node. Nor why the p_seek param was set to true.
and:

godot/scene/animation/animation_blend_space_2d.cpp

Line 529 in 9018e8b

mind = blend_node(blend_points[new_closest].name, blend_points[new_closest].node, from, true, 1.0, FILTER_IGNORE, false) + from;

should be:

mind = blend_node(blend_points[new_closest].name, blend_points[new_closest].node, from, true, 1.0, FILTER_IGNORE, false);

Because from is added to mind in the next line again.
All of this was causing length_internal to skyrocket to inf and flipflop between negative and positive when switching animations.

I'll make a PR.

[archead]

This issue seems to have returned in v4.2.1.stable.official [b09f793].

I can replicate this issue in my personal project and by also running the DiscreteCarryBug.zip that is provided above and porting it to latest Godot 4.0 version.

This was previously fixed in #48375

[JF-Werewolf]

Can confirm.
I'm using 4.2.2 stable and carry is acting exactly like discrete. Found some reports online of people experiencing the same.

[archead]

Tested, issue resolved, hats off to the devs.