summon armor_stand ~ ~ ~ {NoGravity:1b}Go fly somewhere looking in some diagonal direction
execute as @e[type=armor_stand] run teleport @s ~ ~ ~ ~ ~EXPECTED
armor stand gains my position as well as my facing rotation
ACTUAL
armor stand gains my position but preserves its existing facing rotation
It appears that currently teleport is bugged so that the rotation arguments (4th and 5th arguments of that teleport 'overload') use the sender's rotation rather than the context's rotation. You can see that with e.g.
teleport @e[type=armor_stand] ~ ~ ~ ~ ~which does change the facing. As well as
/execute rotated ~20 ~ run teleport @e[type=armor_stand] ~ ~ ~ ~ ~which still gains my facing, not mine+20.
To be clear, here is what I imagine makes the most sense for teleport:
teleport @s ~ ~ ~ changes position to context position, preserves existing rotation
teleport @s ~ ~ ~ ~ ~ changes position to context position, changes rotation to context rotationAfter this bug is fixed, you would have an armor stand keep its location but gain the facing rotation of the player with
execute as @e[tag=AS] at @s rotated as @p run teleport @s ~ ~ ~ ~ ~Possibly a duplicate of the more general MC-125772.
Linked issues
Comments 4
From the 18w02a blogpost, as changes only the sender, and at changes position, rotation, and dimension.
This can be demonstrated by running something like the following:
/execute as @e[type=armor_stand] run particle barrier ^ ^ ^1Contrast with
/execute rotated as @e[type=armor_stand] run particle barrier ^ ^ ^1and
/execute at @e[type=armor_stand] positioned as @s run particle barrier ^ ^ ^1
It seems that the behavior you experienced with:
Is intentional under the assumption that /execute as <entity> is intended to use the rotation of the executing entity, which it currently does.
The other issue is that "rotated as <entity>" and "rotated <y x>" fail to override the rotation of the executing entity when running /teleport @s ~ ~ ~ ~ ~ in conjunction with it. The same issue occurs in this situation:
, in which using "at @p" does not override the executing entity's rotation with the player's rotation.
This is not the case when using "rotated as <entity>" along with /teleport @s ~ ~ ~ facing ^ ^ ^. For example,
will preserve the position of the armorstand, but will give it the same facing direction as the player.
This leads me to believe that the issue mentioned above may actually be the intended behavior, and that the the facing condition is meant to be used in order to override the executing entity's rotation. The other explanation for this behavior is that, even though the documentation states that /execute at <entity> will use that entity's rotation, it may not actually be the case. Personally, this makes sense; /execute as <entity> sets the executor and rotation to that entity, and /execute at <entity> sets the position and dimension to that of the entity. It is up to the developers to decide how the properties of an entity are divided up among the different conditional statements, and until there is more clarity on the subject, it is difficult to say what is intentional and what isn't. Most of the statements I've made are speculation at best, but hopefully this provides some insight on the causes of the issue.