Custom Character not replicating animation

The animation only seems to play on the client. Here’s the gist of it:

local CustomChar = game.ServerStorage.CustomChar:Clone()
CustomChar.Parent = game.Workspace
Player.Character = CustomChar
game.ServerStorage.Animate:Clone().Parent = CustomChar -- Default animate script

Try adding this to you code:

for _,d in pairs(CustomChar:GetDescendants()) do
    if d:IsA("BasePart") then

Have already tried that; Makes no difference, so I removed it. As far as I know, setting a model to Player.Character already gives them networkownership

Instance an Animator from the server first and then give network ownership of the rig’s root to the client.

local Animator ="Animator")
Animator.Parent = CustomChar.Humanoid

Network ownership of custom characters is not implicitly passed to the client if you’re manually changing what their character is. If you rely on internal spawn behaviour then yes, part of the character construction protocol is assigning network ownership. Not the case when you manually take over characters. Handing network ownership over is required.

You only actually need to set the root of the assembly’s network ownership to the client as all other parts will inherit network ownership of the root. Recursively setting all parts’ network ownership is not necessary (cc @Fm_Trick); do it only for the HumanoidRootPart.


I see. Is there any official source stating that/is there any way to test that?

Also, Root part is deterministic. In the case of a character, HumanoidRootPart is the root part (as long as nothing is 10x or greater than it in size). In a model, does setting PrimaryPart have the same effect as Root? (Will setting network owner of PrimaryPart also have the same effect?)

You can also set the network ownership of a root and then check what the owner is via GetNetworkOwner on a part you did not configure network ownership for. For example; set the HumanoidRootPart’s owner to the server then check the network owner of the head.

No. You are capable of having an assembly root that isn’t the PrimaryPart. You can influence what is chosen as the root using the RootPriority property of BaseParts.

More information on assembly roots:

1 Like

Thanks, I see. One thing the wiki is not clear about/inconsistent about is Mass/Size. It says " A part with a higher RootPriority will take priority over other unanchored parts with equal Massless values and a lower RootPriority." Does this mean mass overtake priority?
IIRC mass is based on size.

Because the article on 'Understanding Root Parts; state that the rule is in the following order: 1) Anchored 2) Not Massless 3) RootPriority 4) Legacy (Size, multipliers, etc)

This statement should be taken literally. Suppose you have two massless parts: the one with a higher RootPriority will take precedence over the one with a lower root priority. The behaviour is the same with massless off. Parts that aren’t massless are sorted higher to become roots of an assembly.

Mass itself isn’t taken into account when determining which part should be the root (or at least I believe this is the case), only whether or not the part is massless. Whatever order is described on Understanding Root Parts should be the one you go by.

1 Like

Thanks, I just tested it and that seems to be the case.