Locally played animations don’t replicate unless the animator is a descendant of a player character. How do client NPCs bypass this? Parenting NPCs to the player character is an option but it’s very problematic.
Do major games just play them from the server or something?
Yeah, that’s usually what people do. The only issue may be latency.
If you want I can give you a code snippet as to how to play a server-side animation on a rig.
That’s why I’m avoiding it. But if it’s impossible, wouldn’t it lag the server in the long term?
Thanks, but I can figure it out, just wondering if it’s the only way.
Why would it lag the server? The biggest issue I think it may cause is memory leaks, and that’s completely preventable.
No problem 
Remote events can be useful too, but I assume you’ve already thought it out.
i think so,
using remote events wouldn’t really make much of a difference because latency is also a thing there
so NPC animations are very likely played server-side, atleast i play them server side
Idk, I have been taught that the server’s job is to handle data, so when I’m doing anything else on it I feel like it’s unnecessary and could be avoided.
Also, about the latency, it’s not a problem if it’s only for the players who didn’t trigger the animation. So I thought about playing the animation on the client who triggered it (this works), and then firing a remote event to play for all others. But when playing directly on the server wouldn’t it re-start the animation on the client who triggered it?
Yeah, latency is very annoying. Thank you, I guess I’ll be playing them on the server.
Also, just setting network ownership should allow the animations to be replicated, why is being a descendant of the character a thing?
I like your thinking, although unfortunately it’s best for servers to sometimes handle data (to offload client work even if it’s minimal), and in other cases there’s not much you can do to mitigate it.
I think so, but I’ve never actually tried it myself lol. You can always run a check on the client though (e.g passing the player who triggered the animation as a parameter).
Honestly, no clue. I saw someone in that thread argue that it’s something deprecated.
I’m confused. Why wouldn’t your animator be a descendant of a player’s character anyway?
I didn’t read the whole thread, I guess I’ll just throw it on the server, thank you.
Client NPCs.
I won’t close the thread in case anyone knows another workaround that’s not manually replicating the animations., it’s what I’ll be using. Thanks to everyone who answered.
I REALLY wouldn’t play them server-side, use a remote or signal event to the client to prevent latency. Suphi Kaner has a video on animations, and he uses a signal event to play the animation on the CLIENT.
Playing animations on the server is a sort of performance issue since the CFrames have to be constantly changed and then replicated (I think)
I think playing them on the server still troubles the client cause it has to replicate
You’re right, you’d have to pass the animations to the client before actually playing them on the client, just as your last reply said. That’s my bad.
Like sending a signal to the server and then using :FireAllClients() or making a function to fire every client except the one who triggered the animation to play the animation on all clients?
I like this approach, the client who triggered the animation doesn’t get affected by latency. Thank you!
what are client NPCs? asdasdasdasd
NPCs that don’t have their code on the server, they’re very good for a lot of reasons, I recommend you read about them.
I recommend playing the animation on the server but make sure to also set the NPCs network owner to the server to prevent glitchy movement when the player moves close.
If the client triggers an animation, play the animation on the client first, then FireServer, then fire all clients except the one that fired server (as you said, this completely removes latency)
If the server triggers the animation, fire all clients or change an attribute with a signal connected from a localscript
I like suphi kaners approach, where the NPCS are there, but they’re just data and information on the server and all the rendering and such is done on the client
1 would be like
-- Client Side, the client who triggered the animation
Animation:Play()
ReplicateAnimation:FireServer(animationInstance, NPC)
-- Server Side
ReplicateAnimation.OnServerEvent:Connect(function(plr, animInst, NPC)
for i, v in Players:GetPlayers() do
if v == plr then continue end -- DONT REPLICATE THE ANIMATION TO THE CLIENT THAT ALREADY HAS IT PLAYING
ReplicateAnimation:FireClient(v, AnimInst, NPC)
end
end) -- this function replicates to every client except for the plr
this COMPLETELY removes latency as you said
I know this thread has practically already been answered, but I do have a question that could potentially result in an ever greater reduction of latency.
What if all animation info is stored somewhere like ReplicatedStorage, and the events just have very simple parameters (ideally short strings and/or small numbers)?
From what I know, it may help reduce the time for sending information and lowering the chances of dropped events (which would force RemoteEvents to send another packet, causing even more latency).
-- server
ReplicateAnimation.OnServerEvent:Connect(function(plr, AnimID, NPCNum)
for i, v in Players:GetPlayers() do
if v == plr then continue end -- DONT REPLICATE THE ANIMATION TO THE CLIENT THAT ALREADY HAS IT PLAYING
ReplicateAnimation:FireClient(v, AnimID, NPCNum)
end
end) -- this function replicates to every client except for the plr
-- client
local RS = game:GetService("ReplicatedStorage")
local Anims = {}
Anims[1] = RS.Anims.WalkAnimation
Anims[2] = RS.Anims.RunAnimation
-- etc.
local NPCs = {}
NPCs[1] = workspace.NPC1 -- yeah i know not the best example lol
-- etc.
ReplicateAnimation.OnClientEvent:Connect(function(AnimID,NPCNum))
local Anim = Anims[AnimID]
local NPC = NPCs[NPCNum]
-- load Anim onto NPC and play it
end)
Just what I think, I’m not sure if I’m right or whatnot.