Learn Minecraft Commands – Summoning and Tagging Entities with Entity Data (Episode 8)

Hello and welcome back to my series on learning commands in Minecraft. My name is slicedlime and today we’re going to learn how to summon entities with properties, talk about tagging and start looking at entity data. Last time we got into selecting entities, and as we talk about doing things with entities

– especially summoning entities, one natural question is “how do I select this particular entity again?” That is where our next useful command and concept is going to come in. The command is the tag command.

A tag is like a marker or – well, tag, that you can put onto entities to then be able to select them later. /help tag shows us the syntax – targets, which as we’ve learned last time can be a selector – and then add, remove or list.

This is reasonably straightforward – let’s add a tag to myself for instance – tag slicedlime add lime The lime part here is our tag – this can be anything you want, there’s no need to pre-define it in any way – as long as it is one “word”, that is – doesn’t contain spaces.

So ok, added tag ‘lime’ to slicedlime. Obviously, we can use the tag command to remove it again, and the final mode of the tag command will list all my tags – which in this case is only the lime one we just added.

Tags are there only for us to use from commands – the game doesn’t add any tags by itself. There are also no limits – we can keep adding as many tags as we want. So what are they good for?

Once we’ve added tags to an entity, we can find that entity again by using the tag selector argument. Let’s try it! /say @e[tag=lime] That selects me! Note how I didn’t use @a here – we’re selecting entities, not only players – and still the

Result is only myself, because I’m the only entity in this world with the lime tag. There are no restrictions for how many tags we can make, and there are no restrictions for how many entities can be tagged with a certain tag.

Let’s add a tag for piggo – /tag and we could use tab completion here but let’s use the selectors we learned last time: @e[type=pig,limit=1,sort=nearest] add piggo. Now we have a handle on piggo – if we want piggo in particular, we can now do /say @e[tag=piggo] to find him.

Of course we can use that to add more tags too – tagception! /tag @e[tag=piggo] add cutie More things can be cute, of course, so let’s take one of the village cats here! /tag @e[type=cat,sort=nearest,limit=1] add cutie Now we have two things tagged cutie, and we can target both of them at once. /say @e[tag=cutie].

Of course we can also combine that with other selector arguments to refine the search, so for instance we can do /say @e[tag=cutie,type=cat] The tag selector argument is also different to some of the other ones we’ve learned in that it can be repeated.

If we wanted, we could do /say @e[tag=cutie,tag=piggo] to find only the entities with both the piggo and the cutie tags. And remember the “not” argument we used for types in the previous epsode? That works for tags as well – so we could find one of the other cats by using @e[type=cat,tag=!cutie,limit=1]

For instance – or even combine tag arguments with inverted tag arguments, like @e[tag=cutie,tag=!piggo] to find a cutie which is not piggo. This far we’ve only tagged things that already exist… but let’s say we wanted to summon

An entity, and make sure we tag that one to be able to select it later on – that seems like a very useful thing to be able to do! To be able to do that, we first need to expand our knowledge of how to summon things.

Before I get into that, please take a moment to add a ‘like’ tag to this video. Believe it or not that actually does help out with the YouTube algorithm, so I would really appreciate it. Anyway, summoning things – we tried that a few episodes ago; remember the summon command.

/help summon shows us the syntax – summon followed by an entity type and a position. There’s a sneaky hidden thing here though – if we type in a command – summon cat ~ ~ ~ to summon a cat here, we now get a new argument in the tooltip that didn’t show up before!

Nbt! As usual the brackets indicate that it’s an optional argument, which we kind of knew since we used the command without it before. We saw NBT before in connection to block enitity data and discussed how it worked.

It is very similar for entities – entity data is specified in curcly braces in a JSON-like syntax. Don’t worry if you don’t know what that means – we’ll go through it step by step. Nearly all properties of an entity are stored in its entity data.

This means the data of entities is usually very large, but also that we have nearly limitless potential for making changes to the inner workings! The way this data is specified is in pairs of a field name followed by a colon and then its value.

Depending on the field in question, the value can be a number, a string, a list of things or even an “object” which means another set of curly braces with its own set of fields – it gets complicated very quickly! Let’s take a simple example to begin with.

All mobs have a field called NoAI. It is what is known as a boolean value – either true or false, on or off – but stored as a number, with a value of 1 for on and 0 for off.

That means that by turning the NoAI field ON we can turn the AI for the mob OFF. Let’s try it! /summon wolf ~ ~ ~ {NoAI:1} – make sure to get the capitalization of the data fields right, the naming is case sensitive and as opposed to other things we’ve gone through

This far, there’s no consistent scheme that runs through the entire game. You’ll need to either look up the field names on the mineraft wiki or simply learn the names of the most useful ones. Anyway, here’s doggo. Doggo doesn’t have a brain. Not being able to think in Minecraft has some pretty far-reaching consequences.

For instance, gravity is just an imaginary construct here – if you don’t believe in it, it doesn’t exist – doggo can fly. Things that aren’t related to its AI still work though – we could tag him, select him

With selectors, teleport him, even punch and hurt him or kill him with the kill command. Let’s not do that though, doggo is a good boy even if he doesn’t have a brain. I mentioned that the minecraft wiki is a good source to learn about these fields, so how would this look?

Let’s go find the data for doggo and start learning how to read this information. In the Wolf article, we can find “Data values” and as a sub-section to that: Entity data. It only has one field – Collar color. What?

That is because most of the fields are common with other things – so all these sections that are hidden contain those fields. Like I mentioned, the NoAI field exists for all mobs, so let’s expand the one that says “Tags common to all mobs”.

