Updated:
Common causes
- A wrong ID in
@e[type=…] - A range such as
distance=..5that is too small - The target is far from the command block
@sin a command block, where the runner is the block
Narrow it down
/say test
/execute if entity @e[type=minecraft:zombie] run say zombie found
/execute if entity @e[distance=..10] run say nearby entity foundStart loose. When something is found, add type, distance, name and so on one by one.
Arguments to check
- type:
type=zombieandtype=minecraft:zombieboth work;type=Zombiedoes not. - name: quote names with spaces, as in
name="Boss Zombie". - tag: only matches tags added with /tag. Check spelling.
- scores: a player who never had the score set does not match even
scores={money=0}. - limit and sort:
@e[limit=1]picks in arbitrary order on Java. Addsort=nearestfor the closest.
Targets in unloaded areas
Entities in unloaded chunks cannot be selected. On Java, /forceload keeps an area loaded.
Which message is which
| Message | Meaning |
|---|---|
| No entity was found | Java: nothing matches @e, @s and similar |
| No player was found | Java: no player matches @p, @a or a name |
| No targets matched selector | Bedrock: nothing matches |
All three mean "valid syntax, no target". A syntax mistake shows a red error instead; see unknown or incomplete command.
Dead or offline players
Players on the respawn screen are not selected by @p or @e, only by @a. If a minigame skips some players, check whether they were dead. Names of players who are not online are not found either.
Java vs Bedrock
Bedrock uses r and rm instead of distance, and c instead of limit. Java selectors pasted into Bedrock give a syntax error. The converter rewrites them.
Check your command
The Command Error Doctor checks common syntax mistakes in your browser.