A lot of people seem confused about deprecation in this thread or whether this changes any existing behavior.
The Animator object was already doing the heavy lifting of the animation system. The LoadAnimation functions that were deprecated are not going away and still work the same as they always have, it’s just that their use is not recommended going forward. Internally, they have always aliased to the underlying Animator object, creating it if it didn’t exist, and directing the call to that object instead.
The key issue here is synchronization between the client and server when it creates the Animator object with LoadAnimation on the Humanoid/AnimationController classes.
If a call is made to LoadAnimation on the server and client at the same time, both ends would try to create their own Animator objects. This causes replication to fail because the client would send replication through the Animator it created, while the server would expect to be receiving events from the Animator it created.
The solution is simple. If you have the Animator object pre-made on the server before the client ever calls LoadAnimation, this won’t ever be a problem and you can continue to use the deprecated functions as normal.
This deprecation is ultimately focused on preventing this client-server desync pattern from accidentally happening in the first place. By making the client wait for an Animator to be made on the server in the first place, and using it Animator:LoadAnimation instead, the problem will cease to occur.
On every animation step, the animator iterates through the joint tree and applies transforms to valid active joints that have fully replicated. Nothing will permanently break if a part loads or unloads. It will still apply transforms to valid parts of the joint tree from any clump of parts.
It’s great that this is being cleaned up for consistency reasons, and guaranteeing replication to developers, but in the past year of working with custom animations my main issues have been bugs with Animation replication that don’t seem to get fixed with this change.
One of which has been an ongoing issue since 2016 that has yet to be adressed
I can definitely see and agree with the reasons why this was done, but the way this was executed caused quite a lot of confusion for many developers such as myself, which many can probably vouch for.
This was largely due to the lack of any official announcement for quite some time after the changes had already been made, combined with how animations were temporarily broken and acting completely abnormally during this period. Many began believing this was an error, and rightfully so, as no announcement had been supplied.
Perhaps for future changes that affect such widely-used methods, it’d be awesome if we could get warning in advance before the changes are made. I’m pretty ignorant when it comes to the development process of launching updates to studio like this, though, so apologies if I’m speaking nonsense and there’s some sort of reason for the delay.
I have stolen the code from the wiki and animations are still having issues replicating for other clients
script.Parent.Parent.Values.DoorsOpen.Changed:Connect(function()
if script.Parent.Parent.Values.DoorsOpen.Value == true then
local animator = script.Parent.Rigged.AnimationController:FindFirstChildOfClass("Animator")
if animator then
local animationTrack = animator:LoadAnimation(script.Parent.Rigged["Door"..script.Parent.Parent.Values.DoorSide.Value])
animationTrack:Play()
animationTrack:GetMarkerReachedSignal("Open"):Connect(function()
animationTrack:AdjustSpeed(0)
end)
end
end
end)
Am I missing something? What makes it worse is that despite using identical animations and scripts, only 1 of the doors actually work while the other 2 dont
The client that creates the Animator object would be responsible for managing animations on the object which has the Animator. If the server creates it, the server replicates playback to everyone who the Animator object was replicated to. It’s also what allows clients to replicate playback of animations on their characters and why Animate can be a LocalScript with no remotes involved.
The server would not replicate animation playback to clients who delete the Animator object or create it locally. Same goes with clients playing animations on things they have network ownership over: the client who deleted the Animator will not see animations that the owner client plays. Take for example Player2 deletes the Animator in Player1’s character locally and they jump. Everyone except Player2 will see the jump animation play on Player1’s character.
Well, after this decision, how can I load the animation using Animator…? I don’t know much about these. All I know is insert an object called Animator and don’t know what to do with it.
Oof, been hearing about these getting deprecated the past week. Luckily I’ve been working on my framework revamp that uses Animators instead of Humanoids. I hope this improves animations because I’ve been getting animation replicating issues for my game when using Humanoid:LoadAnimation(), from the animation not stopping, or the animation not playing.
Even the API were marked as deprecated i can still animate it with this Animator huge improvement to Roblox, we can now make local/global animations! :3
Yea I realized this point but he did mention something about us having to use the AnimationController or a Humanoid in order to play animations using the animator (as one of these being the parent of the animator). I was just wondering when we can expect to move away from having to use AnimationControllers or Humanoids specifically for animations to be played.
We have always been able to, they are now just deprecating it so that the method of using :LoadAnimation is discouraged. The animator instance has existed for a while now (at least as long as I’ve been developing).
The middle ages where client and server were fighting over the power of who could replicate the Animator first
In all seriousness, thank you for telling us how it was working behind the scenes. It’s good to know why things are depreciated (some things in the past were pretty useful and didn’t have simple alternatives). Now it’s time to update all my stuff…
Im somewhat confused here, is it still OK to use LoadAnimation, since it makes the Animator for you? From what i’ve read it seems that using Animator will require remote events to play the animation which to me sounds much more confusing and complicated then just using LoadAnimation.
Edit: I see the issue now with the fact that creating it on a localscript using LoadAnimation has replication issues, but I do not understand why instead of deprecating LoadAnimation they fix the issues with LoadAnimation, which leads for me to believe im not understanding the full thing.
Let’s say this is how it looks like in your script.
Instead of loading it in the humanoid you’d wait for the animator.
then load it into the animator. So instead of Humanoid:LoadAnimation, you’d replace ‘humanoid’ with ‘animator’
I’m actually incredibly happy you brought this up. I encountered this a while ago and I find it frustrating that after all this time, it still exists. It’s like a bad omen at this point.
