Yeah, same here.
I store premade HumanoidDescriptions as well and the issue comes from using humanoid:ApplyDescriptionReset for me saying duplicated accessories are found and can’t apply the description…
1 Like
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?
It does support R6! It is possible to use BodyPartDescription.Instance with an R6 body part.
Would you be able to change this code to:
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.
1 Like
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.
1 Like
What about ai help us build a map because im still stuck on tower defense map with tripod
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.
6 Likes
Ohh yeah that fixes it, my bad I missed that at the end of the post. Thank you!!
No worries. Sorry for the inconvenience caused by this change!
1 Like
Will this be better or worse than the old HumanoidDescription system performance wise?
Was this always a thing?
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.
It’s still strange
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.
Documentation for reference
3 Likes
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.
Much thanks!
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.
can we get a property for .ApplyDescriptionFinished? in the case that the event has already fired i wouldn’t know if its loaded already
2 Likes
Yes, Scale Rotation and Offset will be returned in this table for rigid accessories.
1 Like
Thank you!
Will these three AccessoryDescription properties only work on R15 or will there be R6 support aswell?
1 Like