Bluefire610

Grant Yes, if the game saved all the data from the player head item on the tile entity and properly restored the item to that data when the player head block is broken, we wouldn't need to do any of this.

In that case it would be fine if SkullOwner.Name can only contain real player names.

I'd also like to add some context to make you aware of how widely used the old behavior (SkullOwner.Name can contain any string) is and why it is so widely used; Vanilla Tweaks mentioned in the above issue is not the only use case, it is merly an example.

Another Example

Gamemode 4 also uses that behavior to repair its player heads when placed down (exact link to the mcfunction library responsible).

Why Is This Behavior So Useful to the mcfunction Community?

When a player head is placed down (before snapshot 24w09a) two properties from the player head item are conserved: SkullOwner.Name and SkullOwner.Properties.textures[0].
These are two very special tags to us, as player heads are often used as a form of custom item that has an in-built texture without needing a resource pack, and we don't want those to break when a player places them down, breaks them, and picks them back up!
Hence each player head used as such an item must use one of these two tags and insert a unique value so that once the placed down player head is broken and on ground in item form, commands can restore the rest of its NBT to the default state of that custom item (e.g. lore or just some other NBT data).

So why do we prefer matching a unique value in SkullOwner.Name instead of simply matching the texture? It's because the texture is not necessarily unique! There may be multiple of these custom player heads that share a texture, but are restored to different custom heads (e.g. different lores).
Apart from that, using SkullOwner.name also allows us to put a nice '[Drop to Fix]' in the name, so in case a player picks up the player head before the commands got around to fixing, the player is instructed to drop it again.

Over the years the community has settled on a de-facto standard where we store unique strings, usually even namespaced by our datapacks and with a '[Drop to Fix]' message in front, in the SkullOwner.Name to allow us to restore the skulls when they are placed and subsequently broken. Such a string may look like '[Drop to Fix] gm4_metallurgy:arborenda_shamir'.

As you can see, these strings may be very long (longer than 16 characters for sure!) and use non-ascii characters. As a result, these are definitely not real player names, and they're not meant to be! The fact that SkullOwner.Name can have invalid player names is something we really value a lot.

I hope this could add some much needed context.

Can confirm in 1.20.4.

The previous behaviour was widely used by data packs. Being able to detect players using items on blocks is something that really pushed data packs forward.

I'm part of a team maintaining 88 data packs which aim to smoothly integrate into vanilla. The `item_used_on_block` trigger was what finally freed us from the so called 'floor crafting', where we could only react to players throwing items on the ground, and enabled us to do less floor crafting. If this went through it would break a lot of stuff and throw us back to having the player throw items on the ground. Please reconsider this change.

Below are some examples on how the previous behaviour was used:

• Our custom liquid storage blocks

• These tile-entity-relocators

• Our enchantment extractor machine

• Or this multi block ingot doubler

In all of these packs the initial crafting relies on our Custom Crafting system, which allows for NBT crafting (as NBT crafting is not available via recipes in the normal Crafting Table). This is only possible thanks to the item used on block trigger.

This no longer happens in 1.17.1.

Also happens in 1.17.1-pre1.

Thanks for your help, but that's not really helpful, is it?

This will of course also work with normal levity, you just need a block above your head to stop you from gaining height.

Thanks Grey, but is it really?

This is a leftover of that split. It looks like /fill was updated to deal with this scenario but /setblock wasn't.

It does not affect all ridden entities. Command Blocks were able to teleport the minecart / the horse whilst I was riding the cart/the horse, however, Command Blocks can not teleport a boat ridden by a player - only the player riding the boat can.

It doesn't work with horses nor does it work with minecarts