Animations not replicating from client

I am playing AnimationTracks loaded into an AnimationController from the client, but they do not replicate to the server and to other clients

The client owns the physics for the NPC, and the Handle (root part) has priority 127
All of the constraints are created offline or on the server (and I tried initially creating them on the client but that doesn’t change anything)

The animations the client loads are parented to workspace.anims and I don’t modify the AnimationTrack properties such as Weight, Looped, Priority, and Speed

2 Likes

Things like animations, duplicates of models, etc do not replicate from client. I suggest putting a server script into ServerScriptService and using RemoteEvents, personally.

1 Like

This is a weird artifact with animations and replication. Try parenting the animation on the server and see if it makes any difference.

This is not correct. Animations DO replicate with network ownership, which is why the client can move without the server.

3 Likes

AnimationTracks are locked to nil parent (I tried LoadAnimation on server.Parent=workspace)
The Animations are parented to workspace.anims

Does it work if you load the animations from the server? I believe this is a network ownership issue.

Really? I’ve personally found that animations and such do work from the client, but not for other players.

An example is in my game, where I duplicate a Fire model, and the other clients cannot see it, only the placing client can.

It has to be something with the implementation. When another player moves, you see them doing the walking animation. This is due to the animate script.

If that were to work, it is not practical to make my own play animation API, and I would rather report this as a bug

1 Like

You could always just make your own replication system. Filing a bug report is a good idea. In the mean time you could just use custom replication:

Client starts animation for themselves
Client fires server
Server fires other clients
Other clients play animation on the original client

1 Like

Apparently, the priority of the animation doesn’t replicate unless you set the priority in an animation editor.

If you’re already doing that, there might be an engine bug you should report.

3 Likes

Network ownership does not replicate animations being played from the client, it only gives a player control over the position of a part. The default animation scripts read humanoid state changes and plays the animation associated with that specified humanoid state. Humanoid state changes are replicated automatically to all clients.

This is shown by the inability for exploiters to replicate any animations played through their script executors

Setup a remote event system to notify all clients whenever an animation needs to be played. This is essentially how the default animation script works, except you have to manually replicate the character state or character action to all clients.

This error was occurring in my game for a while now, and I didn’t know what was causing it until I tried changing the animation properties in the animation editor to have the Priority set to Action. After doing this, the animations began to replicate for me.

even with action animation priorities it doesn’t replicate for me

It’s not supposed to replicate through network ownership.

1 Like

Ensure that no two animations in your Loadanimations have the same ID. If you want the same animation, then just save it again under a new name. When I set my priority to action, it only worked once the animations were all different ID’s.

Setup a remote event system to notify all clients whenever an animation needs to be played. This is essentially how the default animation script works, except you have to manually replicate the character state or character action to all clients.

I’ve never had to do this, playing animations on one client via the typical humanoid animator replicates it to all other clients.

A quote from @colbert2677

You are typically encouraged to entrust the running of animations to the client. This is because they have network ownership over their character, so animations can reasonably replicate as they operate on Motor6Ds in the character and performance is relatively smooth. There isn’t any inherent harm in running an animation on the server. I’d say this kind of scenario is purely preferential or what seems to work better for your case.

Set the diving animation to the highest priority. If I recall correctly, all Roblox animations use the Core priority with some (such as jump) use idle. None of them use Movement or Action.

As colbert mentions, there are times when you’d want to load and play anims on the server. However in many cases this is just a huge inconvenience.

Okaayyyy, it seems like there are a mess of responses

Not sure if somebody said this, but I guess I’ll go ahead and make something clear:
Animations replicate onto client. When an animation is played, for example, from a PlayerGui, it will work.

However, instances that are not part of the StarterCharacter will not replicate, unless it is a part whitelisted scenarios and instances by the core server and core client alike. In your case, like most others, the pet is not a part of the StarterCharacter (a whitelisted scenario). You will have to play the animation from the server if you would like others to see it.

If you need a more in-depth description, lemme know dude :wink:

1 Like

Animations played on one client do not replicate to other clients. Please take a look at what the default animate script is doing before you make that statement.

-- connect events
Humanoid.Died:connect(onDied)
Humanoid.Running:connect(onRunning)
Humanoid.Jumping:connect(onJumping)
Humanoid.Climbing:connect(onClimbing)
Humanoid.GettingUp:connect(onGettingUp)
Humanoid.FreeFalling:connect(onFreeFall)
Humanoid.FallingDown:connect(onFallingDown)
Humanoid.Seated:connect(onSeated)
Humanoid.PlatformStanding:connect(onPlatformStanding)
Humanoid.Swimming:connect(onSwimming)

It is not replicating animations to the other clients. It is actually replicating the humanoid states to the other clients so that they can play the animation associated with the current humanoid state.

The only thing that the client has control over is the position of a part that they have network ownership over. The network ownership of StarterCharacter's primary part is automatically asigned to the character belongs to, unless you decide to use a custom starter character, in which case you would have to assign network ownership manually.

:man_shrugging: they all have different ids as well