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.
bro when will this thing be live? it has been months now 
2 Likes
Thanks for your feedback and years of patience!
The Looped Property of AnimationTrack should now replicate!
Feel free to give it a try, and let us know if you encounter any unexpected behavior.
12 Likes
I’m still experiencing this problem. I’m Playing an AnimationTrack on the client, which is a short animation that is looped. When played, the server and other clients will see the animation play once with the defined weight. However, while the client playing the animation will see the animation loop, the server and other clients will not.
1 Like
Still does not work.
I setup a simple studio place where I created an animation that in the editor has looped set to true.
I then played in a server script the animation on my character, setting the animation track’s looped to false (I tried setting it both before calling :Play() and after).
The animation does not loop on server but on client is looping despite having set loop to false.
There are still replication issues when playing animation tracks on the server, though also found a few workarounds to hopefully help with debugging this bug internally. This was tested on an empty baseplate.
The animation was a non-looped animation, and I attempted to set the Looped property of the animation track through a server-side script. The animation loops properly on the server, but without workarounds will not replicate the loop to the client.
Setting the Looped property before playing the animation failed to replicate the loop.
local animaitonTrack = Animator:LoadAnimation(animation)
animaitonTrack.Looped = true
animaitonTrack:Play()
Workaround 1
Playing the animation before setting the looped property seemed to fix it for me, through @Askavix has also noted otherwise so might not be a reliable fix.
local animaitonTrack = Animator:LoadAnimation(animation)
animaitonTrack:Play()
animaitonTrack.Looped = true
Workaround 2
Another stranger fix I’ve found is creating the exact same animation track twice. For some reason, the second animation track will properly replicate, even when setting the property before playing the animation (which didn’t work previously).
Definitely hacky, but might be a good lead for investigating this bug further?
local animaitonTrack = Animator:LoadAnimation(animation)
animaitonTrack.Looped = true
animaitonTrack:Play()
animaitonTrack = Animator:LoadAnimation(animation)
animaitonTrack.Looped = true
animaitonTrack:Play()
1 Like
6 years later, still an issue, is the team still aware of this?
That bug still exist, and not only looped gets broken, the client cannot replicate stoping the animation. After the client stopped the animation it still being played for other people
I’m still experiencing this issue. I’m playing an AnimationTrack on the server, set “looped” to false for that animation, and it still plays as looped on the client. I have a very large bunch of mesh animations that I would have to go through and somehow just reupload without the loop and it would make 100% more sense if the animationtrack loop property just replicated properly instead.
1 Like
Still a problem today, sadly none of the workarounds posted here worked for me. Please do something about this!!! Its been years!
Still happens as of today, roblox noticed this back in october 2018. So, it’s been 6 years since.
1 Like