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.
1 Like
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.
Here’s what I’m doing now:
animationTrack:Play()
task.wait(animationTrack.Length - 0.5)
animationTrack:Stop(0.5)
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.
This is still an issue. Should at least be documented.
3 Likes
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.
2 Likes
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
1 Like
I’ve already worked around it. The feature request is about requesting Roblox to fix the underlying issue, not requesting band-aid “solutions”.
1 Like
Roblox when will this ever be fixed, I am still encountering this on my game.
“Yes, this is a known problem and we currently have a ticket tracking it,” they said.
“Hopefully we will get to it soon,” they said.
5 years ago
Will this ever be fixed?
I doubt it. I’m showing an animation that isnt supposed to be looped to friends and it’s an inconvenience to have to change it in animation editor.
Bumping this post; it’s kind of lame how they still haven’t fixed this.
1 Like
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.
Hey,
When is this going to be fixed? I’m kinda shocked it hasn’t been fixed yet. It’s been 5 years…
1 Like
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.
1 Like
it has been 6 years, roblox is truly embarassing oh my god
I think at this point we just accept that Looped does not replicate
Hey mate, any luck yet? Still having the issues.
