Expected Behavior
I would expect animation to replicate for all clients when having Animator as a child.
Actual Behavior
Issue Area: Studio Issue Type: Display Impact: High Frequency: Often Date First Experienced: 2021-05-28 00:05:00 (-07:00) Date Last Experienced: 2021-05-31 00:05:00 (-07:00)
Have you tried parenting the pet to the character? See if that works. Otherwise you are just going to have to fire all clients. As far as I know, animations only replicate from client to server if it’s the players character.
So both the part named “Pet” and the HumanoidRootPart have had ownership set to the players network? If so, I’m honestly clueless as I’ve not worked with pets before. I can try and work this out in studio, or you could wait for someone more experienced than I.
I assume the reason behind it is because the animation did replicate, it just didn’t loop.
For some reason doing AnimationTrack.Looped = true will loop the track on your end, but not on other’s.
This case becomes different if the animation was set to be looped in the Animation Editor, making the track loop no matter what you set it to, but atleast it loops for all clients.
I’ve had this problem before where my idle animation was being normal for me but on other people’s end it wasn’t showing up. When they started playing their idle animations I could see their animation for 2 seconds and then it would stop.
I can definitely confirm that I am having the same issue and other people as @Yozoh mentioned. As outlined in my post, this started happening when it was announced that using :LoadAnimation directly on AnimationControllers and Humanoids is being deprecated, which is well over half a year ago. This currently has a huge impact, especially since I rely on this for animating train doors, which means that players other than the driver of the train will not see the doors animating. This is extremely frustrating as it is of a critical importance in this type of games.
The problem seems to be with Network Ownership somewhat since when setting the network ownership of the train to the server, the doors animate for everyone, but when it is set to the driver, the door animations do not replicate even when played on the server.
I just encountered this issue as well by attempting to weld the model to the character.
A current work around for me is to use the align orientation and align position constraints.
Hi, I am still getting this bug.
I would like to handle my pet’s animations locally as I am handling the physics locally and it would be awkward to have physics and animations be separate. However, when I an animating my pet (even after creating animator on the server and setting the network owner to the player) the animations don’t replicate to the server.
Currently I am having to play animations locally and then also fire remote events to play them on the server. This is really annoying
A little bump because our team is currently experiencing this problem. It’s a major setback for us because we only realized it was a bug late in the development process of the update.
It doesn’t have to do anything with replicating properties. As I mentioned in my comment on this post, it’s only an issue when playing animations on a model whose network owner is a player. Only when the network owner is the server or the model is anchored from the server, the animation works fine. (AKA replicates for all players)
That’s yet another issue from what is said in the first post here seemingly. The first post seems to say that, when the ownership is set to the client and the client plays the animation, it does not replicate. What you are saying is that when the ownership is set to the client and the server plays the animation it won’t replicate, which is intended functionality since the client has ownership, not the server.
I recommend filing/bumping a separate topic for that if you think that should not be the intended case.
Hi everyone! Real sorry for the late reply.
The ticket is unfortunately still being looked at so we don’t have a solution for you all yet. I’ll bump the ticket internally. Thanks for the patience!