Hi gang!

Editorial

It is my believe that ever since Minecraft 1.13 got released it somewhat stopped being "just" a sandbox survival game and also began becoming a bit of a gaming platform all on its own. Seriously: the amount of control which you, being an admin, have over your own world is honestly somewhat mindblowing I think. I'm not only talking about gamerules and gamemodes and all that, I'm talking about making things do and behave in a way you want them to.

Well, if you want to get the most out of your Minecraft world then there are three main mechanics you really should become familiar with; all three of these mechanics fully tie into each other and as I will show you: it can become extremely useful to know at least some basics about all of 'm.

So I figured I'd take you guys on a (brief) tour to look at these three "Minecraft command powers".

Small disclaimer!

If you look closely at my screenshots you will probably notice that my environment is "modded", that's because we currently play on a (private) Forge LAN server which means that the use of client mods has now become mandatory: if you don't have the right mods loaded then you don't get access to this server. And right now most of my experimentations and such happen here, because it's much more fun to play together.

However, keep in mind that the things I'm showing you are all fully "vanilla": so no mods needed! The only thing which might happen is that I'm using some items or blocks which were provided by a mod, but that's it, and that'll be all. I'll make sure to mention this so that you guys won't get confused.

#1 Redstone

So what do we have here?

If you take another look at my blog logo you'll notice 3 Pillagers: one is riding a ravager while holding a (command) stick in his hand and he wears a banner with a skull on it. Right next to him are two more pillagers who are armed with crossbows and stand ready to fire in the direction of the red block at the top of the screenshot.

This is actually an experiment I'm working on: setting up an armed conflict / mob "arena" for my friend Aya to play with. And even though I'm using command blocks to set things up (see above) it's actually redstone which directly controls the flow of action. The idea is for a player to stand near the red block at the top after which the "Death squad" will show up: the group of heavily armed pillagers. The commander then "orders" his men to attack (= editorial freedom) after which they start shooting.

Then, depending on how the battle is going the commander will eventually also order the ravager to attack as well.

See, while I could set up something using so called repeating commandblocks this would actually be a waste of resources. Why would you want to have a commandblock constantly running to check for some conditions while you can also use redstone to initiate everything? The first is not something you'd find in a casual Minecraft world but the use of redstone is fully integrated into the base game, so why not use it?

The basic rules of Redstone

A lot of people will claim that redstone is "difficult" and hard to use, but it honestly doesn't have to be like that. I mean, you can make its use both easy and straightforward or very complicated, your choice. What is important though is being aware of the so called ground rules of redstone behavior:

