Chapter 13 — Entity Tags and Choosing the Right Tool

What You’ll Build

Over the last two chapters you met two ways to remember things: scoreboards (Chapter 11), which track numbers, and command storage (Chapter 12), which holds any shape of data you like. This chapter adds the third and simplest tool in the set, the entity tag, and then steps back to answer the question all three chapters have been building toward: given a job, which tool should I reach for?

By the end you’ll be able to slap a plain on/off label onto any entity with /tag, pick out every entity wearing that label with @e[tag=...] (the tag= filter Chapter 3 promised you’d learn here), and tell at a glance whether a task wants a scoreboard, command storage, or an entity tag. To prove it, you’ll add three tiny systems to your mypack pack: a team marker built from tags, a countdown timer built from a scoreboard, and a quest tracker built from command storage, one system per tool, so the differences are impossible to miss.

This chapter extends the pack you started in Chapter 9 (your mypack pack) and uses the test world you’ve used since Chapter 1. It assumes the selector skills from Chapter 3, the scoreboard skills from Chapter 11, and the command-storage skills from Chapter 12.

What an entity tag is

An entity tag is the simplest tracker in the whole game: a short word you stick onto a specific entity that is either there or not there. There’s no number and no structure, just a label that’s present or absent, like a sticker on a box. The game stores these as scoreboard tags: a simple list of single-word strings stored directly in the entity, with a maximum of 1024 tags per entity. Each entity carries its own little list of stickers, and you can ask “does this entity have the red_team sticker?” and get back a plain yes or no.

That’s the whole idea. A scoreboard answers how many? Command storage answers what’s the data? An entity tag answers a simpler question: is this flag on or off for this particular entity? A flag is just programmer-speak for an on/off marker: the entity either has the tag or it doesn’t.

Because a tag lives on the entity itself, it travels with that entity. Tag a zombie boss and that one zombie stays boss until something removes the tag or the zombie dies, and you don’t have to keep a separate list of which zombie is the boss. That’s what makes tags so handy for marking this mob, that armor stand, or these few players out of a crowd.

Under the Hood The game’s own name for entity tags is “scoreboard tags,” and they really are stored alongside the scoreboard system, but don’t let the name fool you. They have nothing to do with the numbers a scoreboard tracks; they’re a separate on/off list. The book calls them entity tags because that describes what they are: labels attached to entities. (Skippable.)

Adding and removing tags with /tag

You manage entity tags with the /tag command. It has exactly three jobs: add a label, remove a label, and list the labels an entity currently has. Here is the syntax:

tag <targets> add <name>
tag <targets> remove <name>
tag <targets> list

• tag <targets> add <name>: adds the tag <name> to every entity matched by <targets>.
• tag <targets> remove <name>: removes the tag <name> from every matched entity.
• tag <targets> list: lists all tags currently on the matched entities.

The <targets> part is a target selector (the same selectors you learned in Chapter 3), so you can tag one entity, a filtered group, or yourself. The <name> is the label: a single word, and (like scoreboard objective names) case-sensitive, so Boss and boss are two different tags.

Let’s give your pack its first tagging function. Inside a .mcfunction file there’s no leading /, just as you’ve done since Chapter 1. This one marks every nearby zombie as belonging to the red team:

data/mypack/function/mark_red_team.mcfunction

# Mark every zombie within 10 blocks as the red team
tag @e[type=minecraft:zombie,distance=..10] add red_team
say Red team assembled!

Run it from chat the way you’ve run your other functions (/function mypack:mark_red_team) after summoning a few zombies near yourself. Every zombie in range now carries the red_team sticker. Nothing looks different yet; the tag is invisible. To prove it’s there, point /tag ... list at one zombie, or (better) use the tag in a selector, which is the next section.

If you ever want to clear the label, the mirror-image function removes it from the same group:

data/mypack/function/clear_red_team.mcfunction

# Take the red team tag back off every nearby zombie
tag @e[type=minecraft:zombie,distance=..10] remove red_team
say Red team disbanded.

What Went Wrong? Adding a tag an entity already has, or removing one it doesn’t have, isn’t an error you need to worry about: the command simply reports that nothing changed for that entity. Tags are safe to “add again”: an entity can hold a given tag only once, so re-adding red_team to an already-red zombie just leaves it red.

Using tags in selectors: @e[tag=...]

Back in Chapter 3 you saw the tag= filter listed but were told its full story would wait for this chapter. Here it is. You filter a selector by tag with the tag= argument, which has four forms:

[tag=<string>]    Include only targets with the specified tag.
[tag=!<string>]   Exclude any targets with the specified tag.
[tag=]            Include only targets with exactly zero tags.
[tag=!]           Include only targets that have at least one tag.

So @e[tag=red_team] means “every entity carrying the red_team sticker,” and @e[tag=!red_team] means “every entity not carrying it.” The two empty forms are occasionally handy: @e[tag=] finds entities with no tags at all, and @e[tag=!] finds entities that have at least one tag of any kind.

