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 (???):
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.
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?
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.
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.
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?