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
- 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
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!
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.
This doesn’t have appeared to fix replication issues for me
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
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?
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
Cries in a lot of Humanoid:LoadAnimation()
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).
It is literally the same as :LoadAnimation on Humanoids and AnimationControllers except you would be doing it on an Animator instance instead. The Developer Hub article on this provides you with the API and even an example necessary to get into using Animators.
EDIT: Also allows you to not be caught in that cross fire where replication may act weird (case where the client and server create their own animator instance). Since you’d have complete control over this you can decide where and when it can be used.
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…
Even AnimationTrack.Looped, it doesn’t replicate. I get mad at it…
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.
Read the response above by @CloneTrooper1019, explains it pretty well from the looks of it. LoadAnimation in a sense has always been a proxy to the Animator which is what’s actually doing the real work for replicating and playing animations. All that they’re doing is now discouraging the use of LoadAnimation on Humanoids and AnimationControllers . You still have to use the general method to get an animation track (:LoadAnimation) on the Animator, they’re simply saying not to use it on Humanoids and AnimationControllers due to those replication issues which happens if the server and client both try to create an Animator instance (which messes with replication).
Make sure to check the Developer Hub before creating a thread. If you’d like to read further on this, check out the article on the Animator instance and API usage here. Hope that helped clear up the confusion .
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’
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.
But i use default Animate Script (i forgot to mention)