You can stack tag filters. Multiple tag arguments are allowed, and all arguments must be fulfilled for an entity to be selected: they’re combined with AND, exactly like the other filters from Chapter 3. So @e[tag=red_team,tag=boss] matches only entities that have both the red_team and the boss stickers, while @e[tag=red_team,tag=!stunned] matches red-team entities that are not stunned.

Now that you can select tagged entities, you can do something visible with the team you marked. Add a function that makes every red-team zombie glow:

data/mypack/function/red_team_glow.mcfunction

# Make every red team member glow for 30 seconds
effect give @e[tag=red_team] minecraft:glowing 30 0

Run mypack:mark_red_team to assign the team, then mypack:red_team_glow, and the marked zombies light up with the glowing outline while any un-marked mobs nearby stay dark. That outline is your proof the tag is doing its job.

Figure (to be captured). a cluster of glowing red-team zombies with one ordinary, non-glowing zombie standing just outside the original 10-block range

Try It! Combine tags with everything else from Chapter 3. @e[type=minecraft:zombie,tag=red_team,distance=..20] targets red-team zombies within twenty blocks. Or split your mobs into two teams: tag one group red_team and another blue_team, then write a function that only buffs @e[tag=red_team] and another that only buffs @e[tag=blue_team]. Tags turn one undifferentiated crowd into named groups you can command separately.

Two very different things both called “tag”

Here is the single most important thing to keep straight in this chapter, because the next chapter is going to reuse the word “tag” for something completely different.

Modern Minecraft The word tag means two unrelated things in Minecraft, and tutorials online rarely warn you:

1. Entity tag (this chapter): a runtime label you put on one specific entity with the /tag command, and check with @e[tag=...]. It’s a sticker on a single mob/player/armor stand, added and removed live while the world runs.
2. Registry tag (Chapter 14): a JSON file in your data pack that groups types of things, written with a leading #, like #minecraft:logs standing for “every kind of log block.” It groups whole categories of blocks, items, or entity types, and you can’t change it with a command while playing.

The game itself draws the line: the /tag command is distinct from entity type tags, which are applied to entity types and can’t be changed by commands. When Chapter 14 starts talking about #minecraft:logs, remember it means the second kind, a group of block types in a file, not the on/off sticker you learned here.

Quick mental test: red_team on a particular zombie is an entity tag (one entity, on/off, runtime). #minecraft:logs standing for all log blocks is a registry tag (a category of types, defined in a file). Same word, two worlds.

When an entity tag is the right choice

Reach for an entity tag when the thing you want to remember is a simple yes/no flag that belongs to a specific entity. Signs you want a tag:

• You’re marking entities so a later command can find them again: “the mobs in this arena,” “the armor stand that anchors my machine,” “players who already opened the chest.”
• The answer is genuinely on-or-off. There’s no count to keep and no structured data, just is it marked or not?
• The flag should ride along with the entity. Tag a mob and the mark stays with that mob wherever it wanders, with no separate bookkeeping.

If you catch yourself wanting to store a number on the entity, or a list, or several related values, a tag is the wrong tool. That’s a job for the next two tools, which is exactly what the decision guide is about.

The decision guide: which tool for which job?

You now own all three of Part IV’s tools. Here’s how to choose between them. Ask yourself what shape the information is:

A few rules of thumb the table doesn’t spell out:

• Start with the shape of the data, not the system you know best. Old tutorials lean on scoreboards for everything, even things that aren’t numbers, because scoreboards used to be the only flexible option. In current Java Edition that’s the wrong instinct: if the data isn’t a plain integer, command storage is almost always cleaner.
• A flag is not a number. “Has this player finished the quest?” is on/off, so that’s a tag, not a scoreboard objective set to 0 or 1.
• It’s fine to mix them. A real system often uses all three: tags to mark which entities are in play, a scoreboard for the score, and storage for the settings. The three practice systems below each use just one tool so you can feel the difference, but nothing stops you combining them.

Modern Minecraft If you’ve followed older data-pack guides, you’ve probably seen scoreboards used as a catch-all “variable system,” with fake players standing in for strings and flags. That style still works, but it’s no longer how modern packs are built. The split this book teaches (numbers on scoreboards, structured data in command storage, on/off flags as entity tags) matches how current Java Edition data packs are actually written, and it’ll keep your packs far easier to read.

Practice: three systems, one per tool

You’ll now build all three example systems in mypack. Each one is deliberately small; the point is to see the same idea (“remember something”) solved three different ways.

1. A team marker (entity tags)

You already wrote mark_red_team and red_team_glow above, so the tag-based team marker is essentially done. Round it out with a function that reports who’s on the team. The tag=! form is the easy way to count the other side: anything nearby that isn’t red team.

data/mypack/function/team_report.mcfunction

# Announce the two sides
say Red team members nearby:
tag @e[type=minecraft:zombie,tag=red_team,distance=..20] list
say Everyone NOT on red team gets marked blue:
tag @e[type=minecraft:zombie,tag=!red_team,distance=..20] add blue_team

