Okay! I tried the given solutions, and have looked into custom rigs and animation controllers as the post below detailed. However, I’ve ran into a weird issue.
I am not sure how to exactly chain animations, so when I try to play an idle animation for the blast doors in their open position, after the opening animation is done – it flickers temporarily when the opening animation is finished and transitions to the temporary idle animation.
I have tried everything. Messing with the priority values, pausing, messing with the weight values! Yet it’s obvious I’m missing something…
My code is relatively simple too, it’s inside a function triggered by the proximity prompt. Primitive purely for testing purposes.
local animator = script.Parent.AnimationController:WaitForChild("Animator")
local openTrack = animator:LoadAnimation(open)
local idleTrack = animator:LoadAnimation(idleO)
openTrack.Priority = Enum.AnimationPriority.Movement
idleTrack.Priority = Enum.AnimationPriority.Idle
openTrack:Play(0,1,1)
openTrack.Stopped:Wait()
openTrack:Stop(0)
print("Opening done, causes it to flicker")
idleTrack:Play()
task.wait(5)
idleTrack:Stop(0)
print("Idle done, no flicker")
openTrack:Play(0,1,-1)
openTrack.TimePosition = openTrack.Length * 100/100
openTrack.Stopped:Wait()
openTrack:Stop(0)
print("Close done, no flicker")
Might be some weird replication thing. Have you tried putting a zero here for the fade time?
It also says on the docs not to use stop with zero fade time:
It is not recommended to use a fadeTime of 0 seconds to try to override this effect and end the animation immediately as presently, this causes the AnimationTrack poses to freeze.
local opening = true
local animator = script.Parent.AnimationController:WaitForChild("Animator")
local openTrack = animator:LoadAnimation(open)
local idleTrack = animator:LoadAnimation(idleO)
openTrack.Priority = Enum.AnimationPriority.Movement
idleTrack.Priority = Enum.AnimationPriority.Idle
openTrack:Play()
print("Opening started")
openTrack.KeyframeReached:Connect(function(NearEnd)
if opening == true then
print("Opening animation near end")
idleTrack:Play()
end
end)
openTrack.Stopped:Wait()
print("Opening stopped")
openTrack:Stop()
print("Idle track begin")
task.wait(5)
idleTrack:Stop()
print("Idle done")
print("Closing begin")
opening = false
openTrack:Play(0,1,-1)
openTrack.TimePosition = openTrack.Length * 1
openTrack.Stopped:Wait()
openTrack:Stop()
print("Close done")
openTrack.Ended:Connect(function()
openTrack:Destroy()
idleTrack:Destroy()
openTrack = nil
idleTrack = nil
topDoor.CFrame = topDoor.CFrame
lowDoor.CFrame = lowDoor.CFrame
print("Clean up done")
end)
I came to the conclusion that for whatever reason, even if no wait is called, there is a slight delay in a new animation being played, meaning a seamless and instant transition to the new animation, in this case our idle animation being not possible. Resulting in that conflict between the two animations. The strange part is that even if top Enum.AnimationPriority is given to the new animation, the conflict will still occur even if brief. The same applies for weight and fadeTime parameters which from what I understand are supposed to also help with animation transitioning/playing multiple animations at the same time.
This means that I had to edit the animation, add in two extra key-frames before the end (essentially adding in a few microseconds of nothing happening once it reaches it’s fully opened state) and then name those key-frames so I can use the KeyframeReached() event to trigger the idle state animation before the opening animation can actually end. I know KeyframeReached() is deprecated, and I’ll look into it when I have more time to do so.
Frankly, I am confused that I had to do that to get it to work and I am honestly not certain if it is intended to function this way. But, at least it works.