And here sadly we need to take a break to avoid some confusion. We spent a good while talking about tags – why does this option say “Tags” common to all mobs? We said the game didn’t have any built-in tags! That is because there are multiple things in Minecraft technology called tags.

The ones we talked about are called scoreboard tags for a bunch of historical reasons that don’t make much sense anymore. The ‘tags’ mentioned on the wiki are NBTs – named binary tags – in this context a tag is simply the name of a field in the NBT format. So here, tag means field.

It doesn’t stop here I’m afraid – there yet another thing that is also called tags, and that is also very common to use when working with commands – we’ll get into those later on. For now, if we’re talking about tags in game with the tag command or the tag selector,

It’s safe to assume we’re talking about scoreboard tags. If you see tags mentioned in connection to fields in entity data, it’s another name for a data field. At least almost always. Probably. Anyway we were supposed to be looking up this NoAI field – or tag, as the wiki calls it.

Expanding this list of ‘Tags common to all mobs’ shows us a huge list of things. It’s in alphabetical order though, so we can scroll down to find the one we want. Let’s dissect what we’re looking at here. There’s a red icon with a B, a bold field name and then a description.

NoAI – 1 or 0 (true or false) – Setting to true disables the mob’s AI. The mob does not and cannot move, to the extent of not falling when normally able. Which matches exactly what we just learned about the field! Very useful. That leaves only the red B marker.

That is the type of the field – in this case a byte. There are 12 different field types in the game. No need to learn them all now, but let’s look at the number ones. There are 4 ones that store integers – that is, whole numbers.

The one used for the NoAI field is the smallest one – the byte. A byte stores a value between -128 and +127. The other three store increasing amounts of possible values – a purple S marks a short for -32,768 to +32,767.

A blue I marks an int for roghly plus or minus 2 billion and a cyan L is for long, which ranges between negative and positive 9 quintillion. That’s probably overkill for most things though. We’ll go through the other types as we encounter them. Anyway, we’ve learned our first entity data field!

NoAI is often very useful if you want to experiment with a mob without having it run away from you. We can get to know all the entity data of an entity just like we could get to know all the block entity data of a block.

Like we learned a few episodes ago, aiming at a block, holding down F3 and pressing I will give us a full dump of the data for a block in a setblock format. Doing the same while aiming at an entity will instead give us a summon command with the entire entity data.

We can paste this into a command block to re-create the same entity again, or paste it into a text editor to examine it. Fair warning though: there is quite a lot of data even for simple entities.

So now that we’ve learned to summon mobs without AI, we could of course also use that to tag the entity with the tag command – we summon it with NoAI and then use tab completion or a selector to find it.

That’s rather inelegant and error prone though – what if there’s already another entity around of that type or we want to summon more than one entity at once? There’s another data field that solves all of these problems for us.

It’s the Tags field, which lets us set tags on the entity directly as we summon it, which means we don’t need to find it afterwards to get the tag on. This field is available for all entity types, so to find it on the wiki we’ll need to expand

The ‘Tags common to all entities’ section. This is an icon we haven’t seen before – an orange one with a symbol that looks like a bullet point list. That is the symbol for a list field. ‘List of scoreboard tags of this entity’ matches what we’re looking for here.

In entity data, a list field is written as square brackets containing the values. In this case, each tag is a string, which is written inside quotation marks. In some cases, you can also leave out the quotation marks, but it is always safe to include them so it’s a good habit to do so.

Let’s try it out by summoning another dog. /summon wolf ~ ~ ~. Now we need to fill in entity data here which is going to start becoming more complicated. One way to keep track of all the closing curly and square brackets is to write them out immediately and then fill in the insides.

Let’s do that – first curly braces for the entity data itself. Then our field – Tags: and a list [] Now for our actual tags – let’s summon a dog with the cutie and goodboy tags – to do that we add two quoted strings separated with a comma, “cutie” comma “goodboy”.

That’s our entire command, and here’s our new dog! If we want to select that one in particular, we could use the tags in our selector – /say @e[tag=goodboy] shows us the wolf, which confirms that we successfully got the tags added to the entity.

Before we leave the topic of entity data for this time, let me give you a word of warning. Using Entity Data is directly peering into the inner workings of Minecraft. This means that as the game is developed, these things tend change from time to time,

So if some of your commands stop working when a version update drops, it is probably because some field name or format changed. Another thing to keep in mind is that not all errors in entity data show up as errors. For instance, misspelling a field usually means that the values just end up silently

Dropped without any error message, so if your values don’t seem to do anything, double-check that you’ve spelled the field name right and that you have the right capitalization. We will keep learning more pieces of entity data and the various ways that can be formatted through the rest of this course.

For now though – let’s wrap up with another game rule. Since we’ve now learned how to summon our own custom entities, what if we want to be fully in control of spawning things? The game has a fairly complex system for spawning new mobs – if we want to turn that off, we

Can do so by changing the doMobSpawning game rule. This game rule defaults to true, and setting it to false will make the game stop spawning new mobs of any kind. Easy enough let’s try /gamerule doMobSpawning false and then use the time command we learned in a previous episode to make it midnight.

Note how despite it being the middle of the night, no hostile mobs are spawning. Very handy! Let’s go back to daytime though – and with that, we are done for today. My name is slicedlime, thank you for learning commands with me.

Remember to get the companion map and play through the exercises there, and if you run into any problems feel free to join my discord server where we have a channel for learning commands.