I had to re-write everything again because my Chrome crashed and Bug Reports didn’t create a draft 
I hope that I managed to re-write it how it was before.
The timing seems good.
Description
I was exploring games from The Games Event, and one of them was Survive the Killer! by @Dued1’s Slyce Entertainment. (I don’t own the game)
But I encountered an issue. First I thought that it would have been the fault of the game. But then I started to think some steps back.
Something happened which broke a very small portion of the game. My character’s Avatar Description failed to load, which made it load the fallback character instead and I couldn’t move around in their game anymore (because of one of their scripts failing).
It looks like that the their game (Survive the Killer!), was using :WaitForChild() to wait for a HumanoidDescription. The problem is that the Fallback Avatar Character, doesn’t have one.
This is the fallback character created by the Roblox Engine:
Some also call it “Noob” because of its style.
As you can see, it doesn’t have a HumanoidDescription. Infact, it doesn’t have a bunch of things. This preview here is the Server’s character. Created with game.Players.Player:LoadCharacter()
A Block Rig that can be created through the Rig Builder, does have a HumanoidDescription though.
I also thought that it is in that style for a specific reason, but I think I am mistaken and HumanoidDescription never had a method to reset the description to something “default”.
If I use game.Workspace.Player.Humanoid:GetAppliedDescription() on the fallback character, it creates a HumanoidDescription, the problem is it’s in the wrong colors.
It looks like that we all expect that a R15 default character, comes with a Humanoid and HumanoidDescription. That is right, however, the fallback character is making an exception here. And I believe that this is inconsistent. Especially since the fallback character, isn’t really something known or documented
but…
EVEN :GetAppliedDescription() expects a HumanoidDescription. It is CREATING a HumanoidDescription in the case where it DOESN’T EXIST. (Not with the right properties though, how would it even know)
At that point, the fallback character should receive a HumanoidDescription as well, instead of being hardcoded and have the colors manually set!
I believe that the fallback character might of have existed in the Roblox Engine before HumanoidDescription’s were ever a thing, hence why it is still like that, idk.
Another thing is that if someone wanted to create this “Fallback Character” style, you’d have to create your own HumanoidDescription for it, because the Roblox Engine doesn’t have one. Secondly it’s incredibely difficult to summon this fallback character. Because either the Avatar API needs to be down or you need to manage to find a way to create one, like creating a character for a Player with an invalid UserID, like 0
Re-production Steps
- Open Roblox Studio
- In the console enter
game.Players:CreateLocalPlayer() - Then
game.Players.Player:LoadCharacter()to emulate a fallback avatar, I guess? I hope it’s accurate. - Then
game.Players:ResetLocalPlayer()do delete the Player - And then you’re ready to explore the Fallback Character
- Observe how it doesn’t have a HumanoidDescription
- Observe how it will get a HumanoidDescription if you run
game.Workspace.Player.Humanoid:GetAppliedDescription() - Observe how the HumanoidDescription is wrong though, all it did was to just create a new HumanoidDescription Instance
You should be ending up with this guy btw.
Expected Result
The game that I mentioned, expects that all R15 loaded characters have a HumanoidDescription, but the special case where an avatar fails to load, wasn’t expected.
The Fallback Character should have a HumanoidDescription, instead of manually changing the colors.
Even the Roblox Engine’s :GetAppliedDescription() is expecting one, because it just seems to create one with its own free-will. And that should mean something.
Actual Result
The fallback character is the only exception in the Roblox Engine, that currently doesn’t have a HumanoidDescription, even though it could.
Things that rely and expect all R15 to have a HumanoidDescription by default, would fail here. Because the fallback character, is making an exception.
If someone decides to fix this. One of the things I was thinking about was:
- Would this break anyone’s method to figure out if an Avatar failed to load from the Avatar API?
- Is there even a standardized method to figure out if an avatar failed to load.
- If the fallback avatar would have a HumanoidDescription, you could eventually compare both descriptions.