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
Describe the bug
If a non-blocking character animation is started, and then character's Move command is called (either blocking or non-blocking), then, as soon as character arrives to destination and stops:
if animation was already complete, then character's frame resets to frame 0 of the animation loop and keeps that;
if animation was still playing, then it resets to frame 0 and continues playing to the end again.
AGS Version
At least in AGS 3.4.3 - 3.5.0, but could be an older issue.
To Reproduce
Create a separate view with 1 loop and few frames;
Observe the problem.
Note you may experiment with the movement and animation speeds to see both potential outcomes described above.
Expected behavior
Character stopping after movement should not reset (or otherwise affect) ongoing animation if the view is locked.
Known workarounds
The simpliest known is to change coordinates by hand instead of calling Move, but this is only useful if you are moving without walkable areas, as you won't be able to utilise pathfinding, for example:
player.LockView(VMOVEANIM);
player.Animate(0, 2, eOnce, eNoBlock);
int current_x = player.x;
while (player.x > current_x - 100)
{
player.x -= 5; // change 5 to the wanted speed
Wait(1);
}
ivan-mogilko
changed the title
Character's forced animation resets to frame 0 if char stops moving
Character's explicit animation resets to frame 0 if char stops moving
Sep 27, 2020
Most recent report: https://www.adventuregamestudio.co.uk/forums/index.php?topic=58446.0
Describe the bug
If a non-blocking character animation is started, and then character's Move command is called (either blocking or non-blocking), then, as soon as character arrives to destination and stops:
AGS Version
At least in AGS 3.4.3 - 3.5.0, but could be an older issue.
To Reproduce
Note you may experiment with the movement and animation speeds to see both potential outcomes described above.
Expected behavior
Character stopping after movement should not reset (or otherwise affect) ongoing animation if the view is locked.
Known workarounds
The simpliest known is to change coordinates by hand instead of calling Move, but this is only useful if you are moving without walkable areas, as you won't be able to utilise pathfinding, for example:
May be or not relevant to #935.
The text was updated successfully, but these errors were encountered: