Chapter 3 — Target Selectors: Picking Who or What

What You’ll Build

Up to now, almost every command you’ve typed has acted on you, the player running it. But you’ll often want more than “just me.” You’ll want “every zombie near the player,” or “the closest other player,” or “all the armor stands I summoned.” This chapter teaches the tool that lets a command pick its victims without you ever typing a name: the target selector. By the end you’ll know the five selectors you’ll reach for every day (@s, @p, @a, @e, @r) and how to bolt on square-bracket filters to narrow a crowd down to exactly the entities you mean, like @e[type=minecraft:zombie,distance=..10] for “every zombie within ten blocks.” Then you’ll type a short sequence of commands that rounds up nearby mobs, teleports them to you, and slaps an effect on them. Selectors are the single most reused idea in the rest of this book: every command from here on picks its targets this way.

This chapter builds on the chat commands from Chapter 1 and the coordinate ideas from Chapter 2. Everything here is typed straight into the chat box in your test world.

The problem selectors solve

A target selector is a shorthand for picking players or entities in a command without naming them or knowing their hidden ID: you write a short code and the game figures out who matches. You’ve actually already met one: every time you typed @s in Chapters 1–2, that was a selector meaning “myself, the one running this command.” @s is just the simplest member of a small family.

Here’s why this matters. Imagine you want a command to heal every player on the server. You could try to type out everyone’s name, but names change, players join and leave, and a data pack can’t know them ahead of time. A selector sidesteps all of that. You write @a (“all players”) once, and it resolves to whoever happens to be online when the command runs. Selectors turn “I have to know who specifically” into “I describe the kind of target I want, and the game finds them.”

The five selector variables

The first part of a selector is its variable: the @-something that names the broad category of targets. There are five you’ll use constantly. (There’s actually a sixth in Java Edition, covered in the Under the Hood box below.)

• @s — yourself. Selects the entity that the command was executed as, usually you. It picks the executor whether they’re alive or not. If a command wasn’t run as an entity at all (say, from the server console), @s selects nothing. This is the one you’ve been using.
• @p — the nearest player. Selects the nearest player to where the command runs. If two players are tied for closest (exactly the same distance), the one who most recently joined the server wins.
• @a — all players. Selects every online player, alive or dead.
• @e — all entities. Selects all alive entities in loaded chunks, plus all alive online players. “Entity” here means everything that lives in the world: mobs, dropped items, armor stands, arrows, you name it, not just players.
• @r — a random player. Selects a random online player.

A quick but important caution about @r: in Java Edition it picks a random player, not a random mob. If you want a random entity (say, one random zombie), write @e[sort=random,limit=1] instead. You’ll understand exactly what that means by the end of this chapter.

You can type any of these into chat on its own. Here are a few one-liners:

/say Hello from @s /effect give @a minecraft:glowing 10 0 /kill @e[type=minecraft:arrow]

The first makes you say hello. The second gives every online player ten seconds of Glowing. The third, using a filter you’ll meet shortly, removes every stray arrow in loaded chunks. (We’ll come back to effect give and how its arguments work when we build the practice function.)

Under the Hood Java Edition actually has six selector variables, not five. The sixth is @n, the nearest alive entity (any entity, not just a player, unlike @p). It works just like the others and you’re free to use it, but this book leans on the five above because they cover almost everything a beginner needs, and @n is easy to mimic with @e[limit=1,sort=nearest] once you’ve learned filters. Skip this box if it’s more than you want right now.

Modern Minecraft If you’ve watched older tutorials or Bedrock (phone/console) videos, you may have seen extra selectors like @c, @v, or @initiator. Those are specific to Bedrock Edition or the Education Edition. They don’t exist in the Java Edition this book teaches. Stick to the Java five (plus @n) and you’ll never be surprised.

Filtering: narrowing the crowd

A bare @e is a fire hose: it grabs everything. The real power of selectors is filter arguments (the wiki calls them “target selector arguments”): extra conditions you list in square brackets to keep only the targets that match. The shape is always the same: the variable, then square brackets holding argument=value pairs separated by commas:

@e[type=minecraft:zombie,distance=..10]

Read that as: “all entities, but only the ones that are zombies and within ten blocks.” A few rules worth burning in now:

• Multiple filters are AND-ed together. Every pair must be true for a target to make the cut. The example above keeps something only if it’s both a zombie and close enough.
• Filters change how @p, @r, and @s behave, too. With @a or @e, filters narrow the full list. With @p or @r, the nearest/random target is chosen from the filtered group. With @s, you’re kept only if you would land in that group, so @s[type=minecraft:zombie] selects nothing when you run it (you’re a player, not a zombie).
• Case matters. In Java Edition, argument names and values are case-sensitive. type=Zombie won’t match minecraft:zombie.
• No space before the first bracket. You can put spaces around the equals signs and commas if you like, but not between the variable and its opening [.

Let’s walk through the filters you’ll use most.

type= — filter by entity type

The type= argument keeps only entities of a given kind, named by their identifier (the namespace:path name you’ll meet properly in Chapter 8). The minecraft: namespace can be left off, so type=zombie and type=minecraft:zombie mean the same thing.

@e[type=minecraft:zombie]
@e[type=creeper]

Put a ! in front of the value to mean “everything except this type”:

@e[type=!minecraft:player]

That selects every entity that isn’t a player, handy for “all the mobs and items, but leave the people alone.” Two rules to be strict about:

• A plain type=<something> (no !) can appear only once, and you can’t mix it with a ! exclusion. So @e[type=creeper,type=pig] is an invalid selector (an entity can’t be two types at once anyway). If you want creepers or pigs, that’s what entity tags are for: previewed below under tag=, taught fully in Chapter 13.
• You can stack several exclusions: @e[type=!creeper,type=!pig] means “everything except creepers and pigs.”
• You can’t use type= with @a, @p, or @r in Java Edition, because those already mean “players,” and a type filter would either be redundant or contradictory.

distance= — filter by range

The distance= argument keeps only targets within (or beyond) a distance of the point the command runs from. This is where you meet range syntax, a little notation Minecraft uses all over the place: two dots .. mean “a range,” and which side the number is on says whether it’s a maximum or a minimum:

@e[distance=..10]      all entities LESS than (up to) ten blocks away
@e[distance=10..]      all entities MORE than ten blocks away
@e[distance=8..16]     all entities between eight and sixteen blocks away (inclusive)
@e[distance=10]        all entities EXACTLY ten blocks away

So ..10 is “no more than 10,” 10.. is “at least 10,” and 8..16 is the band in between. Distances are measured to the target’s feet, and only positive (unsigned) values are allowed; there’s no such thing as a negative distance. Distance also limits the search to the dimension the command runs in.

You’ll use distance=..N constantly: “do something to everything near here” is one of the most common things a data pack ever asks for.

name= — filter by name

The name= argument keeps only targets whose name matches exactly. If the name has spaces in it, wrap it in quotes.

@e[name=Rover]
@e[name="Sir Barksalot"]
@a[name=!Steve]

The last one, with !, means “every player except the one named Steve.” Names are how you single out a specific mob you’ve named with a name tag, or a particular player. But remember names can change and aren’t unique, so they’re a blunt tool compared to the next one.

tag= — filter by a label you put on entities

The tag= argument keeps only entities carrying a particular scoreboard tag, a simple text label you can stick on any entity to mark it. You haven’t learned how to add tags yet (that’s the /tag command, coming in Chapter 13), but you’ll see tag= in selectors everywhere, so meet it now:

@e[tag=is_boss]
@e[tag=!frozen]

The first selects every entity wearing the is_boss label; the second selects everything without the frozen label. Tags are the cleanest way to mark “these specific entities are special”: for example, tagging the three zombies your pack summoned so a later command can find just those three and ignore every other zombie in the world. We’ll build real tag-based systems in Chapter 13. For now, just know that tag= reads a label, and ! flips it.

limit= and sort= — how many, and which ones

By default, @a and @e grab every match. Often you want only one, or only the closest few. Two arguments control that together:

• limit=<number> caps how many targets come back.
• sort=<order> decides which ones survive the cap, by setting the order before the limit applies. The four orders are:
  • sort=nearest: closest first (this is the default for @p)
  • sort=furthest: farthest first
  • sort=random: shuffled (this is the default for @r)
  • sort=arbitrary: no sorting; often returns the oldest entities first, but no order is promised (this is the default for @e and @a)

Examples:

@a[limit=3,sort=nearest]    the nearest three players (same as @p[limit=3])
@a[limit=4,sort=furthest]   the farthest four players
@a[limit=2,sort=random]     two players chosen at random (same as @r[limit=2])

Notice the last two lines of each pair: @p is really just “@a with limit 1, sorted nearest,” and @r is “@a with limit 1, sorted random.” That’s also the trick from earlier: @e[sort=random, limit=1] is how you grab one random entity (rather than a random player, which is what @r gives you).

nbt= — a quick preview

The nbt= argument filters by an entity’s NBT data, the raw saved data a mob or item carries internally (its health, whether a sheep is sheared, what color it is, and so on). You’ll learn what NBT actually is in Chapter 12; for now just know nbt= exists and what it looks like:

@a[nbt={OnGround:true}]

That selects all players standing on the ground. One warning to be explicit about: reading NBT is a heavy process for the CPU, so use nbt= sparingly. In fact, the wiki points out that @e[nbt={Tags:[a,b]}] does the same job as @e[tag=a,tag=b], and the tag= version is both simpler and lighter on the game. So reach for tag= first; save nbt= for things only NBT can express.

Modern Minecraft Tutorials made for Bedrock Edition use different argument names: r= and rm= for distance, c= for limit, m= for game mode, and so on. The Java Edition this book teaches uses the longer, readable names (distance=, limit=, sort=) with the .. range syntax. If a guide tells you to write @e[r=10], that’s Bedrock; the Java version is @e[distance=..10].

Try It! The selector page lists more filters than we’ve covered: by experience level=, by gamemode=, by facing direction (x_rotation= / y_rotation=), by a cuboid volume (dx= / dy= / dz=), and more. You don’t need them yet, but if you’re curious, every one follows the same argument=value shape and the same .. range and ! rules you just learned. Two more (scores= and predicate=) wait on ideas from later chapters (scoreboards in Chapter 11, predicates in Chapter 18).

Combining filters

Because filters AND together, you build precise targets by stacking them. This is the everyday craft of data packs. Read each of these as a sentence:

@e[type=minecraft:zombie,distance=..10]

“Every zombie within ten blocks.” (The chapter’s headline example.)

@e[type=minecraft:armor_stand,tag=marker]

“Every armor stand wearing the marker label.”

@a[distance=..16,limit=1,sort=nearest]

“The single nearest player within sixteen blocks.”

@e[type=!minecraft:player,distance=..5]

“Everything that isn’t a player, within five blocks of here.”

The order you write the filters in doesn’t matter. [type=...,distance=...] and [distance=...,type=...] mean the same thing, because all the conditions must be true together.

Walkthrough: rounding up nearby zombies

Time to put selectors to work. You’ll type a short sequence of commands that:

1. finds every zombie within ten blocks of you,
2. teleports those zombies to you, and
3. gives them Glowing so you can see who got rounded up.

This combines a filtered selector (@e[type=...,distance=...]) with two commands you’ll meet here: /teleport and /effect give.

First, the two commands:

• /teleport <targets> <destination> moves the targeted entities to a destination, which can be another entity. So /teleport @e[...] @s means “teleport those entities to me.” (/teleport is the full name of the /tp command you saw in Chapter 1; they’re the same command.)
• /effect give <targets> <effect> [<seconds>] [<amplifier>] applies a status effect. The seconds and amplifier are optional; amplifier is the level minus one, so amplifier 0 is level I. If you leave seconds off it defaults to 30.

In your test world, summon a few zombies near you (you learned /summon in Chapter 1), then type these three commands in order, pressing Enter after each:

/teleport @e[type=minecraft:zombie,distance=..10] @s /effect give @e[type=minecraft:zombie,distance=..10] minecraft:glowing 15 0 /say Rounded up the nearby zombies!

The first teleports every zombie within ten blocks to you; the second gives those same zombies Glowing for fifteen seconds so you can spot them; the third announces what happened. A few things to notice:

• The selector is identical on both lines. Each command re-runs the selector fresh, so both the teleport and the effect act on the same group: zombies that were within ten blocks. (After the teleport they’re standing on top of you, but the second line’s distance=..10 still includes them, since they’re at distance zero.)
• @s is the destination. Because you’re typing these in chat, @s is you, so the zombies teleport to you.

The nearby zombies should snap to your position and start glowing. Any zombie farther than ten blocks away is left alone: that’s your distance=..10 filter doing its job.

Figure (to be captured). the player surrounded by glowing zombies right after running the round-up commands, with one un-glowing zombie visible in the distance that was outside the 10-block range

Under the Hood @s meaning “you” is doing quiet work here. A selector like @s only means “the player” if the command was run as that player, which it is when you type it in chat yourself, because you are the executor. In the next chapter you’ll learn the /execute command, which lets you deliberately change who @s is and where a command runs from: for example, “run this once as each zombie, at that zombie’s feet.” That’s how you’ll do per-entity work. For now, typing the command yourself keeps @s simple: it’s you.

Practice

Re-run the round-up commands and experiment with selectors:

1. Wider net. Change both distance=..10 filters to distance=..20 and re-run. More zombies get caught. Then try distance=5..20: now zombies closer than five blocks are skipped. Predict who gets rounded up before you run it, then check.

2. Round up something else. Type a command with the opposite mood: give every cow within fifteen blocks the Speed effect so they bolt. Use @e[type=minecraft:cow,distance=..15] and effect give ... minecraft:speed 10 2 (amplifier 2 is Speed III):

   /effect give @e[type=minecraft:cow,distance=..15] minecraft:speed 10 2 /say The cows have had too much coffee.

3. Only the closest. Type a command that teleports only the single nearest zombie to you, not all of them. Hint: add limit=1,sort=nearest to the selector, @e[type=minecraft:zombie,distance=..10,limit=1,sort=nearest].

4. Spare the named ones. Suppose some mobs are pets you’ve named. Add name=! filters or, better, plan ahead for Chapter 13 by imagining a tag=!pet filter that would skip any entity you’ve labelled pet. (You can’t add the tag yet, that’s Chapter 13, but you can already read it in a selector.)

What Can Go Wrong

What Went Wrong? “My selector grabbed nothing.” The most common cause is the AND rule: every filter has to be true at once. If you wrote @e[type=minecraft:zombie,distance=..2] and the nearest zombie is three blocks away, you get zero targets, not because the type is wrong, but because nothing satisfies both conditions. Loosen one filter at a time to find which one is excluding everyone.

What Went Wrong? “I got an error about my type argument.” Check three things. First, case: Java is case-sensitive, so it’s minecraft:zombie, never minecraft:Zombie. Second, you can only have one plain type= (no !) per selector; @e[type=zombie,type=pig] is invalid. Third, you can’t use type= with @a, @p, or @r at all, because those already mean “players”; use @e when you want to filter by entity type.

What Went Wrong? “Nothing happened, and there’s no error.” If a selector matches nobody, the command simply does nothing, quietly. That’s not a crash; it’s an empty target list. Run a harmless test like /say @e[type=minecraft:zombie,distance=..10] first: if it echoes the matched entities, your selector works and the problem is elsewhere; if it shows an empty result, your filter is too tight or the entities aren’t where you think.

What You Know Now

You can pick targets for any command without naming them. You know the five everyday selector variables: @s (yourself), @p (nearest player), @a (all players), @e (all entities), and @r (a random player), and that @e reaches everything in loaded chunks. You can attach filter arguments in square brackets and combine them, knowing they all have to be true at once: type= for entity kind (with ! to exclude, once-only for the plain form, and off-limits to @a/@p/@r), distance= with .. range syntax (..10, 10.., 8..16), name= for an exact name, tag= for a label (a preview of Chapter 13), and limit= with sort= (nearest/furthest/random/ arbitrary) to control how many and which. You’ve seen nbt= exists but is heavy and best avoided until Chapter 12. And you’ve typed a round-up sequence that filters, teleports, and buffs a precise group of entities: the pattern behind nearly every command you’ll write from here on.

Next chapter unlocks the command that makes selectors truly programmable: /execute, which lets you change who a command runs as and where it runs from, so you can do per-entity work like “as every zombie, at its position, strike lightning.”