It doesn’t do it automatically no.
You simply set HumanoidDescription.HatAccessory or the parameter for it. to the ID you want. And then call Humanoid:ApplyDescription(HumanoidDescription) where HumanoidDescription is the reference to the one you modified. Each time you want it to update. It doesn’t work like the scale objects.
1 Like
That just added color to the NPC.
As you can, it has Hat and Face accessories, you can see in the output I put the ApplyDescription. No accessories were added tho
2 Likes
A lot of fixes have gone in recently for the HumanoidDescription system. You can give what you’re doing another try, and see if it works any better now. Hopefully now you can get the results you want without calling humanoid:ApplyDescription() twice.
1 Like
Thank you very much! It used to take me quite a bit of code just for changing the look of the player. 
I like this feature but it’s very difficult to use with custom assets, since it requires an asset ID and therefore an asset being uploaded to the website.
3 Likes
I love this…I figured out how to do what I wanted with it and I’m somewhat satisfied. For me, the inclusion of Rthro texture Ids text fields would be dope. I did it in script but that would save some time for everyone with similar needs/interests. LeftUpperArm, LeftUpperLeg, RightUpperArm, RightUpperLeg, UpperTorso.
I concur, I would also like to see this feature usable from the client. I recently ran into a use case for it.
I want to display various player’s avatars in a list of viewport frames. When doing this, I want a fresh copy of their avatar, so I had a default NPC parented to a given viewport that I would call Humanoid:ApplyDescription() on to load the player’s avatar. However, since this feature is currently not able to be used on the client, I have to locally clone the target player’s avatar, which isn’t desirable as it isn’t a fresh copy of their avatar.
EDIT : Made this a feature request. Allow HumanoidDescriptions to be used on the client
3 Likes
Most likely due to HumanoidDescriptions just load assets, being able to run it in client would bring quite abit of voulnerabilities. Few examples would be to use emotes you havent bought or loading exploitive scripts.
What I recommend you do is to fetch those avatars via RemoteEvent. Since players only see whats in their own PlayerGui, you can safely put a folder there and as the remote event is called, create the avatars server side and parent them to the callers folder. Be sure to add caching to make it more efficient!
I don’t see these as being issues - if an exploiter was determined enough, he/she could load any animation that was desired through the humanoid animation API. Also, “loading exploitive scripts” - exploiters can already do this to begin with. It’s how they exploit, they can run any arbitrary lua code they want through the use of their exploit.
This is bad practice (and hacky). Generally speaking, the server should have no access at all to a player’s GUI. The only reason we do is because it is a legacy Roblox behavior, and removing it would break a lot of old games.
Correct people can already do both. But its good to make sure it doesnt become easier.
As for the folder, it doesnt necessarily need to be in the playerGui, it can be anywhere as long as its replicated to the player since you can’t pass an instance through remote event. You are only passing the reference to it, meaning if the said instance that was passed isn’t replicated to the player it’ll return nil
This isn’t a valid reason, making the API usable on the client wouldn’t make anything easier. If the player is already running an exploit client, anything is fair game.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.