MC-125067Command context/selectors in /execute are evaluated too early
The new /execute command gives detailed control over the command context given to a command that is to be executed. However, the way command contexts are computed doesn't account for the fact that command context may change in iterations of the outer loop and should then be different in subsequent iterations.
For many use-cases this is perfectly fine because the command context rarely (intentionally) changes. However, for some applications this is not sufficient. Consider the following command, ran when exactly one player and a couple of other entities are in the game:
/execute as @e at @p run tp @p ~ ~ ~1
Expected behavior: the player is teleported one block for each entity in the world. If there are 10 armor stands and the player, the player should be teleported 11 blocks. Actual behavior: the player is teleported one block. A reproduction case not involving teleportation can be found in this comment.
The following is a simplified, pseudo code interpretation of how /execute looping is understood to work with this command:
compute contexts for all loops loop over @e loop over @p stitch together computed command context run "tp @p ~ ~ ~1" with computed command context
Instead, it should work somewhat like this:
calculate contexts for @e loop loop over @e calculate contexts for @p loop loop over @p stitch together context for this iteration run tp @p ~ ~ ~1 with computed command context
Note that the implementation of /execute wasn't looked at in detail for this ticket, so it contains a healthy dose of speculation.
Linked Issues
is duplicated by1
Created Issue:
Information isn't updated in the iteration of execute
When executed as "execute @ e [c = 2] ~ ~ ~ tp @ p ~ 1 ~ ~ ~ 90 ~" in 1.12 or earlier, the player moved 2 blocks x direction and rotated 180 degrees.
However, if you try to do the same with the new execute command in 1.13 you should write "execute positioned as @e[limit=2] positioned as @p run tp @p ~1 ~ ~ ~90 ~", but this will only move one block and rotate only 90 °.
This seems to be caused by the fact that the position and the direction are not changed in the iteration of the execute command.
This also affects arguments such as scores and x, y_rotation.
As a result of the optimization of the execute command, this specification is inconvenient because it is impossible to realize such as moving by the number of entities.
I propose the modification so that the following execute command uses the new information when multiple "execute ~ run" are superimposed.
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
When executed as "execute @
e[c=2] ~ ~ ~ tp @p ~1 ~ ~ ~90 ~" in 1.12 or earlier, the player moved 2 blocks x direction and rotated 180 degrees.
However, if you try to do the same with the new execute command in 1.13 you should write "execute positioned as @e [limit=2] positioned as @p run tp @p ~1 ~ ~ ~90 ~", but this will only move one block and rotate only 90 °.
This seems to be caused by the fact that the position and the direction are not changed in the iteration of the execute command.
This also affects arguments such as scores and x, y_rotation.
As a result of the optimization of the execute command, this specification is inconvenient because it is impossible to realize such as moving by the number of entities.
I propose the modification so that the following execute command uses the new information when multiple "execute ~ run" are superimposed.When executed as "execute @e [c=2] ~ ~ ~ tp @p ~1 ~ ~ ~90 ~" in 1.12 or earlier, the player moved 2 blocks x direction and rotated 180 degrees.
However, if you try to do the same with the new execute command in 1.13 you should write "execute positioned as @e [limit=2] positioned as @p run tp @p ~1 ~ ~ ~90 ~", but this will only move one block and rotate only 90 °.
This seems to be caused by the fact that the position and the direction are not changed in the iteration of the execute command.
This also affects arguments such as scores and x, y_rotation.
As a result of the optimization of the execute command, this specification is inconvenient because it is impossible to realize such as moving by the number of entities.
I propose the modification so that the following execute command uses the new information when multiple "execute ~ run" are superimposed.
Information isn't updatedin the iteration of executeCommand context in /execute is evaluated too early
When executed as "execute @e [c=2] ~ ~ ~ tp @p ~1 ~ ~ ~90 ~" in 1.12 or earlier, the player moved 2 blocks x direction and rotated 180 degrees.
However, if you try to do the same with the new execute command in 1.13 you should write "execute positioned as @e [limit=2] positioned as @p run tp @p ~1 ~ ~ ~90 ~", but this will only move one block and rotate only 90 °.
This seems to be caused by the fact that the position and the direction are not changed in the iteration of the execute command.
This also affects arguments such as scores and x, y_rotation.
As a result of the optimization of the execute command, this specification is inconvenient because it is impossible to realize such as moving by the number of entities.
I propose the modification so that the following execute command uses the new information when multiple "execute ~ run" aresuperimposed.The new /execute command gives detailed control over the command context given to a command that is to be executed. However, the way command contexts are computed doesn't account for the fact that command context may change in iterations of the outer loop and should then be different in subsequent iterations.
For many use-cases this is perfectly fine because the command context rarely (intentionally) changes. However, for some applications this is not sufficient. Consider the following command, ran when exactly one player and a couple of other entities are in the game:
/execute as @e at @p run tp @p ~ ~ ~1Expected behavior: the player is teleported one block for each entity in the world. If there are 10 armor stands and the player, the player should be teleported 11 blocks. Actual behavior: the player is teleported one block.
The following is a simplified, pseudo code interpretation of how /execute looping is understood to work with this command:
compute contexts for all loops loop over @e loop over @p stitch together computed command context run "tp @p ~ ~ ~1" with computed command contextInstead, it should work somewhat like this:
calculate contexts for @e loop loop over @e calculate contexts for @p loop loop over @p stitch together context for this iteration run tp @p ~ ~ ~1Note that the implementation of /execute wasn't looked at in detail for this ticket, so it contains a healthy dose of speculation.
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
The new /execute command gives detailed control over the command context given to a command that is to be executed. However, the way command contexts are computed doesn't account for the fact that command context may change in iterations of the outer loop and should then be different in subsequent iterations.
For many use-cases this is perfectly fine because the command context rarely (intentionally) changes. However, for some applications this is not sufficient. Consider the following command, ran when exactly one player and a couple of other entities are in the game:
/execute as @e at @p run tp @p ~ ~ ~1Expected behavior: the player is teleported one block for each entity in the world. If there are 10 armor stands and the player, the player should be teleported 11 blocks. Actual behavior: the player is teleported one block.
The following is a simplified, pseudo code interpretation of how /execute looping is understood to work with this command:
compute contexts for all loops loop over @e loop over @p stitch together computed command context run "tp @p ~ ~ ~1" with computed command contextInstead, it should work somewhat like this:
calculate contexts for @e loop loop over @e calculate contexts for @p loop loop over @p stitch together context for this iteration run tp @p ~ ~ ~1Note that the implementation of /execute wasn't looked at in detail for this ticket, so it contains a healthy dose of speculation.
The new /execute command gives detailed control over the command context given to a command that is to be executed. However, the way command contexts are computed doesn't account for the fact that command context may change in iterations of the outer loop and should then be different in subsequent iterations.
For many use-cases this is perfectly fine because the command context rarely (intentionally) changes. However, for some applications this is not sufficient. Consider the following command, ran when exactly one player and a couple of other entities are in the game:
/execute as @e at @p run tp @p ~ ~ ~1Expected behavior: the player is teleported one block for each entity in the world. If there are 10 armor stands and the player, the player should be teleported 11 blocks. Actual behavior: the player is teleported one block. A reproduction case not involving teleportation can be found in this comment.
The following is a simplified, pseudo code interpretation of how /execute looping is understood to work with this command:
compute contexts for all loops loop over @e loop over @p stitch together computed command context run "tp @p ~ ~ ~1" with computed command contextInstead, it should work somewhat like this:
calculate contexts for @e loop loop over @e calculate contexts for @p loop loop over @p stitch together context for this iteration run tp @p ~ ~ ~1Note that the implementation of /execute wasn't looked at in detail for this ticket, so it contains a healthy dose of speculation.
Command context in /executeisevaluated too earlyCommand context/selectors in /execute are evaluated too early
is duplicated by
The new /execute command gives detailed control over the command context given to a command that is to be executed. However, the way command contexts are computed doesn't account for the fact that command context may change in iterations of the outer loop and should then be different in subsequent iterations.
For many use-cases this is perfectly fine because the command context rarely (intentionally) changes. However, for some applications this is not sufficient. Consider the following command, ran when exactly one player and a couple of other entities are in the game:
/execute as @e at @p run tp @p ~ ~ ~1Expected behavior: the player is teleported one block for each entity in the world. If there are 10 armor stands and the player, the player should be teleported 11 blocks. Actual behavior: the player is teleported one block. A reproduction case not involving teleportation can be found in this comment.
The following is a simplified, pseudo code interpretation of how /execute looping is understood to work with this command:
compute contexts for all loops loop over @e loop over @p stitch together computed command context run "tp @p ~ ~ ~1" with computed command contextInstead, it should work somewhat like this:
calculate contexts for @e loop loop over @e calculate contexts for @p loop loop over @p stitch together context for this iteration run tp @p ~ ~ ~1 with computed command contextNote that the implementation of /execute wasn't looked at in detail for this ticket, so it contains a healthy dose of speculation.
is duplicated by
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
[Mojang] Nathan Adams![[Helper] Lord_Quadrato](../../../data/avatars/users/26105.png){kind=small}
[Mojang] Nathan Adamsis duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
Likely caused by MC-125067, resolving as a duplicate of that issue.
Thank you for your report!
We're tracking this issue in MC-125067, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
The issue
Bedrock captures context for every iteration of a branching execute command. This differs slightly from Java's behavior.
How to reproduce
Spawn 5 armor stands
/execute as @e at @p run tp @p ~ ~1 ~
Try this in both Java and Bedrock.
In Java, the player is only teleported up one block. The context for the player's position is only captured once.
In Bedrock, the player is teleported up 6 blocks. The context for the player's position was re-captured each iteration.
Java's behavior was reported in MC-125067 and marked "won't fix." I think Bedrock's behavior is somewhat more intuitive, but may be less performant. Regardless, I think it's very important that one behavior is chosen for both platforms.
This is not a valid command, neither in 1.12, nor in 1.13.
That's what the command is supposed to do, what did you expect?
@violine1101
I'm sorry. There was wasted space in the command.
This command is valid in 1.12.
With this command, you will move two blocks and rotate 180 °.
No, that command will move you one block and rotate you 90° as well. Maybe the command was simply run twice?
@violine1101
Perhaps you are doing it in a world where there is no one other than yourself?
My writing is based on the assumption that there are two or more entities.
Oh. I misunderstood your commands. Stupid me.
Now, this is what the command does in 18w06a: It teleports you one block and rotates you 180°. Apart from myself, there's only an armor stand in the world. I'm not exactly sure why I got a different result than you.
@violine1101
It was my misunderstanding about rotation. I forgot that the angle of tp is strange. Stupid me too.
But it shows that the phenomenon is more strange.
Even though it rotates twice, it rotates only once.
The double rotation comes from
MC-124686.@violine1101
I hope that a way to rotate and move twice even if the bug is fixed be added.
In the current specification, I have to create a function each time.
@komaramune: Updated summary and description. Let us know if we missed any important information from the old description.
@violine1101
It's a great!
I thank you for being writen appropriate sentences instead of me.
Here is a repro without teleport:
/scoreboard objectives add TEMP dummy /scoreboard objectives setdisplay sidebar TEMP /scoreboard players set @p TEMP 1 /execute at @e[limit=2] as @p at @s[scores={TEMP=1}] run scoreboard players add @s TEMP 1EXPECTED: final score of 2
ACTUAL: final score of 3
This demonstrates that the second 'at' is evaluating @s only once at the start, rather than in each iteration of the outer limit=2 loop.
Can confirm for 1.21. The famous Vanilla Tweaks team had trouble updating their datapacks because of this bug. I hope it will be looked at in the future.