mojira.dev
MC-276704

Not using a selector in a tp command breaks rotation from a completely different tp command

a teleport command which doesn't affect rotation at all makes the following teleport commands give the entity different rotation values depending on whether the original tp command uses the @s selector, or no selector at all.

Steps to reproduce:
-Download the example datapack
-Run /execute positioned 0.0 0.0 0.0 summon minecraft:marker at @s rotated 0 -50 run function example:test1
-Run /execute positioned 0.0 0.0 0.0 summon minecraft:marker at @s rotated 0 -50 run function example:test2
-Compare the Rotation values given by the /tellraw command

Expected Behavior:
Using an @s selector vs not using a selector wouldn't affect the rotation resulting from a completely different teleport command (Just like it worked in 1.21.1)

Observed Behavior:
The difference between using an @s selector vs not using one is visible through the entity's rotation

/data/example/test1.mcfunction -> gives a Rotation[1] value of 89.99999f (expected value)

tp @s 0.0 0.0 0.0
tp @s ~ ~10 ~
execute at @s facing 0.0 0.0 0.0 run tp @s 0 0 0 0 ~
tellraw @a {"entity":"@s","nbt":"Rotation[1]","color":"green"}

/data/example/test2.mcfunction gives a Rotation[1] value of 40.0f (it seems to always add 90° to the rotation given in execution context)

tp 0.0 0.0 0.0
tp @s ~ ~10 ~
execute at @s facing 0.0 0.0 0.0 run tp @s 0 0 0 0 ~
tellraw @a {"entity":"@s","nbt":"Rotation[1]","color":"green"}

Attachments

Comments 2

This issue is fixed, but for posterity I wanted to mention what the problem actually was, without the complex test setup:
/tp X Y Z (with no target) was treated as /tp @s X Y Z ~ ~ instead of /tp @s X Y Z. That is, it set the target's rotation equal to the context rotation, instead of leaving it alone.

nedraw

Shugoh

Community Consensus

Platform

Important

Commands

24w37a

24w38a

Retrieved