So I am leaning towards “this is a roblox bug” on this one, but I figured I would ask because why not.
So I am working on animations in my game. Originally, I was loading animations on the server side but that came with its own set of fun (also probably roblox bug related) problems.
So I offloaded animations to completely client sided.
I am writing the system that replicates animation to a client that just loaded in.
So to condense down what I have replicating (it’s also replicating properties and whatnot), this is what I got on the client:
for i=1, #replicationData do
local controller = replicationData[i].animationController
for k,v in pairs(replicationData[i].animationTracks) do
local animation = Instance.new("Animation")
animation.Name = v.Name
animation.AnimationId = "rbxassetid://" .. k
track = controller:LoadAnimation(animation)
local internalProperties = v.internalProperties
if internalProperties.Playing then
track:Play(unpack(internalProperties.Playing))
end
end
end
So things to note:
I am using animation controllers, not humanoids
My actual code appears to be working, as the server never plays the animation and the client definitely does play it correctly
Another client has physics ownership
The rig in question has another humanoid seated to it with a VehicleSeat, which seems to really throw things off (hence why im not just having the server handling replication automatically by playing it there)
The problem is the animations don’t actually play until the client I am replicating to is right next to the damn rig.
I ran into this issue the other day too.
I was trying tomake a cool robo fighting game and cause the player was nowere near the robos, animations wouldnt play.
local rootPart = controller.Parent:WaitForChild("HumanoidRootPart")
local oldCF = rootPart.CFrame
rootPart.CFrame = torso.CFrame
wait()
rootPart.CFrame = oldCF
So I was able to get animations working properly by forcing the rig in question to be at the same position as the players character for a frame. Super hacky, and probably a roblox bug, but
I know this is an old post, but I used to have this issue very frequently and I recently discovered a fix that worked in my circumstance. Hope this helps you too.
All I did was assign network ownership OF ALL THE PARTS in the model to the player who is controlling the rig (not just the HumanoidRootPart or Torso etc) and now it works like a charm.
for _,v in pairs(Model:GetDescendants()) do
if v:IsA("BasePart") then
v:SetNetworkOwner(Player)
end
end
Not sure if you’re aware of this or not, but you could just check if the descendant is a BasePart, since SetNetworkOwner is limited to BaseParts. I feel like pcalling this way is bad practice, since it catches errors when its called for non-BasePart descendants.
for _, v in pairs(Model:GetDescendants()) do
if v:IsA("BasePart") then
v:SetNetworkOwner(Player)
end
end
That’s not how pcall is supposed to be used, necessarily.
The calls still error if called on a non-BasePart instance. The pcalls catch said errors and don’t terminate the script. The errors aren’t sent to the console either because of the catching behaviour of pcall. Pcall is commonly used for custom error handling, especially with DataStores. In this case, you’re throwing away the return values of pcall.
Why can you not just check if the descendant is a BasePart and call the API accordingly instead of sweeping errors under the carpet? This is bad practice.
I did it because when I was making this method of solving the bug I wasn’t sure if base parts were the only instance that supported the SetNetworkOwner function and I wanted to be sure that everything that could possibly have that function was being assigned to the client/player.
