Description
The Haunt was a great event to highlight some of the following things, Posts API, Captures and Avatar Creations.
So, I want to address an issue with in-experience Avatar Editing.
AvatarEditorService:PromptSaveAvatar and AvatarEditorService:PromptCreateOutfit are forced to use AvatarEditorService:ConformToAvatarRules while there are secretly two ways to conform to Avatar Rules. I don’t know how to describe them so I will call it “maxNumber” and “LimitExceeded”
AvatarEditorService abides to maxNumber of each Accessory Asset Type, while set-wearing-assets checks for 10 Accessories for any category.
PromptSaveAvatar is a client-side function and can eventually have its behavior altered with Fast Flags, which could be acceptable. But ConformToAvatarRules, is a utility for the server and client, and client Fast Flags, don’t override on the server, so…
But I bet that ConformToAvatarRules goes through a structured check that could have the potential to be configurable. Because then one doesn’t necessarily have to hunt down all the Roblox Formulas, e.g. Delta-E CIE2000.
The issue effectively explained
I have more than 3 Accessories equipped on my Hat, on my Roblox Avatar itself.
After using game:GetService("AvatarEditorService"):PromptSaveAvatar(game.Players.LocalPlayer.Character.Humanoid.HumanoidDescription, Enum.HumanoidRigType.R15), it internally seems to conform to the Avatar Rules on its own, and then prompting the save.
It removed 4 Accessories… But why? I have these Accessories equipped on my Avatar, why does it want to remove them? 
Not even the Universal App’s Accessory Adjustment Editor is that cruel. The Accessory Adjustment Editor lets me edit and save all of these Accessories. Why is PromptSaveAvatar that cruel? And by the way, PromptCreateOutfit doesn’t even mention if it did remove something.
Because of this issue, ConformToAvatarRules can’t be used in a reliable way. If you use it on a Player that has more than 4 Hats equipped, one of the Hats will go away after calling that function method.
FFlagAvatarEditorServiceV2EndpointSupported doesn’t make a change in this either. Infact, I think it might be a Client-Side request in the first place, the only information it seems to want is the current avatar to compare the differences? Which it gets from /v2/avatar/avatar-fetch
Side-explanation of The Issue
while there are secretly two ways to conform to Avatar Rules
What is wrong? Is there anything wrong with what happened above? The Avatar Rules say that you can have:
- 1x Hair Accessory
- 1x Face Accessory
- 1x Neck Accessory
- 1x Shoulder Accessory
- 1x Front Accessory
- 1x Back Accessory
- 1x Waist Accessory
- 3x Hats
In total these numbers sum up to 10.
10 is an important number here, because the secret Avatar Rules, allow you to have up to 10 Accessories in any Category. This means you can have 10 Hats and it is fine. But the issue is that ConformToAvatarRules ignores that, and probably as well for Layered Clothing.
If you force set Accessories through the Avatar API you can wear more than 3 Hats on your Avatar, which is cool. But in-game functions like ConformToAvatarRules and PromptCreateOutfit ignores that.
If you go over the number 10, you’ll get a LimitExceeded Error. The limit itself isn’t explained.
Why is it like this?
I don’t know why ConformToAvatarRules and PromptSaveAvatar are designed currently like how they work.
I believe that Roblox may know that an Avatar can have more than 3 Hats, but doesn’t decide to promote it. But they allow “Advanced Users” to have more than 3 Hats at once.
“Advanced Users” as in those that use Third-Party Browser Extensions or the API directly, in order to wear more than 3 Hats.
I don’t know if at Roblox, they actually intended it to be designed like that, or if it is a bug on the Avatar API for set-wearing-assets. But DON’T fix that.
If they did intend it to be designed like that, then there’s still an issue. Because ConformToAvatarRules still removes Accessories that were allowed by the API.
Adding a client-side Fast Flag to preserve “Advanced Users”, won’t solve :ConformToAvatarRules.
The method itself offers good utility, like setting Default Clothing for Delta-E Color Difference and etc. but you can’t control these. But I bet, that the source code of ConformToAvatarRules goes through a structured list of checks, where the potential exists to have it all configurable.
You can’t control whether it should abide or not abide to maxNumber from avatar-rules. It almost starts to suggest that the only way to fix that without causing unintended changes, is by adding a second argument, that allows this behavior to be configurable.
Functions like PromptSaveAvatar are Client-Sided, however I don’t think there’s a Fast Flag that an “Advanced User” can enable, that would allow to create a prompt which lets you save up-to 10 Accessories of any Category, without abiding to maxNumber from avatar-rules
So… 
Re-production Steps
- Create an R15 Avatar with more than 3 Hats. e.g. with aid from
/v2/avatar/set-wearing-assets - Run
game:GetService("AvatarEditorService"):PromptSaveAvatar(game.Players.LocalPlayer.Character.Humanoid.HumanoidDescription, Enum.HumanoidRigType.R15)on Studio while the game is running. - Observe how it wants to remove 1 of the Accessories
Expected Result
That updating an outfit, creating an outfit and saving an avatar, allows you to keep the accessories that you’re already wearing. (And other accessories)
Actual Result
These built-in methods are abiding strictly to maxNumber for each Accessory Category. I’d assume that it does the same for Layered Clothing as well.
Summary
While searching I managed to find other posts: