Bloo
- Bluefire610
- bluefire610
- Europe/Stockholm
- Yes
- No
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
MC-228525
How to replicate:
1. place a command block which is constantly executing "/tp @e[type=Boat,c=1] ~1 ~ ~"
2. summon any boat
3. get in
4. type "/tp @e[type=Boat,c=1] ~1 ~ ~" in chatYou'll notice the command block isn't allowed to interact with the boat when a player is riding it, however, the player inside the boat is allowed to manipulate the boat using the chat
{Motion:[0:0.0d,1:0.0d,2:1.0d]}. Executing a command as the player inside the boat(/execute <player in the boat> ~ ~ ~ /tp @e[type=Boat,c=1] ~1 ~ ~) doesn't work either. The same effect applies to {{/entitydata @e[type=Boat,c=1]}}
Causing a bit of lag by taking a screenshot sometimes results in the boat being teleported as long as the game is laggingHow to replicate:
1. place a command block which is constantly executing "/tp @e[type=Boat,c=1] ~1 ~ ~"
2. summon any boat
3. get in
4. type "/tp @e[type=Boat,c=1] ~1 ~ ~" in chatYou'll notice the command block isn't allowed to interact with the boat when a player is riding it, however, the player inside the boat is allowed to manipulate the boat by using the chat (/tp @e[type=Boat,c=1] ~1 ~ ~) . Executing a command as the player inside the boat (/execute <player in the boat> ~ ~ ~ /tp @e[type=Boat,c=1] ~1 ~ ~) doesn't work either. The same effect applies to {{/entitydata @e[type=Boat,c=1]
{Motion:[0:0.0d,1:0.0d,2:1.0d]}}}
Causing a bit of lag by taking a screenshot sometimes results in the boat being teleported as long as the game is lagging
How to replicate:
1. place a command block which is constantly executing "/tp @e[type=Boat,c=1] ~1 ~ ~"
2. summon any boat
3. get in
4. type "/tp @e[type=Boat,c=1] ~1 ~ ~" in chatYou'll notice the command block isn't allowed to interact with the boat when a player is riding it, however, the player inside the boat is allowed to manipulate the boat by using the chat (/tp @e[type=Boat,c=1] ~1 ~ ~) . Executing a command as the player inside the boat (/execute <player in the boat> ~ ~ ~ /tp @e[type=Boat,c=1] ~1 ~ ~) doesn't work either. The same effect applies to {{"/entitydata @e[type=Boat,c=1]
{Motion:[0:0.0d,1:0.0d,2:1.0d]}"}}
Causing a bit of lag by taking a screenshot sometimes results in the boat being teleported as long as the game is lagging
How to replicate:
1. place a command block which is constantly executing "/tp @e[type=Boat,c=1] ~1 ~ ~"
2. summon any boat
3. get in
4. type "/tp @e[type=Boat,c=1] ~1 ~ ~" in chatYou'll notice the command block isn't allowed to interact with the boat when a player is riding it, however, the player inside the boat is allowed to manipulate the boat by using the chat (/tp @e[type=Boat,c=1] ~1 ~ ~) . Executing a command as the player inside the boat (/execute <player in the boat> ~ ~ ~ /tp @e[type=Boat,c=1] ~1 ~ ~) doesn't work either. The same effect applies to
{Motion:[0:0.0d,1:0.0d,2:1.0d]}{{"/entitydata @e[type=Boat,c=1]"}}
Causing a bit of lag by taking a screenshot sometimes results in the boat being teleported as long as the game is lagging
Ridden entities (Boat/Minecart/Horse)can't be teleported by command bocks when riddenBoats can't be teleported by command blocks when ridden
When an entity is killed and a score is assigned to that entity in the same tick, but after it was killed (using functions and @s), a scoreboard entry is created that can't be deleted easily. One would expect scoreboard entries of dead entities to be removed.
How to reproduce
- Create a function with two commands:
kill @s
scoreboard players set @s <some_objective>- Execute this function as some entity.
- Inspect the scoreboard using the sidebar
- Notice a scoreboard entry with the UUID of the entity that was killed by the function.
This behavior was not present before 1.17.
When an entity is killed and a score is assigned to that entity in the same tick, but after it was killed (using functions and @s), a scoreboard entry is created that can't be deleted easily. One would expect scoreboard entries of dead entities to be removed.
How to reproduce
- Create a function with two commands:
kill @s
scoreboard players set @s <some_objective>- Execute this function as some entity.
- Inspect the scoreboard using the sidebar
- Notice a scoreboard entry with the UUID of the entity that was killed by the function.
This behavior was not present before 1.17.
When an entity is killed and a score is assigned to that entity in the same tick, but after it was killed (using functions and @s), a scoreboard entry is created that can't be deleted easily. One would expect scoreboard entries of dead entities to be removed.
How to reproduce
- Create a function with two commands:
kill @s
scoreboard players set @s <some_objective> 1- Execute this function as some entity.
- Inspect the scoreboard using the sidebar
- Notice a scoreboard entry with the UUID of the entity that was killed by the function.
This behavior was not present before 1.17.
It doesn't work with horses nor does it work with minecarts
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.
This is a leftover of that split. It looks like /fill was updated to deal with this scenario but /setblock wasn't.
Thanks Grey, but is it really?
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.
Also happens in 1.17.1-pre1.
This no longer happens in 1.17.1.
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:
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.
Can confirm in 1.20.4.
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.
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.