mojira.dev
MC-121934

execute sub-commands only run (for each entity), if the next sub-command runs at least one command for each entity

To start off with, this bug is the reason, why MC-121727 is open again. Somebody commented it below there and it got reopened, even though this is actually a slightly different problem and belongs in its own bug report. I will post a comment under that report as well, linking to this, so that it gets closed again as resolved.

As explained in the title, even though if and unless are checked for every entity, only if all conditions are met it will execute the command for each entity.

Example:

  1. Place down two armor stands on top of two stone blocks

  2. Run the following command:

    /execute as @e[type=armor_stand] at @s if block ~ ~-1 ~ stone run say hi
  3. Both armor stands will say hi, which is correct

  4. Change the block below one armor stand with something different and run the command again

  5. This time, no text will appear in the chat, as only one of the two conditions were met

I for myself doubt, that this is the intended behavior, but even if it is, the following command should work nonetheless:

/execute as @e[type=armor_stand] at @s run execute if block ~ ~-1 ~ stone run say hi

By nesting the execute, the two nested execute-calls should be completely isolated from each other. This is not the case though, as it yields the exact same result, as without the nesting.

This implies, that nested executes will get optimized into one execute.

If you put the conditional execute into a function, and run that function, instead of having the execute inlined, it does work as you would have expected it with the nested execute, as those two function calls are completely isolated from each other now.

This all got a bit long... The huge and-gate was probably never intended, which would make the execute optimization valid as well.


VERY IMPORTANT additional information I found, after taking a look at the dupe MC-122821:

As it turns out, not only if and unless cause this and-behavior to happen and they are actually not the core reason for this to happen at all. The reason is something more simple, which can be shown by a simple example:

execute as @e[type=armor_stand] as @s[tag=test] run say hi

You might think this example yields the same output as this example:

execute as @e[type=armor_stand,tag=test] run say hi

but it does not and again, only if all armor stands have the test tag it will, and if not, nothing will happen. The reason is, that the first as sub-command only runs for all entities, if it can successfully run the next sub-command in line (not including the final run command, except for nested executes, as those get optimized into one execute...) for each of those entities.

This means, only if the @s[tag=test] returns at least one entity, for each entity of the first sub-command, the command will do something. In other words, if (at least) one armor stand does not have the tag test, not all armor stands could successfully execute a command and therefore no armor stand will.

Going to change the title to something more fitting shortly.

Linked issues

MC-121938 /execute detects if distance to all entities who execute the command when using distance in selector in if entity Resolved MC-122017 "execute as...if" works incorrectly Resolved MC-122055 If "/execute if" fails for one executing entity, it fails for all Resolved MC-122480 execute score comparison Resolved MC-122556 Execute is a little fishy Resolved

Comments 17

Does this still occur if you include at @s after as @e[type=armor_stand] in your example commands? If I'm reading this correctly, the position of the command as it now stands would be from the player or whatever command blocks is running it.

Sorry, I only forgot that in the report, thx for pointing it out. The testing was done with at @s. I added it to the report.

Great, I can now confirm. Thank you for the detailed report!

Can double confirm
This is probably the reason 1.13 maps and data packs have not been released yet.

@ChaosNemisis LOL, did you even read the bug report? There is a workaround (even though it is somewhat tedious) using a separate function. 😃

7 more comments

Still not working in 17w50a

@Boomber got confirmed already for 50a and is (probably) finally fixed for the next snapshot, which has yet to come out

Still happening in 17w50a.

@unknown, it's already confirmed for that version and marked fixed for the next snapshot.

Possseidon

Nathan Adams

Confirmed

/execute, /execute-if, /execute-unless

Minecraft 17w45b, Minecraft 17w46a, Minecraft 17w47a, Minecraft 17w47b, Minecraft 17w48a, Minecraft 17w49a, Minecraft 17w49b, Minecraft 17w50a

Minecraft 18w01a

Retrieved