I think Animations should be just handled clientside, why would the server (which no one plays on the server) handle animations? Who will see the server animations apart from only thing doing is sending the information to all clients which you can also do using OnClientEvent’s and FireAllClients() call in case you want it to replicate/sync with other clients, but i think just having the server fire a remote to all clients to update the animations for these is the best solution
But go ahead, flag this post because this forum is literally 1984
It’s 2023 and Roblox still hasn’t fixed this bug. The only solution to this is by using RemoteEvents, firing all clients and changing the loop but, the problem is that the server gets none of that code and it will remain dead. You sadly cannot send the loaded animation back to the server but better than nothing I suppose
That’s great because it’s also an issue via client side as well. Animations set to not loop via client do not replicate the behavior to the server. But a way around this issue would be to wait for the animation to complete then stop it. I guess Ill try that.
The solution would just be this.
anim.Looped=false
spawn(function()
local anim=anim
anim.Stopped:wait()
anim:Stop()
end)
I’d only use spawn function if you want to carry on with the code you have around it without making it wait for the animation to complete.
This looped property may not replicate but if you unloop the animation and wait for it to stop then stop the animation this does replicate across server client boundaries.
In this way, it’s necessary to stop it a little early (at least 0.1s or so) and fade it out smoothly. Otherwise, the next loop of the animation will play and get interrupted once the client receives the :Stop signal.
Roblox, I beg. This issue wasted an hour of development time, as I could not figure out why for the life of me some of my user-submitted emotes looped properly and some didn’t, and I didn’t get proper events. Please fix this, it’s been known for nearly 5 years now.
The solution is simply this. If you have an animations engine simply patch them with a spawn function variant. Or even something like this local function AnimBoundary(anim)
–this method replicates across server client boundaries
local anim=anim
local animhandle
animhandle=spawn(function()
anim.Looped=false
anim.Stopped:wait()
anim:Stop()
animhandle:Disconnect()
end)
end
Yeah I would keep bumping it. I was running into problems where I couldn’t figure out why my animations were not stopping even though I set .Looped to false. Turns out these properties don’t replicate at all and I wasted a ton of time trying to figure out why it wasn’t working until I stumbled upon this post.
The fact that this was recognized as an issue and still has not been fixed for 5+ years is absolutely insane.
playing animations on the server makes it so animations are replicated to all clients roughly at the same time, meanwhile, playing animations on the client takes some time till it finally replicates to others. playing animations on the server is a MUST for competitive fighting games like deepwoken that has a reaction-based mechanic (parrying, perfect blocking, perfect dodging).
I suppose it depends on how the animation is played from the server. If you’re handling NPC animations from the server, then yes I suppose it would be faster than having clients handle it. If you’re trying to say that for combat animations, player vs player, that the server should handle those animations, I believe this is incorrect. If you have the client fire a remote event to the server to tell it to play an animation, that’s really just adding an extra step to replicate. If you simply play the animation on the client, it does the replicating for you, no need to fire a remote event. Now, maybe playing an animation on the client and having it automatically replicate is slower than firing a remote event and having the server do it, I’m not sure, I haven’t tested it. I’m gonna assume that isn’t the case, because it’s literally doing the same thing but without another thing to send to the server.
My personal theory on why this happens, is because AnimationTracks themselves have limited replication. The actual TimePosition can go out of sync, because the engine is intentionally programmed to ignore it and simulate it locally on the client to reduce stuttering and improve smoothness, likely with the knock-on effect that some important properties (.Looped) do not replicate, because the client just ignores it.
However, this behavior is incredibly unintuitive. For me, the best solution I have come across is to never override .Looped to false if you aren’t sure of it’s value in the actual animation asset, and to dispatch a coroutine with task.spawn that waits for the animation to end by task.wait’ing it’s Length, and then manually calling :Stop. If you set .Looped to false when it’s true in the Animation Editor, the script will never be able to get the :Stop to go through, as it is rejected when the server finds out the animation isn’t running on it’s side, even if it’s still running on the client.
