MC-50306Player skulls with SkullOwner do not use UUIDs; can break after name-changes
Player skulls with the SkullOwner tag do not store their UUID. As a result, if a user changes their name, all existing copies of their skull will be broken. It's hard to say skulls aren't intended to work in the long term (as items and building blocks, there are plenty of reasons to keep them around for a long period of time). There are also no particular benefits to using names of nonexistent players as SkullOwners, although the system should probably accept both names and UUIDs when a custom skull is first spawned.
Steps to Reproduce:
- Spawn a custom player skull, using a command such as
give @p skull 1 3 {SkullOwner:"WolfieMario"} - Observe that, when placed, it displays the skin of the named player.
- Save and quit
- Using an NBT editor, examine the skull as it is saved in your inventory. The SkullOwner remains a String tag of the player's display name, meaning it will be broken if this player changes their name, and may even become a different player's skull if somebody else takes the name.
This will cause issues when name-changing is available to the public. Until then, the bug won't have any in-game effects, but 1.8 will already be released before name-changing is possible, and by then it would be too late to fix this (barring a 1.8.1, of course).
Created Issue:
Player skulls with SkullOwner do not use UUIDs; can break after name-changes
Player skulls with the SkullOwner tag do not store their UUID. As a result, if a user changes their name, all existing copies of their skull will be broken. It's hard to say skulls aren't intended to work in the long term (as items and building blocks, there is plenty of reason to keep them around for a long period of time). There are also no particular benefits to using names of nonexistent players as SkullOwners, although the system should probably accept both names and UUIDs when a custom skull is first spawned.
Steps to Reproduce:
- Spawn a custom player skull, using a command such as
give @p skull 1 0 {SkullOwner:"WolfieMario"}- Observe that, when placed, it displays the skin of the named player.
- Save and quit
- Using an NBT editor, examine the skull as it is saved in your inventory. The SkullOwner remains a String tag of the player's display name, meaning it will be broken if this player changes their name, and may even become a different player's skull if somebody else takes the name.
This will cause issues when name-changing is available to the public. Until then, the bug won't have any in-game effects, but 1.8 will already be released before name-changing is possible, and by then it would be too late to fix this (barring a 1.8.1, of course).
Player skulls with the SkullOwner tag do not store their UUID. As a result, if a user changes their name, all existing copies of their skull will be broken. It's hard to say skulls aren't intended to work in the long term (as items and building blocks, there is plenty of reason to keep them around for a long period of time). There are also no particular benefits to using names of nonexistent players as SkullOwners, although the system should probably accept both names and UUIDs when a custom skull is first spawned.
Steps to Reproduce:
- Spawn a custom player skull, using a command such as
give @p skull 10{SkullOwner:"WolfieMario"}- Observe that, when placed, it displays the skin of the named player.
- Save and quit
- Using an NBT editor, examine the skull as it is saved in your inventory. The SkullOwner remains a String tag of the player's display name, meaning it will be broken if this player changes their name, and may even become a different player's skull if somebody else takes the name.
This will cause issues when name-changing is available to the public. Until then, the bug won't have any in-game effects, but 1.8 will already be released before name-changing is possible, and by then it would be too late to fix this (barring a 1.8.1, of course).
Player skulls with the SkullOwner tag do not store their UUID. As a result, if a user changes their name, all existing copies of their skull will be broken. It's hard to say skulls aren't intended to work in the long term (as items and building blocks, there is plenty of reason to keep them around for a long period of time). There are also no particular benefits to using names of nonexistent players as SkullOwners, although the system should probably accept both names and UUIDs when a custom skull is first spawned.
Steps to Reproduce:
- Spawn a custom player skull, using a command such as
give @p skull 1 3 {SkullOwner:"WolfieMario"}- Observe that, when placed, it displays the skin of the named player.
- Save and quit
- Using an NBT editor, examine the skull as it is saved in your inventory. The SkullOwner remains a String tag of the player's display name, meaning it will be broken if this player changes their name, and may even become a different player's skull if somebody else takes the name.
This will cause issues when name-changing is available to the public. Until then, the bug won't have any in-game effects, but 1.8 will already be released before name-changing is possible, and by then it would be too late to fix this (barring a 1.8.1, of course).
Player skulls with the SkullOwner tag do not store their UUID. As a result, if a user changes their name, all existing copies of their skull will be broken. It's hard to say skulls aren't intended to work in the long term (as items and building blocks, there
isplenty of reason to keep them around for a long period of time). There are also no particular benefits to using names of nonexistent players as SkullOwners, although the system should probably accept both names and UUIDs when a custom skull is first spawned.Steps to Reproduce:
- Spawn a custom player skull, using a command such as
give @p skull 1 3 {SkullOwner:"WolfieMario"}- Observe that, when placed, it displays the skin of the named player.
- Save and quit
- Using an NBT editor, examine the skull as it is saved in your inventory. The SkullOwner remains a String tag of the player's display name, meaning it will be broken if this player changes their name, and may even become a different player's skull if somebody else takes the name.
This will cause issues when name-changing is available to the public. Until then, the bug won't have any in-game effects, but 1.8 will already be released before name-changing is possible, and by then it would be too late to fix this (barring a 1.8.1, of course).
Player skulls with the SkullOwner tag do not store their UUID. As a result, if a user changes their name, all existing copies of their skull will be broken. It's hard to say skulls aren't intended to work in the long term (as items and building blocks, there are plenty of reasons to keep them around for a long period of time). There are also no particular benefits to using names of nonexistent players as SkullOwners, although the system should probably accept both names and UUIDs when a custom skull is first spawned.
Steps to Reproduce:
- Spawn a custom player skull, using a command such as
give @p skull 1 3 {SkullOwner:"WolfieMario"}- Observe that, when placed, it displays the skin of the named player.
- Save and quit
- Using an NBT editor, examine the skull as it is saved in your inventory. The SkullOwner remains a String tag of the player's display name, meaning it will be broken if this player changes their name, and may even become a different player's skull if somebody else takes the name.
This will cause issues when name-changing is available to the public. Until then, the bug won't have any in-game effects, but 1.8 will already be released before name-changing is possible, and by then it would be too late to fix this (barring a 1.8.1, of course).
Place the skull and break it in survival, then it is inverted to the new uuid format, however it loses the wol's skull name
Is this still a concern in the current Minecraft version 14w30c or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Fixed: skull items and blocks now store Name, (UU)Id, and texture Signature and Value tags (encoding a URL directly to the texture file on the skin servers). This means skulls shouldn't change appearance when a player changes their skin anymore. I also think the Name tag solves the issue FVbico mentioned, but I haven't tested that yet. They also correctly update to these tags even when /given or /setblocked with the old (name-only) tag.
I'm sorry I didn't check this sooner; I think it has used this new format for a very long time now (without the Name tag, however). It just didn't when I first posted this ticket.
Hence the reason we're going through these old / stale tickets, we want to know what is still valid prior to 1.8 wrapping up (whenever that is...)