AnimationTrack.Changed does not work

Help and Feedback Scripting Support
#1

When you load an animation, its length is always 0 until it’s fully loaded, so the logical way to wait for it to load is to do this:

local anim = Animator:LoadAnimation(...)

if anim.Length == 0 then
    anim:GetPropertyChangedSignal("Length"):Wait()
end

I was surprised to find out this doesn’t work because that signal is never fired when the length changes from 0, I confirmed this by doing:

local anim = Animator:LoadAnimation(...)

anim.Changed:Connect(function(property)
    print(property) -- Does not print
end)

anim.Priority = Enum.AnimationPriority.Action
anim.Priority = Enum.AnimationPriority.Core

We should expect the code inside the Changed event to print, but it doesn’t, so either I am missing something or this is a bug.

1 Like
#2

repeat task.wait() until track.Length > 0

1 Like
#3

Of course that’s the alternative, but it shouldn’t be an option to begin with, I hate polling

#4

No clue why either events do not fire properly when those values are set by the engine

Unfortunately it seems polling will be your best bet here, there is no Loaded property/event for AnimationTracks nor does it seem one will be added in the near future (???):

#5

Not having IsLoaded for AnimationTracks is fine because the Length property suffices to get both the length and to tell you when the animation is loaded (by doing the GetPropertyChangedSignal("Length"):Wait()), the problem is that the events in AnimationTracks are completely broken and don’t fire at all, I was hoping that someone would report this upon seeing this post cause clearly it’s a bug.

#6

You are correct – not a property, but a .Loaded() event such as the ones used by sounds would be more practical than GetPropertyChangedSignal("Length"):Wait()), yes? Maybe try Engine Bugs or a new Feature Request?

1 Like
#7

Yeah a .Loaded event would be less verbose and more obvious to use than GetPropertyChangedSignal, but it’s not needed, I reckon the reason they didn’t add it is because .Length hits two birds with one stone.

I unfortunately can’t post there because Regular rank is no longer granted since 2020, so my best bet is for someone with regular rank to see this and report it.

1 Like
#8

Engine-handled properties of instances do not fire the .Changed event for those instances when their values change.

For example, a “Sound” instance’s “TimePosition” property.

#9

I don’t understand this sentence, what’s somethig not engine-handled?

I was able to get the changedsignal for many properties for sound like TimeLength, so doing this:

local sound = ...
if sound.TimeLength == 0 then
	sound:GetPropertyChangedSignal("TimeLength"):Wait()
end

is the equivalent of doing this:

local sound = ...
if not sound.IsLoaded then
	sound.Loaded:Wait()
end

Yet I can’t do the same thing for AnimationTrack’s Length, so what’s the difference?

#10

I’m referring to internally handled properties which change at a frequency greater than once per frame. track:GetPropertyChangedSignal("Length"):Wait() won’t fire in circumstances where the track is loaded before the RBXScriptSignal object is created.

#11

I don’t think that’s the case because print(typeof(anim:GetPropertyChangedSignal("Length"))) prints RBXScriptSignal which shows that it’s created long before the animation is loaded.

How do you know if something is handled at a frequency higher than once per frame?