The /execute command is a very versatile command that is used to execute commands in a variety of situations and conditions. It allows multiple parameters to choose, who, when, and where to execute the command.

Parameters do not have a strict order syntax (except for run, which has to be at the end). Does order of parameters affect the end result of the command? Are there some parameters that are calculated first over others?


This is a self-answered question. If you have additional details, feel free to comment or post another answer.

Short answer: Does order matter? Yes, order matters.

All of your parameters are calculated from left to right. Here are some examples (command on top, result below):

/execute as @e[type=cow] if entity @s[type=cow] as @e[type=sheep] run say Hello, World!

[Sheep] Hello, World!

Switches the executing entity to the cow, then if it detects itself as a cow, switch the executing entity to the sheep and make it say Hello, World!

Concerning the as parameter:

The as parameter is used to change the entity executing the command. The switch to the new entity in control is made right as the parameter is processed, not when the run command is reached.

Therefore, each as parameter is relative to the previous:

/execute as @e[type=cow,limit=1] as @s run say Hello World!

[Cow] Hello World!

In this command, whoever is running the run command will say Hello, World to the chat with their namestamp. But who will that be, me or the cow?
In this case, it will be the cow who will run the command, because the 2nd parameter (as @s) is relative to the first. Because the entity was previously set to the cow, @s will refer back to the cow, because the switch to the new entity is made right then and there, not when it gets to run.

Also, we know that /execute as does not change position, right? Well because of this mechanic we just went over, we can force as to include position by doing this:

/execute as @e[type=cow,limit=1] at @s run ...

Because @s is relative to the entity currently in control of the command, that means it will refer to the cow. Therefore the position of execution will be moved to the cow.
Remember though, if you want to switch to another entity and include its position again, you will need to type both parameters again (switching the 1st target selector to reference the next entity to be in control)

Concerning the store parameter:

store is a special case. With store, the location to save is "primed" when the command runner gets to that position. Then, once the command finishes executing, the result is stored in the primed position, even if the executing entity/position is changed.

/execute as @e[type=cow] store result score @s test as ExpertCoder14 if entity @a[name=ExpertCoder14]

Although I may be the one that checks for the player, it is still the cow whose score is updated. This is because the score parameter was primed while the cow had control of the command.

Learn more about /execute on the Minecraft Wiki: Commands/execute

  • I think technically the return value of "as" and some more /execute sub-commands are always what they get as input, so they essentially just hand it on. But your explanation works as well. May 31 '20 at 8:31
  • Every command has a return value, which you can use in /execute store (or comparators, but don't do that). Each sub-command of /execute is essentially a full command, you can just skip the "… run execute …" in between. What I suspect is that the return value of /execute as is always the same one as the return value of whatever command you execute as something, it just gets passed on by /execute as. So you would still read the return value of the command directly after /execute store, it just happens to be the same one as the return value of the command after that. Just a theory. May 31 '20 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.