This is the whole shape of a tag system: add to join a group, tag=/tag=! to select members or non-members, remove to leave. No numbers, no files — just labels.

2. A countdown timer (scoreboards)

A timer is a number that changes over time, so it’s a scoreboard job. From Chapter 11 you know how to create an objective and change a holder’s score; here you’ll store the time on a fake player (a made-up score-holder name that isn’t a real player) called #timer, and show it on the sidebar.

First, a setup function that creates the objective and starts the clock at 10:

data/mypack/function/start_timer.mcfunction

# Create the timer objective (safe to run again; errors are harmless if it exists)
scoreboard objectives add mypack_timer dummy
# Show it on the sidebar
scoreboard objectives setdisplay sidebar mypack_timer
# Start the countdown at 10 on a fake player
scoreboard players set #timer mypack_timer 10
say Timer started at 10.

Then a tick step that subtracts one each time it runs. You met the tick function tag in Chapter 11 (mypack/data/minecraft/tags/function/tick.json), so append this function’s id to that file’s values rather than creating a new tick tag:

data/mypack/function/timer_tick.mcfunction

# Subtract 1 from the timer every time this runs
scoreboard players remove #timer mypack_timer 1

mypack/data/minecraft/tags/function/tick.json

{
  "values": [
    "mypack:kill_on_gold",
    "mypack:timer_tick"
  ]
}

(The mypack:kill_on_gold line was already in your tick tag from Chapter 11; you’re adding mypack:timer_tick beside it, not replacing the file.) Run mypack:start_timer and watch the number on the right side of your screen tick down. This is the scoreboard’s home turf: a whole number you can change, compare with /execute if score (Chapter 11), and display, none of which a tag or storage does as neatly.

Try It! Right now the timer keeps counting past zero into negative numbers. With /execute if score from Chapter 11 you can stop it at zero and fire off an event, a great mini-exercise once you’ve finished this chapter.

3. A quest tracker (command storage)

A quest has structure (a stage name, maybe a count of items collected, maybe a list of objectives), so it’s a command-storage job. From Chapter 12 you know that command storage is a general-purpose, namespaced container identified by a resource location like mypack:quest. Here you’ll start a quest by writing a small structured value into storage:

data/mypack/function/quest_start.mcfunction

# Begin the quest: store a stage name and a starting count
data modify storage mypack:quest stage set value "find_the_key"
data modify storage mypack:quest items_collected set value 0
say Quest started: find the key.

Then a function that advances the quest by reading the data back and moving to the next stage:

data/mypack/function/quest_advance.mcfunction

# Move the quest to its next stage and show the stored data
data modify storage mypack:quest stage set value "open_the_door"
data get storage mypack:quest

Run mypack:quest_start, then mypack:quest_advance, and the data get line prints the whole quest object back to you so you can see the structure you’ve stored. Notice what storage gives you that the other two tools don’t: a named value with a stage string and a number side by side, all under one tidy id, with no entity and no fake-player tricks. That’s exactly the “complex or structured data” row of the decision guide.

Three systems, three tools, one lesson: match the tool to the shape of what you’re remembering: a flag, a number, or structured data.

What Can Go Wrong

• The tag selector matches nothing. Tags are case-sensitive, so @e[tag=Red_Team] will not find entities you tagged red_team. Check the exact spelling and capitalization in your /tag add. Also remember every filter in a selector must hold at once: @e[type=minecraft:zombie,tag=red_team] only matches entities that are both zombies and tagged, so if you tagged a skeleton, that bracket skips it.

• You used a tag where you needed a number (or vice versa). If you find yourself adding tags like score_1, score_2, score_3 to fake a count, stop. That’s a scoreboard’s job. And if you set a scoreboard objective to 1 or 0 just to mean “done / not done,” that’s really a flag, so an entity tag is simpler. When a design feels awkward, re-check it against the decision guide: numbers → scoreboard, structured data → storage, on/off → tag.

• You confused the two kinds of tag. Trying to write @e[tag=#minecraft:logs] won’t work: #minecraft:logs is a registry tag (a group of block types, Chapter 14), not an entity tag (a runtime label, this chapter). The tag= selector argument only reads the on/off labels you add with /tag. Keep the two meanings of “tag” apart and this class of bug disappears.

What You Know Now

You can now add a plain on/off label to any entity with tag <targets> add <name>, take it off with remove, and inspect it with list; select labeled entities with @e[tag=...], its negation tag=!, and the empty tag=/tag=! forms; and stack tag filters knowing they all must hold at once. Just as importantly, you can now choose among Part IV’s three tools: command storage for complex or structured data, a scoreboard for an integer you want to count or display, and an entity tag for a simple on/off flag that rides along on a specific entity. And you can tell an entity tag (a runtime sticker on one entity) apart from a registry tag (a file grouping types of things), the distinction that carries you straight into the next chapter, where the other kind of tag takes center stage.