Teleporting the initial executor affects the positions of other branches in execute command.
Here is the command that is causing the issue. Summon at least four armor stands and run the following command in chat.
/execute as @e[c=5] run tp @a ~ ~1 ~Inexplicably, the player teleports 5 blocks up. ❌
Adding a single positioned ~ ~ ~ subcommand fixes this. Setting the current location to the current location shouldn't have any effect, but something has changed.
/execute positioned ~ ~ ~ as @e[c=5] run tp @a ~ ~1 ~The player teleports up only 1 block, which is the expected behaviour. ✔
Attachments
Comments 7
migrated
Thank you for your report!
We're tracking this issue in MCPE-165278, 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 (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 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.
This issue is different from MCPE-165278. I know that depth-first/breadth-first order can change the logic of a command, but that doesn't explain how the forked branches are changing their execution position even though there is no position-related subcommands. You can see that the commands in my report don't have `at @p`, which means that there is no means to re-capture the player's position.
Additionally, I would like to mention that this does not happen when running from a command block.
Still in the latest version.
Execute the following command in chat:
/execute positioned as @s as @e[c=5] run tp @a ~ ~1 ~
The player teleports 5 blocks up❌
Expected behavior:
"positioned at @s" is executed only ONCE and does NOT fork the execution. The execution position should not change in the five branches of "as @e[c=5]".
Thank you for your report!
However, this issue has been temporarily closed as Awaiting Response.
Is this issue still present in the latest version? If so, could you please add it to the list of affected versions (or mention it if you are not the reporter)? Additionally, could you attach a video demonstrating the issue?
This ticket will automatically reopen when you reply.
Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📓 Project Summary – 📧 Suggestions – 📖 Minecraft Wiki
Thank you for your report!
After consideration, the issue is being closed as Working as Intended.
Please note, that mechanics of the game may change between updates.
Things such as graphics, sounds, world creation, biomes, redstone, villagers, and animals may not work the same in current versions.
Full Version History – Snapshot Version History – Feature Requests and Suggestions
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Huh… this is too weird to be WAI.
A possible explanation for this issue is that the both the first creation of the execution context and the as subcommand did a shallow copy when copying player’s position, which was affected by the subsequent teleportation, but is this really the official opinion of Mojang? It's very strange that the developers would expect the user to understand this distinction between shallow and deep copies that occur internally in each subcommand.