Doesn’t seem to be enough.
I wonder if this bug has to do with Network ownership of the Head (I am changing the asset for every body part except for the head when using ApplyDescription
I’m still getting the “head falling off” bug for humanoid descriptions that are applied server-side when a player spawns.
One thing I’ve noticed is that this bug also replicates inconsistently—testing with another person, his head fell off on my client, but was normal on his. I wasn’t able to tell whether the head fell of on the server, but I’d imagine it didn’t since his character was still alive.
What this means is that the head falling off issue is very likely one of replication.
do you have a place file which can be used to repro the issue?
Can this be achieved with NPC’s? Tried setting the HatAccessory to say 204162039 and nothing happened
Did you call Humanoid:ApplyDescription(HumanoidDescription)?
Nah I just got a hats id from the site and pasted it into Humanoid Description. Tried cutting pasting the model back in but did nothing.
You gotta call ApplyDescription with a reference to the HumanoidDescription as the parameter anytime you want to apply a change.
So you cant just manually do it?
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.