It actually does somewhat work. Both of the new instances get created, but Im not sure what the BodyPartDescription instances point to (the Mesh, or the actual limb?). Also, AccessoryDescriptions for layered clothing also get created for R6, even though layered clothing does not appear on R6.
EDIT: I guess the BodyPartDescriptions dont point to either? Since the Instance property is always nil (which kind of defeats the purpose?) A lot of accessories have the same name, so I thought this would fix the issue of being able to easily differentiate them, but apparently not?
humanoid.ApplyDescriptionFinished:Connect(function(description)
handleDescription(description)
end
This should fix the issue.
The issue here is now that some information is stored in sub instances, they may not be guaranteed to be available at the time ChildAdded is fired with the HumanoidDescription.
We are evaluating the best way to fix this issue and hope to have a resolution soon. We are evaluating whether it is safer to roll forward this change and enable it for studio and then provide a script to remove the duplicate AccessoryDescriptions and BodyPartDescriptions or to roll back the change. The problem with the roll-back is that the duplicate accessory descriptions don’t play well with our rollback logic. We hope to have this fixed one way or the other by the end of the day though.
We have rolled out this change to studio. If you are experiencing the duplicate asset/body part bug, close and re-open studio to make sure you have this feature enabled and then run the following script.
local LOCATIONS_TO_PROCESS = {
game:GetService("Workspace"),
game:GetService("ReplicatedStorage"),
game:GetService("ServerStorage"),
game:GetService("ServerScriptService"),
game:GetService("StarterGui"),
game:GetService("ReplicatedFirst"),
game:GetService("StarterPack"),
game:GetService("StarterPlayer"),
game:GetService("Lighting"),
}
local totalDuplicatesRemoved = 0
local function deduplicateSubDescriptions(humanoidDescription, className, getKeyFunction)
local seenKeys = {}
local childrenToRemove = {}
for _, child in humanoidDescription:GetChildren() do
if child:IsA(className) then
local key = getKeyFunction(child)
if seenKeys[key] then
table.insert(childrenToRemove, child)
else
seenKeys[key] = true
end
end
end
for _, child in childrenToRemove do
child:Destroy()
totalDuplicatesRemoved = totalDuplicatesRemoved + 1
end
end
local function processChildrenRecursive(instance)
if instance:IsA("HumanoidDescription") then
deduplicateSubDescriptions(instance, "AccessoryDescription", function(accessoryDescription)
return accessoryDescription.AssetId
end)
deduplicateSubDescriptions(instance, "BodyPartDescription", function(bodyPartDescription)
return bodyPartDescription.BodyPart
end)
return
end
for _, child in instance:GetChildren() do
processChildrenRecursive(child)
end
end
for _, location in LOCATIONS_TO_PROCESS do
processChildrenRecursive(location)
end
print("Total duplicate AccessoryDescriptions and BodyPartDescriptions removed:", totalDuplicatesRemoved)
This should remove any duplicate AccessoryDescriptions and BodyPartDescriptions stored in your place and fix the issue.
I just tested it, it was always a thing… I deleted the HumanoidDescription after applying it and then did CTRL + Z, not sure how it was undoing things, but the limbs, those are gone. Same on the new one so it’s not a new issue.
When I first saw these new objects added to the API, I thought the AccessoryDescription.Instance property would be used to finally have a way to get the associated Accessory object on a character created by Humanoid:ApplyDescription(). Turns out it’s completely unrelated, being meant for custom accessories that don’t have asset IDs… will there ever be a way to do this in the future?
Right now the best way I can think of accomplishing something like this is to load the accessory ID with InsertService and then compare its properties with the accessories currently on a humanoid character to find the right one. My use case is I want to be able to highlight the accessory you’re currently editing on your character, but I need the location of the accessory’s handle to do so.
This API upgrade is adding a way to do this, just not the way you expected! We are adding a AccessoryDescription:GetAppliedDescription() function which will you allow to do this.
Could you please give us a way to detect the size of accessories, more specifically layered clothing? This would give us a temporary solution to the large avatar layered clothing bug
Model:GetBoundingBox()/Model:GetExtentsSize() are no use
This is amazing QoL, especially with AccessoryDescription! We happened to be working on giving our players the ability to offset their accessories and this addition does that for us.
Will Scale, Rotation, and Offset be in the table returned by HumanoidDescription:GetAccessories() when the AccessoryDescription API is activated?
Asking as we are preparing code for when the AccessoryDescription API is activated and serializing the description is an important factor.
For our implementation, we handle deleting the accessories in post. At the moment we convert them to a MeshPart and then check the part size. From there if it is offending, we destroy the accessory. Results are cached so that it isn’t too expensive to handle.
Once this API is out, I imagine you can use AccessoryDescription:GetAppliedInstance() to cycle through the accessories in the HumanoidDescription and knowing the accessory ID through AccessoryDescription.AssetId will give you a good way to identify illegal accessories and make a blacklist. From there, you could delete blacklisted accessories from the HumanoidDescription before applying them.
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
