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:
/execute <selector> <x> <y> <z> <command> /execute <selector> <x> <y> <z> detect <x> <y> <z> <block> <data> <command>
This will be refactored as follows:
/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 thingsNow...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.
Conditionals
/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 <selector> <objective> <cmp> <selector2> <objective2> ...
The conditional commands are the new and improved /execute ... detect command syntax. For example, this command, which kills arrows that hit tripwire:
/execute @e[type=arrow] ~ ~ ~ detect ~ ~ ~ tripwire -1 kill @s
is rewritten as this:
/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>
= /tellraw
= /title
= Books
= Signs
= Advancements
). Defaults to "false".
1
Show us the commands you're using and someone will be much more able/willing to help.
1
You could still use a health_boost effect. Instead of setting it when a player is between the required levels, make it a two part check. First tag the player if they are under the effects, then give the effect for 1 million seconds if they do not already have it:
scoreboard players tag @a[tag=boost1] remove boost1
scoreboard players tag @a[tag=boost2] remove boost2
scoreboard players tag @a add boost1 {ActiveEffects:[{Id:21b,Amplifier:0b}]}
scoreboard players tag @a add boost2 {ActiveEffects:[{Id:21b,Amplifier:1b}]}
effect @a[lm=10,l=19,tag=!boost1] minecraft:health_boost 1000000 0
effect @a[lm=20,l=29,tag=!boost2] minecraft:health_boost 1000000 1
This is perfectly expandable as well. Just repeat each one of the three types of commands for each new level.
Edit: Whoops, unbalanced curly brackets.
1
This should do it:
/summon minecraft:item ~ ~ ~ {Item:{id:"minecraft:spawn_egg",Count:1b,Damage:0s,tag:{EntityTag:{id:"minecraft:bat",Tags:["oregensum"]}}}}
1
Like many administrative commands, the setidletimeout command cannot be used in command blocks.
https://minecraft.gamepedia.com/Commands#setidletimeout
1
You could use fill replace executed from the dragon_egg item the dragon will drop to replace any nearby dragon_egg blocks with air:
scoreboard players tag @e[type=minecraft:item,tag=!dragon_egg] add dragon_egg {Item:{id:"minecraft:dragon_egg"}}
execute @e[tag=dragon_egg] ~ ~ ~ fill ~15 ~15 ~15 ~-15 ~-15 ~-15 minecraft:air 0 replace minecraft:dragon_egg
1
"Facing: The direction the painting/item frame faces: 0 is south, 1 is west, 2 is north, and 3 is east."
So use this command:
/summon minecraft:item_frame -1048 238 -274 {Invulnerable:1b,Facing:3b}
1
No, change the command to this:
execute @a[score_walk_min=10] ~ ~ ~ detect ~ ~-0.5 ~ minecraft.wooden_slab 2 playsound step.metalgrate @a[r=25]
scoreboard players reset @a[score_walk_min=10] walk
You may need to play with the value to get the desired effect.
1
Why not just use @a[score_steps_min=10] in the playsound command, then reset it right after?
scoreboard players reset @a[score_steps_min=10] steps
1
No, you misunderstood. You are using the entity "Tags" list on an item.. That is not correct. Plus, when you use the give command, the given NBT data is placed inside the {Item:{tag:{here}}} compound. When summoning any entity you can assign "Tags", they are located in the top of the NBT data compound, so placing them inside the Item->tag compound does nothing. Especially because it isn't an entity.
There is a thing called custom item NBT tags. They're actual NBT tags that only work for items, they are not in a list like entity "Tags", they are not strings, they are bools that you can name and define yourself. For example: {Item:{tag:{custom:1b}}}
You can summon an item as an item tile entity. "minecraft:item" is an entity. If you use this command you can summon an item with both custom item NBT tags and entity "Tags":
summon minecraft:item ~ ~ ~ {Item:{id:"minecraft:dirt",Count:1,tag:{notdirt:1b}},Tags:["itReallyIsDirtDoe"]}
Now while it is an item tile entity that no one has picked up, you can target it using "@e[tag=itReallyIsDirtDoe]".
Once someone picks it up you can test that it is in their inventory with this:
testfor @a {Inventory:[{tag:{notdirt:1b}}]}
Just so you know, custom item tags are not really documented on the wiki.
If you are referring to the tag->BlockEntityTag compound, then again, you are mistaken. These are used for real tags, not custom, that should be applied when the item is placed. Like the command in a command block or inventory of a chest. You cannot put "custom:1b" tags here, nor entity "Tags", for that matter.
1
This proves nothing. It is still an entity that has unique tags. That does not mean you can summon it. You used to have to give the skull an empty direction tag, but later I remember reading in one of the changelogs something along the lines of "wither skulls can no longer be summoned unnaturally". I could be confusing this with the change they made to summoning fireballs when you had to actually fill each record of direction with doubles, or perhaps I'm just thinking of 1.8-pre1 when summoning fireballs and wither skulls was broken entirely.
Either way, I also found this which might support my initial statement: