Run these from an operator’s chat, a command block, or a function file. Execute is simplified here — chain the rows in the order you want them to run.

How to Use the Execute Command Generator

  1. Open the Execute tab (it loads by default). The builder starts with a single as <selector> row.
  2. Pick a subcommand from each row’s dropdown – as, at, positioned, rotated, facing, align, anchored, in, if block, if entity, if score, unless entity, or store result score – and fill in its argument box.
  3. Click + Add subcommand row to chain another subcommand after it; the generator keeps every row in the order you added them.
  4. Type the final command in the Run box – this is whatever runs once the whole chain resolves.
  5. Copy the single generated /execute line into a command block, function file, or an operator’s chat.

Command Syntax Reference

/execute <subcommand> [<subcommand> ...] run <command>

/execute doesn’t run anything by itself – it’s a chain of modifiers that changes the executor, position, rotation, dimension, or a pass/fail condition for the single command at the end. Each subcommand narrows or redirects context for the next one in the chain, and the chain always terminates in run <command>. A few of the subcommands this generator exposes:

  • as <selector> – changes who the rest of the chain runs as (changes @s), without moving the execution position.
  • at <selector> – changes where the chain runs at (position, rotation, and dimension), without changing who it runs as.
  • positioned <x y z> / rotated <yaw pitch> / facing <x y z> – override just the position or rotation directly, independent of any entity.
  • align <axes> – snaps the current position to the integer grid on the given axes (e.g. xyz) before the next subcommand runs.
  • anchored eyes|feet – chooses whether position/rotation checks use the entity’s eye height or feet.
  • in <dimension> – moves execution into another dimension, e.g. minecraft:the_nether.
  • if block <pos> <block> / if entity <selector> / unless entity <selector> – a conditional test; if it fails, the whole command aborts and nothing after it (including run) executes.
  • if score <target> <objective> matches <range> – tests a scoreboard value against a number or range like 1.. or 5..10 before continuing.
  • store result score <target> <objective> – captures the numeric result (or success/fail as 1/0) of the final command into a scoreboard value instead of just running it for effect.

Frequently Asked Questions

What’s the difference between execute as and execute at?

as <selector> only changes who the command runs as (so @s refers to a different entity afterward) – it does not move the execution position. at <selector> only changes where the command runs (position, rotation, and dimension are copied from the target) – it does not change who the command runs as. A very common pattern is chaining both together, as @e[type=cow] at @s run ..., to run a command as each cow and at that cow’s exact location.

What happens if an if or unless condition fails partway through the chain?

The entire /execute command aborts immediately – every subcommand still to come, including the final run, is skipped. This is what makes if/unless useful as a gate: e.g. execute if score @s obj matches 1.. run say positive only says anything when the score condition is true. You can chain multiple if/unless subcommands to require several conditions to all be true at once.

How does store result score differ from just running the command directly?

Without store, the final command just executes for its normal effect. With store result score <target> <objective> inserted before run, the numeric result the command would have returned (or 1 for success / 0 for failure on commands that don’t return a number) is written into that scoreboard value instead – useful for capturing things like a block count, a raycast distance, or a data query’s value for later logic. store success (not built into this generator’s row list, but valid syntax) stores only whether the command succeeded, ignoring the actual result number.

Can I chain more than one if/unless or more than one as/at in the same command?

Yes – there’s no hard limit on how many subcommands you chain, and the generator lets you add as many rows as you want. Multiple if/unless subcommands all have to pass (they’re implicitly ANDed). Multiple as/at subcommands are applied in order, so as @e at @s as @p would first branch per-entity, move to each one’s position, then re-target the nearest player while keeping that position – order matters.

Does the order of subcommands in the chain matter?

Yes, strongly. Each subcommand modifies the execution context handed to the next one, so positioned ~ ~1 ~ align xyz gives a different result than align xyz positioned ~ ~1 ~. As a rule of thumb, put as/at (who/where) early, position and rotation tweaks next, and if/unless conditions wherever they logically need the context established by the subcommands before them.

Related Tools