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:
Place down two armor stands on top of two stone blocks
Run the following command:
/execute as @e[type=armor_stand] at @s if block ~ ~-1 ~ stone run say hi
Both armor stands will say hi, which is correct
Change the block below one armor stand with something different and run the command again
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
is duplicated by 15
Comments 17
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.
@ChaosNemisis LOL, did you even read the bug report? There is a workaround (even though it is somewhat tedious) using a separate function. 😃
@Boomber got confirmed already for 50a and is (probably) finally fixed for the next snapshot, which has yet to come out
Does this still occur if you include
at @s
afteras @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.