First of all if you execute all of them from one sign in different lines, then you need to do it sign by sign. If you want them to execute from one line (all at once) I suggest you place a redstone block with a setblock that activates a command block chain.
When you use a selector that includes dimension-binding parameters (x/y/z/dx/dy/dz/distance
), the dimension of execution will be restricted to the command sender's dimension. The gameLoopFunction
function will run commands with the Overworld as the dimension of execution.
For example, the following command says the names of all entities in all loaded dimensions because no dimension-binding parameter is used:
say All entities: @e
Once one of the parameters is included, the command will only say the names of entities in the command sender's dimension. If the command were run in a command block in the Overworld, it will only say the names of entities in the Overworld. If the command block were in the End, it will only say the names of entities in the End:
say Entities in the current dimension: @e[x=0]
Since your command is running via gameLoopFunction
and includes distance=256..
, it will be restricted to selecting endermen in the Overworld (of which none will have their Dimension
tag naturally set to 1).
In 1.12, you would work around this by using /execute
to change the command sender to one that is known to be in the desired dimension, who will then run the command you wish to affect only that dimension. For example, assuming that an entity with the tag "end" exists only in the End, the following will say the names of all entities in the End dimension even if the command block (or gameLoopFunction
) running this command is not in the End:
execute @e[tag=end] ~ ~ ~ say Entities in the End: @e[x=0]
Unfortunately for 1.13, there is currently a bug preventing the dimension of execution from changing to the relevant target in /execute
: https://bugs.mojang.com/browse/MC-122893
That bug must be fixed in order to use this method. Otherwise you will have to have physical command blocks in the End, though that does not help if they are not loaded.
Best Answer
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):
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 therun
command is reached.Therefore, each
as
parameter is relative to the previous:In this command, whoever is running the
run
command will sayHello, 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 torun
.Also, we know that
/execute as
does not change position, right? Well because of this mechanic we just went over, we can forceas
to include position by doing this: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. Withstore
, 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.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