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.
2 Likes
We do use StreamingEnabled, and the max speed for players on personal vehicles is 50. So not too fast.
1 Like
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. 
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.
3 Likes
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.
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.
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 
?
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 CFrame.new().
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?
3 Likes
How did you get it to fix temporarily?
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 = {}
animator.AnimationPlayed:connect(function(track)
if not fixedAnims[track] then
fixedAnims[track] = true
player.Character.Parent = replicatedStorage
player.Character.Parent = workspace
end
end))
2 Likes
I’ve been taking a look at this issue and originally I was able to reproduce the problem regularly. Since then, we’ve made some changes to the joint replication and I believe it may have fixed the issue. Is anyone still having this issue?
5 Likes
Don’t necessarily want to bump more than necessary, but for context, CodeWriter and I talked in DMs and my repro seems to be fixed.
2 Likes
This topic was automatically opened after 6 days.
I’m still having a similar animation replication issue. A descendant animator of the character model doesn’t replicate.
Hey there,
The original issue on this thread was confirmed fixed by CodeWriter and Amber, We will close this thread as fixed. There are been many changes to Animation and replication over the last couple of years. Let us know if the issue persists and we will re-open this thread.
1 Like