Checking the accessory part size does not work. I have no problem with originally big accessories/body parts, but want to prevent huge avatars due to glitched layered clothing accessories. Currently there is no solution to this, as manually inserting asset IDs in a blacklist every single time there is a new huge outfit glitch isn’t a solution
Below, I will show you the difference between the visuals and the actual accessory part size. Also, I played your game with the glitched outfit to check if your implementation worked and it still glitched
This is one the smaller glitched outfits, I have seen them five times the size of our entire map
That’s concerning! I also misinterpreted the original comment so I apologize. Also I agree that a blacklist is more of a bandaid than a solution. Deleting it in post is also unideal because it’ll show for a brief moment.
This was mainly used to counter the enormous accessories being bypassed last month, so it would not work with layered.
Please do share the asset ID in messages because I’m very interested in replicating this and preventing it. I do hope for an official way to address these abnormally large accessories & characters though.
Is there a way we can opt out of this feature for the time being? We’re noticing a massive issue when applying a description that includes body parts - it seems to be changing the rig somehow? Layered Clothing gets deformed, an offset is applied (characters are physically moved by a few studs), and our R15 animations break.
When did you start noticing this? Did you notice this last week or only starting today?
We started rolling out some preliminary changes for the accessory adjustment feature earlier today, and I wonder if this might be the cause. This was turned off for an unrelated reason just now.
Can you provide a link to the place where you experience this and the steps to reproduce it? Also, if you can condense the repro into a smaller example and DM me the file, that would be helpful.
Thanks to @ItsMuneeeb for helping me solve it quickly
The problem is that when a HumanoidDescription is updated on the server, the client’s ChildAdded event triggers too early—before the new AccessoryDescription and BodyPartDescription details have fully reached client.
Coded Clothing Mall V3 🛍️ - Roblox is the game where the bug appears, I have not pushed an update to fix this yet as I am working on a complete revamp, also using the new API now.
For our game, it was because all the code was made to Destroy() humanoid descriptions upon creation. Thie was done because we could not trace a memory leak. Doing this naturally clearsd out all AccessoryDescription and BodyPartDescription instances, resulting in accessories being taken off and skin color being set to 0,0,0.
The heads up would’ve definitely been nice as it was confusing figuring out the root cause.
Ever since this update released I’ve been getting a rare issue where sometimes HumanoidDescription:GetAccessories(false) will return an empty table if called immediately after the character spawns.
Judging by the reason for the addition of Humanoid.ApplyDescriptionFinished, I’m guessing that I’m just trying to get the HumanoidDescription too early, before all AccessoryDescriptions exist.
However, ApplyDescriptionFinished still doesn’t solve my problem because it doesn’t automatically fire after CharacterAdded. How do I ensure that the HumanoidDescription has fully loaded right after the character spawns? Waiting for Player.CharacterAppearanceLoaded doesn’t work either.
Note: I’m not trying to wait for changes from Humanoid:ApplyDescription(), I just want to get the initial appearance of the character when they first spawn.
@TheGamer101 hello I wasn’t sure if this is the right place but decided to post it here since it was on topic.
We noticed that the Position/Rotation/Scale on AccessoryDescriptions has been unlocked on Studio.
We saw a weird behavior when rotating the value of AccessoryDescription.Rotation with ArcHandles that is different to rotating welds and parts. It appears to perform identically to rotating the welds with ArcHandles until a rotation is applied on a second axis. Both are fed similarly structured coordinates and we’ve accounted for Gimbal Lock by using Quaternions.
Here is a gif showing using the ArcHandles to rotate a weld
And another showing using ArcHandles to rotate a AccessoryDescription.
As you can see, the accessory is rotated differently with AccessoryDescription. The gif below showcases it best. In this gif, weld is used while the ArcHandles is being held down and AccessoryDescription is only applied when the handle is let go of. You are able to see a huge difference in how they behave.
I was hoping to know if this was expected and we might need to find a way around it, or if we should wait it out in hopes for a change.
@Kipukii thanks for bringing this to our attention. I’ll investigate what’s going on here. The AccessoryDescription Rotation value isn’t driving the Handle CFrame directly, but instead changing the CFrame of the handle’s attachment point, so I’ll have to look at how this interacts with the ArcHandles use case.
Thank you very much. What I did in both methods is convert the Vector3 using CFrame.Angles. I’ve tried other methods as well. If you require any of my code please let me know!
Our method didn’t work on the handles but worked on the welds. Only used the Handle as an Adornee.
Is there any way to get the AccessoryType of an accessory by its asset ID? If not, is there a way to detect accessory types from inserted accessories in a future proof way? So far I’ve found nothing and am currently converting AssetTypes to AccessoryTypes manually.
The mapping between AssetType and AccessoryType will always be 1:1. I would recommend using AvatarEditorService:GetAccessoryType(AvatarAssetType avatarAssetType) for doing the mapping between AssetType and AccessoryType so that this remains forwards compatible in the case of any new AccessoryTypes or AssetTypes.
