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.
27 Likes
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 
Reports
- AnimationTrack:AdjustWeight improperly replicates
- Setting animation weight to 0 permenantly freezes it
- Properties of AnimationTrack set on the server only replicate the value when read, but the behavior is not replicated
Discussions on behavior / quirks
21 Likes
I would find somebody who can help you in this situation. I would be fine in doing so but i have other things to be doing. I wish you the best!
3 Likes
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.
8 Likes
This doesn’t have appeared to fix replication issues for me
My Screen:
Another players screen
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
15 Likes
Disables animation replication for the client.
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.
Hopefully that wasn’t too confusing?
9 Likes
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.
1 Like
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.
5 Likes
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
2 Likes
Cries in a lot of Humanoid:LoadAnimation() 
1 Like
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.
2 Likes
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).
2 Likes
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…
6 Likes
Even AnimationTrack.Looped, it doesn’t replicate. I get mad at it…
1 Like
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.
5 Likes
It’s as simple as doing this.
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’
19 Likes
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.
5 Likes
But i use default Animate Script (i forgot to mention)
3 Likes
Read the post. It explains everything.
6 Likes
I noted that the default Animate Localscript use this deprecated property. I’m right?
If is true, this Localscript changes to the future?
4 Likes