• Redstone has a maximum signal value of 15. This means that a signal cannot travel past 15 blocks, something shown above: the lamp on the right (8 blocks out from the torch) is turned on but the lamp on the left, which is another 8 blocks away, stays off.
• Redstone has 3 main types of blocks: sources; these provide a redstone signal (like the torch), conduits; these transfer a redstone signal (like the redstone dust, but also the lamp!) and receivers: these "do" something with a redstone signal such as the lamp turning on.
• There are three main "control blocks": a comparator (shown on the right) checks the block behind it for a redstone signal, if one is present it then it will relay this signal (and it's signal strength). Which is why the lamp on the left side isn't turned on: all the comparator did was relay the signal, and because it had already travelled out by 8 blocks this signal had a value of 15 - 8 = 7.
• The second control block is the so called repeater: as its name suggests it simply 'repeats' a redstone signal. In other words: boosts its power all the way back up to the maximum value of 15.
• Last but not least the observer block: this block constantly looks at the block in front of it and when something changes then it will trigger a quick redstone pulse. Ever wanted to check that your sugarcane is at its peek? Then why not use an observer?

See what I mean? Here the observer is looking at the air block in front of it. Yes: air ("minecraft:air") is also a block. As soon as the sugarcane grows to its full size of three blocks then the air gets replaced by sugarcane. This gets 'observed' by the observer after which it will trigger a redstone pulse: a quick on and off signal. This gets picked up and repeated by the repeater behind the observer which directly powers the diorite block behind it. That block then powers the redstone dust below it and that in its turn triggers the piston which will now extend, break the middle sugarcane block and then retract again.

All you have to do now is to pick up the sugarcane. You can do this manually, but a hopper might be a better idea. Yet that's a bit beyond the intend of my guide right now ;)

One last thing though... the final "rule of behavior" of redstone: strongly powered vs. weakly powered. The diorite block behind the repeater gets its signal directly from the repeater itself which means that it gets strongly powered. This has nothing to do with the strength of the redstone signal (or "charge") but rather the way it received it.

See: if a block directly receives a signal from a redstone source it becomes strongly powered, and that means that this signal can be picked up by a redstone conduit: the redstone dust below it. But if it becomes weakly powered... then this mechanic won't work. In other words: if I were to place some redstone dust next to the diorite block on the ground then this dust would never get powered, simply because the block doesn't get a strong signal itself.

Remember my first example with the redstone lamps? There's a reason why I used a comparator up there, and it wasn't necessarily because of the demonstration: it was the only way for me to move the signal back to the beginning, because the lamp was weakly powered, so I had to use something like a comparator to pick up the signal again. Otherwise it wouldn't have worked.

More important than you may think?

As I mentioned earlier: redstone is a de-facto part of any Minecraft world. Redstone dust can be mined in the overworld, once you have obtained some nether quartz you can craft devices like a comparator and daylight sensor and well... you can control as much as you want. Take (trap)doors for example. Or maybe lights which turn on as soon as it's getting dark?

The thing is: redstone can easily become an essential part for handling certain administrative tasks.



So let's say for the sake of argument that I have a complex structure here. It's blocking my view of the temple behind it which is why I want to rotate this by 90 degrees. Sure... something this simple is easily rebuild, but that's not the point right now. What if I needed to 'move' this in a quick and efficient way?

Well, thankfully we now have structure blocks which can be used to load and save structures. As you can see above I already set one up. So here's a fun little 'secret' about these blocks: if you set up a structure save block as I done above then cilcking 'SAVE' will do just that: a new file gets created which contains the structure which you set up for the block to include (see the outline?).

But wouldn't you agree that this is a lot of hassle for merely wanting to move something out of the way? I mean, if you want to keep your world save a bit tidy then you'll have to go clean this up afterwards. Well... if you trigger a structure block using redstone then it won't save the structure to a file but instead will copy it to memory.

Then all you have to do is set up a load block somewhere, refer to the same structure and once you're done you simply destroy both structure blocks and then it'll be as if nothing happened.

Seriously: you don't have to become a redstone genius, but having some basic understanding can really get you places.

The "secret" to redstone?

There is honestly one main "secret" to messing with and becoming good with redstone: breaking down a problem into smaller, more managerable, chunks and then solving each of those smaller problems one step at a time. Seriously.

Take the sugarcane above... the first 2 issues: how to check that it's ready to harvest and second: how to harvest it? The second problem is somewhat simple: break a cane in the middle and its stem remains in place while you get the top two blocks. Nothing which a piston can't handle. Then the timing of the harvest... well, we all probably know that a sugarcane doesn't grow taller than 3 blocks, and that leaves plenty of room for an observer.

See, there's a reason why all commandblocks have a setting to determine if their activation requires redstone or not...

Which actually brings us to...

#2 Commands (and some blocks to put 'm into).

If you want to properly manage & administrate your Minecraft world then everything eventually falls back to commands, optionally manifested in the form of command blocks, which you can see above. There are three types of these commandblocks:

• Impulse (left side) => This block simply runs a command and that's that.
• Chain (middle) => These types are always part of a 'collection': then execute their command but only after the block 'before' them has executed its command. You will normally find these 'behind' impulse or repeating command blocks.
• Repeating (right side) => This block does as its name implies: it repeats its command over and over and over again.

As you can see all three blocks have 2 variants: conditional (the one with the 'arrow') and unconditional (the one on the left side). This is mostly used with the chain type: if set to conditional then it will only run if the command within the block 'before' it has succesfully executed.

And as mentioned: all these blocks can be triggered (or controlled) by redstone, but also provide a redstone signal based on the results of the command they ran.

So what commands are we talking about? Well, there are tons of commands for us to use... from changing the weather (/weather) or the time of day (/time) to something more "interactive" with the players like /give which, as its name implies, gives another player (or mob!) some kind of item. Or maybe you want to give your players some XP? => /xp is right there.

But let's take this one step further, shall we?

JSON and NBT: essential key components for our Minecraft commands!

JSON stands for JavaScript Object Notation and it's a so called file and command format which allows us to structure commands to use different types of information. Now, bear in mind that the line between JSON and NBT is somewhat blurred but to keep this as simple as possible we're going to take this one step at a time.

To put this simple for now: JSON represents the format of the commands we use whereas NBT defines the structure.

What does NBT stand for you wonder? => Named Binary Tag and unlike JSON it's something specifically used within Minecraft. JSON is actually an open standard meaning so much that its use isn't limited to just Minecraft. NBT otoh...

But one step at a time!



FLAN ("Fabric LANd") is a server mod which allows players to make a land claim after which that area becomes protected from others. It uses a golden hoe as a tool to create (and expand) claims and also a common stick to check if a block is owned by a specific player.

Thing about me: I take our server very seriously so "just" using a golden hoe wasn't good enough, it needs to be obvious what this tool does and even more so: I wanted to make sure that Aya and any optional visitor could always check how things worked. For your information: this isn't a fancy "modded item" you see here: this is a full vanilla item made using vanilla commands which just so happens to be used by this mod we use.

So how? JSON with a bit of NBT of course!

Item properties

Nearly every item in Minecraft has so called properties, and this is especially true for so called entities; things that "do" something. Fun fact: both mobs and players alike are all entities within the world of Minecraft.

If we take a look at the hoe shown above then there are 3 property types that should immediately stand out:

• The items name and lore (ergo its "display")
• The items enchants (the Unbreakable property somewhat counts for an enchant).
• The items damage.

Notice the mention of 3 NBT tags in my above screenshot? Let's take a closer look:


So what are we looking at here? Obviously the output of the so called /data command, in specific: /data get entity @p Inventory[​0]. Now look closely: the tag comment is followed by a { character. The Lore comment has a [ behind it. And if we look at what's inside the { } characters behind 'Name' we see mention of text, color and bold.

This my friends is the so called JSON notation:

• The { } characters resemble a so called tag_compound structure. Simply put: everything inside the { } characters will provide the so called NBT data and this data can consist of several differerent properties. What properties? In this case => Unbreakable, display and Name.
• The [ ] characters define a so called tag_list component. A list implies that there are one or more values which together define the property we're using. The example above being Lore; this can consist of one or more lines of text and thus its format is defined as tag_list.
• Then we have " " charafters, two double quotes. These represent a so called string which is basically a line of text. You can see this in both the Name property but it's also being used inside Lore. Here we're dealing with so called strict JSON: this implies that everything needs to be spelled out in full detail. If we look at Name you can see that the actual text gets individually defined, but also some of its properties like bold and italic.
• Booleans, or tag_boolean. Surely you were wondering why words like true and false weren't surrounded by double quotes? No? Well, then you should have because when dealing with commands details like this truly matter! The reason there are no " " characters is because these aren't strings but booleans which define a true or false value; no more, no less.
• Notice the 1b behind Count? That b stands for byte, in specific: tag_byte. There are three important numeric values within NBT: float, byte and integer. To make sure you're using the right format you need to use either b or f to make sure that the format of the number value you're using is picked up accordingly. If you don't use a designation then it'll be picked up as integer.

Here is the actual command which I used to create this gizmo:

give @s minecraft:golden_hoe{display:{Name:'{"text":"Land claiming tool","color":"gold","bold":true,"italic":false}',Lore:['{"text":"A tool to protect your home!","color":"white","italic":false}','{"text":"Use \'/flan menu\' to edit your claim.","color":"green","italic":false}','{"text":"Use \'/flan help\' for more info.","color":"dark_aqua","italic":true}']},Unbreakable:1}

This obviously begs the question: how do we know when to use what value and/or format?

Unfortunately we don't, not always. Commands like /data can help you to discover a lot of these details, but there's only so much. When looking at Count shown above then... there is no reasoning: that property only uses a byte ("tag_byte") value, that's it and you'd better know and deal. Same for textual color values.

But never underestimate what you can discover through experimenting.

For example:



So here I simply renamed a plain iron pickaxe. It once again mentiones 3 NBT tags and if you take a closer look (using the command I mentioned earlier) then you'll discover: display, RepairCost and Damage. Just keep in mind that when a property has a default value then it won't get mentioned. For example: notice how the renamed pickaxe has an italic title? That is common behavior for renamed and enchanted items and as such: it won't be a defined property.

Fortunately there's always the Minecraft wiki.... For example, take a look at this section regarding item structures. Notice Unbreakable? The very same propery I used before!

Command selectors

JSON and NBT form the very heart of every Minecraft command, but there's one specific aspect you simply need to know about: a command designation: who or what are you going to target in your command?



So here I once again summoned my pillager "death squad", yet now we have a problem: I expect Aya to come over any time soon to mine out those ore blocks I placed earlier, but I don't want her to get bothered by this lot. It'll mostly be fine: I'm using the NoAI tag to keep these guys passive, but for now I want to get rid of them. Sounds like a job for the /kill command. But what are we going to kill?

We need a designation or selector:

• @a represents all the current players in the world.
• @e represents all entities.
• @p represents the player that is closest by.
• @r represents a random player.
• @s represents the entity affected by your command.

The fun part is that these selectors can also use extra properties to finetune the selection. How about this: /kill @e[​type=!minecraft:player]? In other words: kill all entities in the world except for those of type player. That doesn't sound very useful on a server, let's trim it down some more: /kill @e[​type=!minecraft:player, distance=..10]; much better: we're still killing all the entities which aren't players, but only those within a 10 block area around us (= the one who issued the command). So no risk of accidentally killing Aya's pets.

And while you can't easily find default item or entity properties in the game, you can easily check out the list of selectors: thanks to the new Minecraft command completion. Minecraft's chat sure has improved a lot since 1.8! ;)

.... except that there's always a limit to the length of text which you can type. So if your command becomes too long then you have no other choice but to use a commandblock. But what if we need such a command to be available anywhere in the world?

I mean: commandblocks are awesome, but they are not protected from chunks getting unloaded.

Fortunately for us the people at Mojang also considered this aspect and thus they gave us:

#3 Datapacks!

In this sea of packs we're looking for file/ServerPack which is the one I created to support all this.

A datapack is a collection of "control files" which can provide new or customized assets for your world. Functions for example are simply commands that are stored in a JSON formatted file (though the extension is .mcfunction) and it contains ... well, a function or command. Remember that claim tool I mentioned earlier?




I made sure to add this to the 'server section' of the main datapack so that it would be easy to get the tool without having to type out the full command each and every time.

Oh, and for the record: that spawn egg can't be used to summon an AyanamiKun ;) It's actually a customized llama spawn egg which summons LlamayamiKun which is Aya's favorite pet Llama (customized), but the command is very dated (from a time where you needed to use control codes to get color) and I still need to adapt it to our current Minecraft version. The famous ever expanding todo list ;)

But back to datapacks.... there are several things which it can provide and/or customize:

• Functions (see above).
• Advancements.
• Recipies (crafting & smelting recipies alike).
• Structures (things you can load using a structure block).
• Tags (which is basically a collection of "other things"; like blocks or functions and such).
• Loot tables (this defines what item(s) get dropped when you kill a specific mob or open a certain generated chest).

You can even use a datapack to create new world dimensions, but that's all experimental at the time of writing.

And there you have it!

(for now)

Three different yet very important (and intertwining) ways to customize and/or control your Minecraft world.

As you can see I didn't go into extreme details, but kept things easy to understand (hopefully). But I am definitely playing with the idea to dive deeper into all three topics, one at a time, to help unravel some more "mysteries" behind 'm and hopefully make things a bit more accessible.

To be continued? Who knows.... now.. if you'll excuse me, I'm going to help Aya finish her tunnel through the nether: she discovered a fortress all on her own and now it's time for easy access between the portal and said fortress.

Thanks for reading, I hope you guys found this useful.