/disguise <entity> as player does not properly set the skin based on the player name, instead using entity UUID.

[James103]

As of Mob Disguises 1.0.4 and DisguiseLib 1.0.8, when you run /disguise [entity] as player with a playername argument, the skin is not properly set based on the player name that is passed in. Instead, the skin is set based on the UUID of the underlying entity. Therefore, you still are limited to one unique player disguise per entity, instead of unlimited disguises of the same skin, each pointing to a different entity.

In the following commands, it may be a good idea to add NoAI:1b to each of the NBT tags, but that's not required.
CustomName:'""' is unnecessary, but does mostly hide the disguised player's name.

From my testing (click here to expand steps)

Testing player disguise with no player name specified:

• Run summon pig ~ ~ ~ {CustomName:'""'}.
• Run disguise @e[type=pig,limit=1,sort=nearest] as player
• Notice that as no player name is specified, a default player skin is used.
  • I can tell that it's using a default player skin because it is default Steve in some tests and default Alex in others.

Testing player disguise with a player name:

• Run disguise @e[type=pig,limit=1,sort=nearest] clear to avoid Applying /disguise <entity> as player repeatedly can result in client side errors and invisible mobs #17.
• Run disguise @e[type=pig,limit=1,sort=nearest] as player 111
• Notice that a default player skin is used for the disguise instead of a custom skin.

Checking the UUID of the disguise:

• The player 111 has the UUID: [I;891580536,-714388382,-1804876794,-2055821724]
• Run data get entity @e[type=pig,limit=1,sort=nearest] UUID
• Run data get entity @e[type=pig,limit=1,sort=nearest] DisguiseLib.DisguiseEntity.UUID
• Notice that both UUID results are the same, and different from the target player.

Trying again with the actual UUID of the player as the UUID of the entity:

• Kill the pig: kill @e[type=pig]
• Summon a new pig: summon pig ~ ~ ~ {CustomName:'""',UUID:[I;891580536,-714388382,-1804876794,-2055821724]}.
• Run the disguise: disguise @e[type=pig,limit=1,sort=nearest] as player
• Notice that it now uses the skin of player 111 this time.
• Clear the player disguise: disguise @e[type=pig,limit=1,sort=nearest] clear
• Change to a different player disguise: disguise @e[type=pig,limit=1,sort=nearest] as player 101
• The skin is still that of player 111 even though an attempt to change the disguise to player 101 was made.

[samolego]

Seems like I messed up something when updating it 😅 . Or it's because the following method has changed ...

MobDisguises/common/src/main/java/org/samo_lego/mobdisguises/command/DisguiseCommand.java

Line 82 in eb31d19

SkullBlockEntity.loadProperties(profile, gameProfile -> {

I assume you have valid internet connection?

[James103]

I do have a valid internet connection to all of the servers required for this to work, as if I install Carpet mod and run /player 111 spawn or use the vanilla command /give @p player_head{SkullOwner:"111"}, it loads the skin of player 111.

It's just when I disguise an entity as a player and give it the correct username does it load a default or incorrect skin.

[maxheyn]

I'm also experiencing this same issue. I try to disguise a villager as a player but it is only ever Steve or Alex, regardless of the name I enter afterwards.

Edit: I'm using DisguiseLib 1.1, MobDisguises 1.0.5, and not sure if this one matters, but Taterzens 1.6.1 on a Fabric 1.17.1 server

[samolego]

Thinking more about this, I'll probably make skins depend on fabrictailor, as it has all needed code for skin fetching.

There've been numerous issues when using builtin skin methods, which was why Taterzens & FabricTailor are using different approaches.

[James103]

When using DisguiseLib 1.2.1, MobDisguises 1.0.8, Fabric Tailor 1.8.0, and Minecraft 1.18.1 (with MobDisguised self-built from source), the results are largely the same as originally posted, mainly that the skin retrieved is still based entirely on the UUID of the underlying entity, with the intended UUID (or player name) of the disguise having no effect on the resulting skin.

One notable change is that when the skin is a valid non-default skin, the skin data is stored in the entity's DisguiseLib.DisguiseEntity.fabrictailor:skin_data, and that attempting to modify that tag causes it to be overwritten immediately with the previous value.