Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-121934

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

    Details

    • Type: Bug
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: Minecraft 17w45b, Minecraft 17w46a, Minecraft 17w47a, Minecraft 17w47b, Minecraft 17w48a, Minecraft 17w49a, Minecraft 17w49b, Minecraft 17w50a
    • Fix Version/s: Minecraft 18w01a
    • Confirmation Status:
      Confirmed

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                dinnerbone [Mojang] Dinnerbone (Nathan Adams)
                Reporter:
                Possseidon Dominik Vogel
              • Votes:
                44 Vote for this issue
                Watchers:
                33 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  CHK: