I like this, LoadAnimation is useless and we could just play the animation directly is going to save a few lines.
1 Like
This update seems useful and refreshing, it feels a lot cleaner to just directly use the Animator instead of having a object call a function on another object to do the thing.
About replication though, I usually just stick to making custom animation ‘replication’ or doing all of that client-side, feels like it would strain the server less (I know it’s barely anything but I like optimization, lol).
1 Like
The current system isn’t ideal, but if you want all animation play state, speed, and weights to replicate our built in replication does that more efficiently than it’s currently possible to do in Lua right now.
It does some custom coalescing of state updates in the replicator queue that isn’t possible internally, and we have plans to improve its efficiency further. When you do it yourself you also cut yourself off from future backwards compatible optimizations we might make to animation replication.
There’s only two reasons I know of to do animation replication right now:
- You absolutely need animations that can play locally on your character that do not play on the server. We don’t have a built-in way to do this… yet.
- You use AnimationTrack weights for aiming. The state update event coalescing isn’t optimized for this case yet, and this can currently generate a problematic amount of replicated weight updates with large player counts. We’ll improve this eventually. You can also implement aiming by modifying Motor6D.Transform locally with custom replication of aim direction (I’d recommend a RemoteEvent from the client and a NumberValue for pitch for efficient broadcast from server).
Outside of those problem cases you’re very likely worse off if you DIY, since you’re defeating low-level optimization work we do internally that is impossible to do in Lua.
We also provide this stuff hoping to make you more efficient as developers by saving you time reinventing wheels. Even though our wheels aren’t as fully featured as we’d like them to be today, if what we have fills your needs we hope we can save you a lot of work by using it!
Unless of course you’re just doing it for fun and your own learning, then have fun!
5 Likes
I do this for plenty of stuff actually, I don’t mind doing some extra work because it keeps me busy and entertained, I don’t really do anything too big, I simply just make state machines on the client (like a client script that loops through all players and checks their states, albeit in a optimized way of course, I’m not gonna use for loops lol), I felt like it would optimize the game since animations don’t need to tell the server if they’re playing or stopping and if the game lagged there would be no delay in animations playing/stopping, therefor I make my own client-side state machines and such, I also script my own humanoid and my own backpack simply because I’ve found some issues with the build-in stuff, I don’t mind doing that extra work though, it’s like an extra challenge.
Anyways, let’s not go too off-topic, this is a nice update nonetheless, makes loading and playing animations just way more clean and sorted, less objects to be inserted in models.
1 Like
I’ve had issues with my own projects and just games in general where the animations didn’t replicate it was annoying to deal with especially with fighting games where animation cues help a ton with the experience, so yeah happy with this deprecation.
1 Like
My question is…
Why? Just why??
Why is this necessary? It was fine before
Also does the Animator object ALWAYS get created automatically, or do we need to make an if statement just in case?
1 Like
Can’t we still use the method on client-side animation controllers?, where the animation will only be played on each individual client and not from the server.
1 Like
Yeah, Animation objects are just asset id holders. It’s absolutely redundant. This is on our radar, but no promises.
8 Likes
Technically yes, but would still recommend against it. Because again, if you call it too early it will create its own desyncronized animator and replication will be broken. If you know the Animator already exists, it’s technically safe to call them.
Even if this wasn’t a foot-gun waiting to happen, we’d still want to deprecate it. What’s the point of having three different classes expose the same API when only one of them actually implements it? In the future we won’t add any new generic animation APIs to Humanoid and LoadAnimation, only Animator.
6 Likes
An Animator will be created for you on the server if it is spawned by the the default character loader or created from a HumanoidDescription. So for player characters spawned by Roblox code, it should be safe to assume they will already have an Animator from the server.
For anything you’re assembling manually or for some NPCs this might not be guaranteed. You can either add an Animator to the model yourself, or create it from server Scripts. Personally I’d just do the former and throw a clear error if WaitForChild("Animator") ever returns nil in my animate script.
4 Likes
it was made so we can replicate animations client and server side.
1 Like
How would I migrate my animation code to prevent using deprecated functions?
Nevermind, I figured out with some help on a topic I made recently to figure out a problem I ran into.
1 Like
The original post literally says what you need to do lol.
1 Like
instead of the humanoid, you direct it to the animator INSIDE the humanoid
2 Likes
I’ve been trying this approach for my NPC creatures, but Studio does not seem to offer “Animator” as an option for Insert Object. Is that a bug/unfinished work, or intentional for some reason?
As an experiment I tried running the game, and just grabbing an Animator object out of it at runtime using studio Copy/Paste to get one for my source model, and I’m not seeing any problems so far. Is there any risk in grabbing an Animator object that way?
1 Like
I dont think you are, even what I’ve tried, I get the same identical issue.
The doors don’t update until the other client goes near the train
I just gave up with animations and went over to modifying the Motor6D’s Transform property directly instead of using animators.
6 Likes
At last! This is a nicer more direct way to play animations without having to use the LoadAnimation method, this will also make animation replication a lot easier. 
This new change made my game act very weird. Sometimes animations work. Sometimes they don’t.
did you update your scripts? if not then you should migrate.
Just updated my scripts, everything works fine now.
1 Like