SignalBehavior Deferred and animation stopping and playing

This is a bad example but this use case can come up in my game.

AnimationTrack:Play()
AnimationTrack:Stop()
AnimationTrack:Play()

this results in the animation not being played despite play being the last called. This only happens with SignalBehavior being set to deferred… Anyone know a work around that still allows you to stop and play a animation thats already playing

2 Likes

That’s probably because you haven’t implemented a task.wait()? Try implementing a task.wait() between these functions.

AnimationTrack:Play()
task.wait()
AninationTrack:Stop()
task.wait()
AnimationTrack:Play()

You can also try using Heartbeat instead:

AnimationTrack:Play()
Heartbeat:Wait() -- Assuming that Heartbeat is equal to game:GetService("RunService").Heartbeat
AnimationTrack:Stop()
Heartbeat:Wait()
AnimationTrack:Play()

from what I know if :Play() is called again on the same AnimationTrack it should just restart it, how can this exactly happen in the game?

that works but its just odd to me that a yield is required

I have a combat system where it stops the current playing combat animation before doing the next combat animation. so if you do the same action twice, you get a sequence of events that looks like my code snippet

That’s because you’re executing three functions at the same time. These functions are to play and to stop the sound. If you execute them at the same time, the game will almost like play and stop at the same time, and it can result in problem as you see.

If the actions you are referring to are for example, an idle and an action animation you may want to change the Priority of the animations.

This can be achieved from both the animation editor and code.

1 Like

For example:

local function A()
    print("A function has been called")
end

local function B()
    print("B function has been called")
end

A()
B()

-- Would print both at the same time. The order of the calls do NOT affect it.

A()
game:GetService("RunService").Heartbeat:Wait()
B()

-- Would print B after the next Heartbeat event (if the game is running at 30 fps, it would take 1/30 seconds to play). If it is running at 1fps, it would take 1/1 seconds to play. 0.0333 and 1 seconds, respectively.

I see what you mean and appreciate the example, but code executes from top down… A() would always print first in your example, if animation Play and Stop worked like that then my issue wouldn’t exist. It looks like internally roblox uses some sort of signal which gets deferred. I have found a solution based on y’alls answers. Thank you

What I mean is that the order of the function and the time they will be called depending on their order is negligible, to say the least. Function calls typically happen very quickly, as they are just a few lines of code. The time it would take for them to run, if there is no “wait” to pause the script and resume it, is highly close to 0.

Then, roblox would be executing A() function first and b() subsequently, unless there are explicit pauses or delays. That’s why “wait” exists.

A() would be, indeed, called first, but then you can check that almost instantly B() would be called. If scripts had a significant time to execute the next line of code, it would take much time to run all of it, consequently affecting the whole code.

That’s why all lines of code must proceed very quickly, including the subsequent lines. Generally, the time it takes for roblox to run the next line of code is really close to microseconds to milliseconds.

print("Print one!") -- Would execute after 1/1,000,000 of a second. One millionth of a second or 0,000001 seconds. Depending, it can execute after 1/1000 of a second. One thousand of a second or 0,001 seconds.
print("Print two!") -- Would execute after the Print One. So it would be still the same time after it executes the first print.

-- It means that, in theory, it would take 1 second to process 1 million lines of code if the lines of code were executing at 1/1,000,000 of a second. However, in practice, the actual execution of the code can vary due to factors like server load, system resources, and more.

Thus, in your example, the soundtrack would play and then stop after 1/1,000,000 of a second or even less.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.