Note: This is an informational page, not a help desk.
In a Reddit post, Dinnerbone announced several changes to commands for 1.13, among them the removal of the /execute command in favor of more powerful alternatives. This thread is a second description of how the new commands relate to /execute, and a sequel to my previous thread: How to Use the /execute Command.
/execute as <selector> ...
/execute at <selector> ...
/execute positioned <x y z> ...[/p]
[p]/execute positioned as <selector> ...[/p]
[p]/execute rotated <yaw> <pitch> ...[/p]
[p]/execute rotated as <selector> ...[/p]
[p]/execute facing <x y z> ...[/p]
[p]/execute facing entity <selector> feet|eyes ...[/p]
[p]/execute anchored feet|eyes ...[/p]
[p]/execute in <dimension> ...
/execute if|unless block <x y z> <block> ...
/execute if|unless blocks <src-begin> <src-end> <dest> all|masked ...
/execute if|unless entity <selector> ...
/execute if|unless score <selector1> <objective1> <|>|<=|>=|= <selector2> <objective2> ...[/p]
[p]/execute if|unless score <selector> <objective> matches <range>
/execute store result|success score <selector> <objective> ...
/execute store result|success block <x y z> <block> <nbt-key> <numeric-type> <scale> ...
/execute store result|success entity <selector> <nbt-key> <numeric-type> <scale> ...
These commands are actually subcommands, which means you can leave off the /execute label when chaining them. The final command is signified by the keyword run.
Who's executing?
/execute as <selector> ...
This runs the specified command with the specified entity(s) as command senders. However, the position the command runs from remains unchanged. For example, running the following from a command block:
/execute as @e[type=creeper,name=Bob] run give @p stone
will give stone to the single player nearest the command block, one block for each creeper named Bob. Use /as for commands where the sender is important, such as the below. A good rule of thumb is to use /as if you plan to use @s later in the command, and to otherwise use /at.
/execute as @e run say @s //each entity says their name
/execute as @a[scores={importance=5..}] run function importance:do_important_things //each matched player does important things
Now...where to execute?
/execute at <selector> ...
The /at command is similar to /as, but runs the command from the position of the entity(s) and not using the entity(s) as command senders. For example, the intended use of the previous command targeting creepers named Bob is this.
/execute at @e[type=creeper,name=Bob] run give @p stone
This command will give stone to the player(s) nearest to any creeper named Bob. Use /at for when the sender is not important. When both the sender and the position are important, use both.
/execute as @e[type=creeper] at @s run tell @p Ssssss... //each creeper creeps out the nearest player
/execute at @p run teleport @e[tag=special] ~ ~-5 ~ //teleports the special entity five blocks below the nearest player
The /positioned command may be used as a direct correspondence to the portion of the original /execute command, to be used in the same circumstances. I don't really have much to say about this one other than to use it when you put anything other than "~ ~ ~" as the coordinates to the old /execute.
The /rotated command additionally sets the rotation used by the command, either in the specified direction or the same as the specified entity. The /facing command also sets the rotation, but either looks at the specified block or at the specified entity's feet or eyes. The /anchored command sets the local coordinate origin at the sender's feet or eyes, and the /in command sets the command to run in the specified dimension.
The /at command sets position, rotation, and dimension to the specified entity.
/execute as @e[type=arrow] at @s if block ~ ~ ~ tripwire run kill @s
/if block is the new version of /testforblock, while /if blocks is the new version of /testforblocks and /if entity is the new version of /testfor. /if score is the replacement for /scoreboard test.
/execute if block ~ ~5 ~ red_wool run function mymap:do_red_wool_things
/execute if entity @e[scores={awesome=1..}] run setblock ~ ~5 ~ redstone_block
/execute if score @p Health < @e[name=Boss] Health run say Your health is less!
Note that all of the conditional commands can be negated by using "unless" in place of "if".
When to use /as or /at?
Each command provides half the functionality of /execute. Which one to use depends on what functionality you need.
Use /as when you need a specific entity or entities to run the command
Use /as when you use @s later in the command (including functions)
Use /at when you need the command run at an entity's position
Use /if entity when you are testing for the existence of an entity
Use both when you need the functionality of both
Remember: /as @s makes no sense!
Removal of common commands
In the process of overhauling /execute, several common commands were removed in favor of the new /execute. Migrating these commands is as follows.
/testfor <entity>
/execute if entity <entity>
/testforblock <x y z> <block>
/execute if block <x y z>
/testforblocks <src begin> <src end> <dest> all|masked
/execute if blocks <src begin> <src end> <dest> all|masked
/tp <selector> <~x ~y ~z>
/execute as <selector> at @s run tp @s <~x ~y ~z>
Recommended Command Order
When writing complex /execute commands, I recommend this ordering of sub-commands.
store
as
at
anchored/positioned/rotated/facing/in
if
Examples
For writing commands, I recommend the order listed in this thread (/as, /at, /if) as this will reduce bugs caused by incorrect positions or entities. That is, set the command sender, set the position, test conditions.
/execute @e[type=creeper,name=Bob] ~ ~ ~ detect ~ ~-1 ~ minecraft:wool 14 give @p[r=3] stone
/execute at @e[type=creeper,name=Bob] if block ~ ~-1 ~ minecraft:red_wool<span style="color: #000000;"> run give @p[distance=..3] stone
/execute @e[tag=destroyable] ~ ~ ~ execute @p ~ ~ ~ playsound portal:destroy player @s ~ ~ ~ 1 1
/execute at @p if entity @e[tag=destroyable] run playsound portal:destroy player @p ~ ~ ~ 1 1
/execute @p ~ ~ ~ detect ~ ~ ~ tripwire -1 function portal:destroy_portals
/execute at @p if block ~ ~ ~ tripwire run function portal:destroy_portals
/execute @e[tag=portal] ~ ~-1 ~ scoreboard players set @p[dy=1] cooldown 1
/execute at @e[tag=portal] at ~ ~-1 ~ run scoreboard players set @p[dy=1] cooldown 1
/execute @e[name=BluePortal] ~ ~-1 ~ execute @p[dy=1] ~ ~ ~ function portal:teleport_b2o
/execute at @e[name=BluePortal] offset ~ ~-1 ~ as @p[dy=1] run function portal:teleport_b2o</span>
This is stupid and confusing. /execute was just fine and worked perfectly, why are they replacing it? Splitting it into 4 commands makes it too confusing.
This is stupid and confusing. /execute was just fine and worked perfectly, why are they replacing it? Splitting it into 4 commands makes it too confusing.
Maybe so; that's what this thread is supposed to remedy. It looks like there will be a straightforward conversion from /execute to the new commands though. It looks like a standard /execute will be /as <entities> at <entities/@s> offset <xyz> detect <xyz block> <command>. With /as, /offset, and /detect being "optional" as circumstances warrant.
The problem is, however, when using /as, it's not at the entity that's executing, that's what /at and /offset are for. In which case the replacement for out /execute now would be running three commands instead of one and looking for an unused location. Instead of executing at the target, /as will execute at the executor of the /as command. Basically, /as @p /summon Creeper ~ ~ ~ in a command block would make the player summon the creeper, but at the command block. I can think of about two uses for this. Especially with functions being added, it just seems pointless to remove an already widespread and great utility with something that just makes more effort for people and is more difficult for beginners to understand.
How to test for a players coordinates using execute...?
I feel that this update broke a crap-load of maps, and I'm sure we would all like to know how to replace "/testfor @p[x=#,y=#,z=#,r=#]" with an execute command. >:/
How to test for a players coordinates using execute...?
I feel that this update broke a crap-load of maps, and I'm sure we would all like to know how to replace "/testfor @p[x=#,y=#,z=#,r=#]" with an execute command. >:/
you can do
/execute if entity @p[x=-798,y=4,z=0,distance=..5]
will test for the nearest player that is within 5 blocks at -798,4,0 and output it to a comparator, exactly how testfor worked.
It doesn't work with a chain command block, Only with a comparator for some reason
Of course, if your simply needing to run another command upon success of the testfor conditions, you can easily imbed the command in with the execute command.
such as
execute if entity @p[x=160,y=66,z=157,distance=..5] run say hi
(this will execute as the command block)
execute as @p[x=160,y=66,z=157,distance=..5] run say hi
(this will execute as the player)
you can even do
execute as @p[x=160,y=66,z=157,distance=..5] run execute [...] run execute [...] run execute [...] and so on
What's the point of this? Everything was fine. Not only did they get rid of things such as the testfor (and other commands), they made things more complicated (/effect give playername, /kill playername), and removed the [tag] infront of things, such as @e[r=5], or @a[r=2], or @e[type=Creeper]. It's all become a jumble of confusion for whatever reason.
hmmm i think it should work with chained aswell are u sure it works with comparators? i hope so because comman block-redstone-crossover is a nice thing to have
What's the point of this? Everything was fine. Not only did they get rid of things such as the testfor (and other commands), they made things more complicated (/effect give playername, /kill playername), and removed the [tag] infront of things, such as @e[r=5], or @a[r=2], or @e[type=Creeper]. It's all become a jumble of confusion for whatever reason.
I agree, that some of the new commands will take some getting used to, However, There are some great additions to commands also. The ability to check for nbt data in a target selector is a huge improvement. (and they never removed target selector arguments, they changed and renamed a few of them like r is now distance, c is now limit, and so on.) I also love the value ranges instead of specifying a min and max value on an argument that has it such as checking for a score range. instead of @a[score_time_min=1,score_time=8] you can now do @a[scores={time=1..8,"add any other scores to check"=1}]
My experience so far with the new command library, is that almost everything that you could do in 1.12.2, you can do in 1.13.
There are a few bugs or dis-functionality of some commands right now that I dislike, but I'm keeping optimistic that they will be adjusted for 1.13, or at least shortly after.
Quote from scuroK
hmmm i think it should work with chained aswell are u sure it works with comparators? i hope so because comman block-redstone-crossover is a nice thing to have
Tested it thoroughly in various applications with a comparator in my test world. It may be a bug with the chained command blocks not triggering when the other block actually is successful.
The way these command blocks are supposed to be now is with the chained command that the was supposed to be the next chain command block, embedded into the execute. For the most part, it is pretty easy to change this over, except on preexisting, complicated systems perhaps.
But, I have came up with a work around for that too..
If you, for whatever reason, can't embed your command in the execute command, you could just add in
run setblock x y z fire
where x, y, and z are the cordinates to an air block that is surrounded by air, nowhere near any other block, anddefinitely not near anything flammable that you don't want to go up in flames.
technically, the execute command will be successfully placing the fire, which will disappear instantly, which will give a basis for a chain-conditional-always active command block to run. Not sure on the performance aspect of that though.
I think I'm starting to understand the new /execute. However, I'm still having a problem.
This command below is supposed to teleport all players within 1 radius of the armor stand "door0e" 4 blocks east relative to the armor stand:
/execute at @e[type=armor_stand,name=door0e] run tp @a[distance=1] ~-4 ~ ~
However, it just says "no entity was found". The command itself works, but the selectors don't seem to work. I just want to know how to teleport all players within a certain distance of an armor stand. The distance selector doesn't seem to work. I guess I don't understand where it's supposed to go. Is there another step I'm missing in my execute command?
I can't use static locations either (meaning I can't use selectors like x, y, z, xd, yd, zd, etc) because I am planning on having multiple of these armor stands throughout my map and I don't want to code each one individually.
I think I'm starting to understand the new /execute. However, I'm still having a problem.
This command below is supposed to teleport all players within 1 radius of the armor stand "door0e" 4 blocks east relative to the armor stand:
/execute at @e[type=armor_stand,name=door0e] run tp @a[distance=1] ~-4 ~ ~
However, it just says "no entity was found". The command itself works, but the selectors don't seem to work. I just want to know how to teleport all players within a certain distance of an armor stand. The distance selector doesn't seem to work. I guess I don't understand where it's supposed to go. Is there another step I'm missing in my execute command?
I can't use static locations either (meaning I can't use selectors like x, y, z, xd, yd, zd, etc) because I am planning on having multiple of these armor stands throughout my map and I don't want to code each one individually.
Try it with
@a[distance=..1]
Right now you are checking for players exactly 1 block away from the armor_stand, which is probably why it can't find a matching target selector. If I remember right in these snapshots, x y and z coordinates in selectors are now doubles.. or maybe floats?.., so I'm sure even if you are 0.99 blocks from the armor stand, it wont find you.
This is stupid and confusing. /execute was just fine and worked perfectly, why are they replacing it? Splitting it into 4 commands makes it too confusing.
So true. In 1.12.2 I was good at command blocks. Now? I can't even do /testfor.
So true. In 1.12.2 I was good at command blocks. Now? I can't even do /testfor.
I'll just wait for MrGarretto to make a converter. Problem is, I'm working on a command mod pack so everything's breaking in 1.13 and that's bad for the whole staff and team. No one asked for these changes, Mojang.
Note: This is an informational page, not a help desk.
In a Reddit post, Dinnerbone announced several changes to commands for 1.13, among them the removal of the /execute command in favor of more powerful alternatives. This thread is a second description of how the new commands relate to /execute, and a sequel to my previous thread: How to Use the /execute Command.
The New Commands
The old syntax of the /execute command is:
This will be refactored as follows:
These commands are actually subcommands, which means you can leave off the /execute label when chaining them. The final command is signified by the keyword run.
Who's executing?
This runs the specified command with the specified entity(s) as command senders. However, the position the command runs from remains unchanged. For example, running the following from a command block:
will give stone to the single player nearest the command block, one block for each creeper named Bob. Use /as for commands where the sender is important, such as the below. A good rule of thumb is to use /as if you plan to use @s later in the command, and to otherwise use /at.
/execute as @e run say @s //each entity says their name /execute as @a[scores={importance=5..}] run function importance:do_important_things //each matched player does important thingsNow...where to execute?
The /at command is similar to /as, but runs the command from the position of the entity(s) and not using the entity(s) as command senders. For example, the intended use of the previous command targeting creepers named Bob is this.
This command will give stone to the player(s) nearest to any creeper named Bob. Use /at for when the sender is not important. When both the sender and the position are important, use both.
The /positioned command may be used as a direct correspondence to the portion of the original /execute command, to be used in the same circumstances. I don't really have much to say about this one other than to use it when you put anything other than "~ ~ ~" as the coordinates to the old /execute.
The /rotated command additionally sets the rotation used by the command, either in the specified direction or the same as the specified entity. The /facing command also sets the rotation, but either looks at the specified block or at the specified entity's feet or eyes. The /anchored command sets the local coordinate origin at the sender's feet or eyes, and the /in command sets the command to run in the specified dimension.
The /at command sets position, rotation, and dimension to the specified entity.
Conditionals
The conditional commands are the new and improved /execute ... detect command syntax. For example, this command, which kills arrows that hit tripwire:
is rewritten as this:
/if block is the new version of /testforblock, while /if blocks is the new version of /testforblocks and /if entity is the new version of /testfor. /if score is the replacement for /scoreboard test.
/execute if block ~ ~5 ~ red_wool run function mymap:do_red_wool_things /execute if entity @e[scores={awesome=1..}] run setblock ~ ~5 ~ redstone_block /execute if score @p Health < @e[name=Boss] Health run say Your health is less!Note that all of the conditional commands can be negated by using "unless" in place of "if".
When to use /as or /at?
Each command provides half the functionality of /execute. Which one to use depends on what functionality you need.
Removal of common commands
In the process of overhauling /execute, several common commands were removed in favor of the new /execute. Migrating these commands is as follows.
Recommended Command Order
When writing complex /execute commands, I recommend this ordering of sub-commands.
Examples
For writing commands, I recommend the order listed in this thread (/as, /at, /if) as this will reduce bugs caused by incorrect positions or entities. That is, set the command sender, set the position, test conditions.
Putting the CENDENT back in transcendent!
This is stupid and confusing. /execute was just fine and worked perfectly, why are they replacing it? Splitting it into 4 commands makes it too confusing.
My Name Is Bhexion and I make datapacks.
Find me on PlanetMinecraft and Youtube.
Maybe so; that's what this thread is supposed to remedy. It looks like there will be a straightforward conversion from /execute to the new commands though. It looks like a standard /execute will be /as <entities> at <entities/@s> offset <xyz> detect <xyz block> <command>. With /as, /offset, and /detect being "optional" as circumstances warrant.
Putting the CENDENT back in transcendent!
The problem is, however, when using /as, it's not at the entity that's executing, that's what /at and /offset are for. In which case the replacement for out /execute now would be running three commands instead of one and looking for an unused location. Instead of executing at the target, /as will execute at the executor of the /as command. Basically, /as @p /summon Creeper ~ ~ ~ in a command block would make the player summon the creeper, but at the command block. I can think of about two uses for this. Especially with functions being added, it just seems pointless to remove an already widespread and great utility with something that just makes more effort for people and is more difficult for beginners to understand.
My Name Is Bhexion and I make datapacks.
Find me on PlanetMinecraft and Youtube.
How to test for a players coordinates using execute...?
I feel that this update broke a crap-load of maps, and I'm sure we would all like to know how to replace "/testfor @p[x=#,y=#,z=#,r=#]" with an execute command. >:/
wut do i put here?
you can do
will test for the nearest player that is within 5 blocks at -798,4,0 and output it to a comparator, exactly how testfor worked.
damn dude, thanks
didn't know the "r=#" was replaced with "distance=#".
:|
wut do i put here?
oof. I just tested, didn't work. :/
Proof it doesn't work
wut do i put here?
It doesn't work with a chain command block, Only with a comparator for some reason
Of course, if your simply needing to run another command upon success of the testfor conditions, you can easily imbed the command in with the execute command.
such as
What's the point of this? Everything was fine. Not only did they get rid of things such as the testfor (and other commands), they made things more complicated (/effect give playername, /kill playername), and removed the [tag] infront of things, such as @e[r=5], or @a[r=2], or @e[type=Creeper]. It's all become a jumble of confusion for whatever reason.
hmmm i think it should work with chained aswell
are u sure it works with comparators? i hope so because comman block-redstone-crossover is a nice thing to have
I agree, that some of the new commands will take some getting used to, However, There are some great additions to commands also. The ability to check for nbt data in a target selector is a huge improvement. (and they never removed target selector arguments, they changed and renamed a few of them like r is now distance, c is now limit, and so on.) I also love the value ranges instead of specifying a min and max value on an argument that has it such as checking for a score range. instead of @a[score_time_min=1,score_time=8] you can now do @a[scores={time=1..8,"add any other scores to check"=1}]
My experience so far with the new command library, is that almost everything that you could do in 1.12.2, you can do in 1.13.
There are a few bugs or dis-functionality of some commands right now that I dislike, but I'm keeping optimistic that they will be adjusted for 1.13, or at least shortly after.
Tested it thoroughly in various applications with a comparator in my test world. It may be a bug with the chained command blocks not triggering when the other block actually is successful.
The way these command blocks are supposed to be now is with the chained command that the was supposed to be the next chain command block, embedded into the execute. For the most part, it is pretty easy to change this over, except on preexisting, complicated systems perhaps.
But, I have came up with a work around for that too..
If you, for whatever reason, can't embed your command in the execute command, you could just add in
where x, y, and z are the cordinates to an air block that is surrounded by air, nowhere near any other block, and definitely not near anything flammable that you don't want to go up in flames.
technically, the execute command will be successfully placing the fire, which will disappear instantly, which will give a basis for a chain-conditional-always active command block to run. Not sure on the performance aspect of that though.
I think I'm starting to understand the new /execute. However, I'm still having a problem.
This command below is supposed to teleport all players within 1 radius of the armor stand "door0e" 4 blocks east relative to the armor stand:
/execute at @e[type=armor_stand,name=door0e] run tp @a[distance=1] ~-4 ~ ~
However, it just says "no entity was found". The command itself works, but the selectors don't seem to work. I just want to know how to teleport all players within a certain distance of an armor stand. The distance selector doesn't seem to work. I guess I don't understand where it's supposed to go. Is there another step I'm missing in my execute command?
I can't use static locations either (meaning I can't use selectors like x, y, z, xd, yd, zd, etc) because I am planning on having multiple of these armor stands throughout my map and I don't want to code each one individually.
Try it with
Right now you are checking for players exactly 1 block away from the armor_stand, which is probably why it can't find a matching target selector. If I remember right in these snapshots, x y and z coordinates in selectors are now doubles.. or maybe floats?.., so I'm sure even if you are 0.99 blocks from the armor stand, it wont find you.
Wow... that did it Carpenter. It works exactly as intended now. Thanks so much!
So what does the ".." mean? Does that change the variable type or something?Edit: Just found out that selectors now support ranges.
How would I detect if a block is not for example air?
Putting the CENDENT back in transcendent!
HEEELP ME PLS! how can i use the: /execute if score
So true. In 1.12.2 I was good at command blocks. Now? I can't even do /testfor.
Minecraft Discord Server: https://discord.gg/FSfPgQ7
*Skilled at 1.12 command blocks
*Semi-skilled at 1.13 command blocks
*Good enough at redstone
*Average at building
*Legendary at giving up on a build or project because I forgot a command or just lose inspiration
I'll just wait for MrGarretto to make a converter. Problem is, I'm working on a command mod pack so everything's breaking in 1.13 and that's bad for the whole staff and team. No one asked for these changes, Mojang.
My Name Is Bhexion and I make datapacks.
Find me on PlanetMinecraft and Youtube.