Change To Humanoid Animate LocalScript

Currently you can replace the Humanoid's Animate LocalScript with a Script of the same name. However, if you do this, changing animations with a call to Humanoid:ApplyHumanoidDescription() will fail to change the animations, as this only works with Animate LocalScripts. A change is going live on Thursday (02/20) that will fix this issue. Primarily this would’ve only been an issue for developers who were trying to animate NPC Humanoids on the server.

We do not anticipate any issues arising from this change. However, please provide feedback if you think this change will impact your game in a way you are not able to fix. Also, after the change goes live, please provide feedback if you experience any issues in your games.

Thanks,

The Roblox Team

89 Likes

Will this override custom animation scripts?

9 Likes

How will this supposed change work?

And on the topic of using a server script to play animations, will this ever be required? I currently do not see a reason that the client needs to have access to replicate animations to other clients apart from legacy support for old gear tools, and games (which likely don’t work anymore anyways due to the forced FE update some time ago).

It makes more sense overall to me that the client should not be able to just load in animations and start playing them and have them replicate to other players.

1 Like

If you have the client replicate animations to the server, the client is going to see those animations much faster, so the animation is going to look cleaner for the person in the first place. That’s why there is functionality for that and it’s why the default for all players is that anims load on the client.

2 Likes

Does not make sense. If the client is replicating it to the server who then replicates it to everyone else it would effectively be slower than the server its self just replicating the animation to everyone else. You could mitigate the issue of the client not seeing their own animation by just playing it on their side, and then telling everyone else to play it on their side.

An extra amount of time is added by piggy backing off the server to tell every other player to play the animation. Of course you still run into this issue when you would like to have clients request to the server to play an animation.

2 Likes

Is this gonna make it so if you have custom animations, after walking for a while you won’t get your idle animation? I don’t know how to explain this. I set all animations to the same in some of my games, and after walking for a while, it plays the idle animation whilst walking. It’d be nice if this does fix that.

2 Likes

This is why it renders on the client first. Typically, while it is generally the more secure approach to handle everything on the server, if you had something like a jump animation, there is zero delay between when you click space and when you jump on the client, because the animation is handled on the client and not the server. As you are additionally replicating over your characters physics (through NetworkOwnership), the animations will sync up alot better. If you jump on the client, the animation will end once you’ve reached the ground on your screen. If a jump request were handled on the server, you could still have animations overextending their time on the character, and it wouldn’t be as fast for the player). Not to mention, a server sided jump would need to be triggered by the client to begin it, and this would add another signal. The client-sided jump likely would not have this issue, as you don’t need to communicate with the server to jump, you can just do it to your character on the client and it’ll replicate over.

So in this instance, a server instigated jump would be slower for the jumper (potentially the rest of the clients), than the client instigating that jump first, and then telling the server to replicate it to other clients.

It seem’s like this could be an issue with how you’ve laid out your animation ID’s. Feel free to drop a thread in #help-and-feedback:scripting-support and we’ll see what we can do to help!

3 Likes

Just because you play animations on a client to get that instant visual, doesn’t mean they should replicate from that client to the sever then to all other clients. I don’t pretend to understand how Roblox does its whole animation thing, but just from what I think would be logical, I would think you should set custom animations from the server (not messing with replacing values in the local Animate script) and the server sends to all clients the ‘modified’ animation. So when a client plays the animation locally, and gets instant visuals, the server can tell all the other clients to play that animation as well, by name or id or something. So the animation itself isn’t replicating to everyone, only the signal to play this particular animation.

2 Likes

A change on the server is replicated to everyone’s client by default. So if the original client player was jumping, and replicated their animation to the server, the server would recognise that as a change, and thus all other clients would recognise that as a change. This is how it has been for a while.

This would very much depend on whether the animation was triggered by a keypress. In the case of a player’s character, you probably do not want their idle animation to continue playing while you are trying to run around or jump. Running a process like this on the client produces a far more aesthetically pleasing animation for the person triggering it, and it is also triggered without too much interference from latency.

Strictly speaking, the server does not typically send animations on their own anywhere. Replication refers to more than just signal changes, and in the case of the player’s character, it can also refer to the specific physics of a part. I suggest reading up on NetworkOwnership as this is the method through which player’s characters are able to render the animations they exhibit to the server, as the player is a physics-based object, and animations are physics-based aesthetics (thats why if you animate something thats anchored, it won’t move.)

There’s a really useful read by @unix_system about replication and network ownership as well which I recommend too, as it covers these concepts in greater detail

1 Like

no, it should have no effect. They should still work as before.

2 Likes

I don’t see why some people are having an issue with this. I mean it’s not like it could be exploited or anything, as it’ll only let animations owned by the game creator play, and if that’s the case, I’m not sure how the creator’s animations would cause trouble in their own game.

1 Like