I have a tool that loads an animation when the parent switches to a parent of a humanoid(when its being equipped by a player or NPC).
When i set the tool to nil and then set it back to the same NPC then it checks if that same humanoid has the animations loaded and if the animation exists then it destroys them.
it also prints hot many animations are loaded into the humanoid
When i used Animator:GetPlayingAnimationTracks() it returned all the animation tracks that are loaded in the animator and the issued is that when i try to destroy one of them, the animation track wont be destroyed. It only happens to animations that are looped by default and animations that are not looped get like 50 copies of it
Part of the code shows it here:
local anims = tool.Parent.Humanoid:FindFirstChildOfClass("Animator"):GetPlayingAnimationTracks()
if #anims > 0 then
print(#anims)
for i,v in ipairs(anims) do
v:Destroy()
v = nil
end
end
(The animation inside the tool is with empty id please add an animation that is looped by default to see the bug then upon running wait for the script to print 256x to see the bug)
Here is a repo file: Place1 - Copy.rbxl (82.8 KB)
Expected behavior
I expect the animation to be destroyed when the script is destroying them
:Destroy() doesn’t actually destroy an instance straight away. What it does is set the Instance.Parent property to nil, lock the Instance.Parent property so it can’t be changed, and disconnect all RBXScriptConnections. This means, in your other scripts, when the scoped variables which pointed to that track eventually get cleaned up by the garbage collector, the track itself isn’t cleaned up because it’s still being played on the animator or it is still being referenced by a script, whether it be a core script or one of your own.
You mentioned how Animator:GetPlayingAnimationTracks() returned all of the tracks loaded onto the animator; this means that they are still playing, and therefore can’t be cleaned up. I also just tested myself and the animation did not get destroyed until I forcefully stopped it, which also explains why it only happens to looped animations, like you said.
I’m pretty sure this is expected behaviour, just stop the track with AnimationTrack:Stop() to stop it before it gets cleaned up.
