Animations Not Replicating Correctly

Reproduction Steps
Steps To Reproduce

  1. Play Overlook Bay
  2. Find other players who have their Personal Vehicle out and using it

Direct Links

System Information

Windows 10

Intel i7-9700k @ 3.6 GHz
NVIDIA GeForce GTX 2070

Expected Behavior
The player’s personal vehicle is replicating correctly when the animation is playing.

Actual Behavior
The player’s personal vehicle will not be replicating anything from the animation that is playing.




Issue Area: Engine
Issue Type: Other
Impact: High
Frequency: Constantly
Date First Experienced: 2021-05-22 00:05:00 (-04:00)
Date Last Experienced: 2021-06-18 00:06:00 (-04:00)
A private message is associated with this bug report


Could you provide more detail as to what you’re doing? Can you make sure that the Animator object inside the humanoid is created on the server rather than on the client? If it is created on the client, animations will not replicate as per expected behavior.

I have it check for an Animator object before it could play any animation on the client. If one doesn’t exist on the client, it simply won’t play it.

Hi, thanks for the report! I am unable to reproduce this issue on my end. Does it still occur on your side?

Yes it still does, the issue only happens to other users not yourself. And I am unable to reproduce this issue in studio, it only happens in a live server.

Does the game use StreamingEnabled, and are these players ever teleporting or moving really fast? We have had similar issues only in live servers and not in studio, in our game Tropical Resort Tycoon, and have never really been able to find the root of the issue.

1 Like

We do use StreamingEnabled, and the max speed for players on personal vehicles is 50. So not too fast.


I am getting an issue where sometimes, only in live games, certain custom joints in animations don’t replicate. This is on a game that has StreamingEnabled set to true, but as I’ll later show in the repro, this doesn’t seem to be the cause.

Specifically, this happens for a custom joint created between the player’s right hand and a weapon instance, and the behavior is similar to what is shown in the OP.

Running a player + servers test, these animations always replicate correctly. However, I was able to generate a repro that only works on a live game with the following steps:

Step 0: Download this repro file
AnimationReplicationRepro.rbxl (46.0 KB)
Step 1: Go into the animation editor and load the “MovePartDown” animation. Export this as your own animation on the roblox website so that it can be displayed in the live game.

Step 2: Copy the ID of your new animation into here:

Step 3: Publish this place to a roblox game.

Step 4: Start the game on a higher-end, desktop device, and walk a fair distance from the spawn.

Step 5: Load the game on a low-memory, low-end mobile device, and click the “Add Custom Part & Start Animation” button. image

On the mobile device, the whole animation loads correctly, shifting the part down; however, on the desktop device, it will not shift down but instead stay in the upwards, unanimated position:

If you move closer to the low-end-device’s character, the animation will actually replicate correctly. Clicking the “Add Custom Part & Start Animation” button will allow you to reset this, and see at what distance the the player’s animation will fully replicate. In this case it seems to be a very short distance indeed.

Takeaways from investigating this bug:

  • This bug is NOT dependent on StreamingEnabled; turning this off on the repro I was still able to get the same result.
  • I made the server tell the client to run the animation exactly when the part is created to model what happens in my game. It seems that this is not a race condition issue, so if you create the part, wait a second, and then load the animation, the custom joint’s animated transform will still not replicate.
  • This only happens when there are custom joints. Changing the animation to contain regular R15 parts (such as raising the arms up), the arms will replicate, but the custom joint itself will not.

    Moving close:

It seems like the transform of the custom joint itself is what is not replicating correctly, and only replicates from the low-end client to nearby players based on throttling that’s determined by the low-end client.

Workaround: You could use animation events and a custom script that listens to these as the animation plays, and adjust the transform if found. This is tedious and may require some hardcoding.

Alternatively you can run an animation on an invisible proxy character on the client every time an animation with custom joints plays, and adjust it on the client-side AnimationTrack that’s playing it. This could become performance intensive.

There’s not a great workaround. Animated custom joints are de-facto broken until this bug is fixed.


Another bypass is by adding a weld and an invisible part (or by equipping a Tool). Then the animation works correctly.

What do you mean here? Welds can’t be animated through roblox’s animation system. Would you be able to make a patch that works on the repro place in my last post?

I also have more custom animated joints than just the “right grip”; I have joints that attach to the head, back, and sometimes left hand with my game’s props.

tool animations are broken aswell despite having a motor6D to animate them

1 Like

Yeah, I can update the repro. But basically, if you play the animation and add a weld to the character, the animation will replicate itself correctly to all users. I noticed this earlier today when I was testing around in Overlook Bay.

Here’s a workaround repro:

AnimationReplicationReproWithWorkaround.rbxl (46.8 KB)

1 Like

Awesome! I tested the repro and it definitely does fix the issue.

Digging deeper, it looks like just adding this welded part the moment after the custom joint is added on the server isn’t enough. Specifically, the new welded part needs to be added after the client has replicated the custom joint as well. So you need to detect client-side when new Motor6D joints have been added to the rig, and then tell the server to create a welded part through a remote afterwards.
Also, both creating and destroying this welded part have the same effect—it forces the client to update the rig information that it replicates to other players.

I’ve created a general purpose patch, which can be placed in StarterCharacterScripts. This patch will dynamically detect whenever a new joint is added to the character, and then the server (with some sanity/flood checks) will create or destroy a new welded part in order to compensate.

Hopefully the way this patch works can be informative towards getting this issue fixed. Maybe we can get @gigagiele 's attention again :pray: ?

General purpose patch (put this in game.StarterPlayer.StarterCharacterScripts):
AnimationBugPatch.rbxm (3.9 KB)

Repro place with patch included:
AnimationReplicationReproWithGeneralPurposePatch.rbxl (48.7 KB)

1 Like

I’m having this issue too. This is a rendering issue, I believe. I printed my Transform value and it prints the correct value, however, its rendering if as if its

It’s fixed when they requip or when I walk near them. Unfortunately the fix you posted is not working for me.

NOTE: The arm isn’t part of the animation. I’m just doing some inverse kinematics on it. Focus on the blaster.

This is still a bug in World Zero, Robloxian High School and our new prototype as well. Insane how having the animation system in such a broken state is acceptable. Does anyone have 3rd party recommendations for running animations in Lua?

1 Like

How did you get it to fix temporarily?

Same issue here: Animations are broken

It would be really nice if this was fixed ASAP

Hey I found a pretty good, clean, and consistent fix for this. All you have to do is reparent the other object being animated, whether it be their character or something else into the replicated storage and then back to the workspace. This forces a replication update. You only have to do this once, so record your animation track so you don’t have to do it again.

Key note: Since this is a visual replication bug with OTHER players, you must have an event referring to their animator not yours

This is an example:

local fixedAnims = {}

	if not fixedAnims[track] then
		fixedAnims[track] = true
		player.Character.Parent = replicatedStorage
		player.Character.Parent = workspace
1 Like