Hi gang!

Multipart

This will be an ongoing project, so more parts are going to be added at a later time. Just keep your eyes peeled for the update log. My only problem is that I cannot say at what interval this is going to happen because I'm currently deeply caught up in work which sometimes leaves me with very little free time.

Intro

Mark my words: I think Minecraft version 1.13 is going to be one of the best received updates we got so far. And maybe also one of the more controversial ones. Not in the way 1.9 did but there are some very important things you need to keep in mind when upgrading to 1.13 (I suggest waiting for 1.13.1!).

The problem is simple: 1.13 gives us plenty of cool new blocks and new features to enjoy. From new wood variants (bark blocks and stripped log blocks), new block variants (prismarine stairs) right down to completely new blocks such as coral and new weapons like the turtle helmet or the trident. And the new mobs of course: drowned, phantoms, dolphins and several fish make their appearance in Minecraft. Exciting right?

But there's also a downside: 1.13 is probably going to break every map in existence out there because Mojang also redesigned the entire command set. Commands such as /execute are completely revamped, others like /blockdata are going to be removed and finally we're also getting new commands such as /data, /datapack and /tag.

And that's not all... Are you enjoying functions and maybe also structures? Bad news for you then because all of that will stop working as well. World save locations such as .\structures and .\data\functions are now no longer valid and will stop working.

Now what?!

Well, good news! Just sit back and relax and just enjoy reading my blog in which I will describe my ongoing project in converting my current 1.12 redstone world into a 1.13 redstone world. And I think some of you are going to find this very interesting.

Even if you're not into the snapshot yourself you might still learn something because I will be sharing a lot of my 1.12 contraptions, explain them and then convert them into 1.13. So you might find stuff which could be worth copying ;)

Requirements

I'm trying to keep my blog as accessible as possible but there are some requirements. I expect you to have a basic understanding about functions and how to make those. As a result I also expect you to know how to access your world save folder using a file manager and how to move, copy and remove folders ("directories") and / or files (such as functions and structures).

Other than that you won't need much else. If you want to follow my lead you'd only need a 1.12 world which you want to convert. Warning: I strongly suggest that you either make a backup or simply copy your world and use the copy to experiment on.

About my redstone world

Over the years I've really came to enjoy what I like to call "Minecraft tinkering". And what better way than to dedicate an entire world for that? So I've set up a redstone world and filled it with a lot of stuff. From things which I copied from Youtube right down to designs of my own. Redstone, command blocks, structure blocks and of course the scoreboard are all heavily in use here. That's why I think this could be an interesting journey into the 1.13 realms.

First: Preparations; setting up a datapack

As I mentioned above my world uses a ton of stuff. Including functions and structures. And to get those working again we're going to need a so called datapack. A datapack is basically a collection of "Minecraft additions" and it's somewhat comparable to a resource or texture-pack. But instead of making cosmetic changes this pack will actually add (or change) game mechanics.

If you open your world save folder then you should see a folder called 'structures' and one called 'data'. And if you already fired up the snapshot then you should also see a folder called "datapacks". If not then create it yourself.

A datapack can be set up in 2 ways: as a folder which contains everything else, or as a zip file. A zip file can be useful if you want to easily copy your stuff and use it in multiple worlds, but because we're busy converting (and we need to repair plenty of functions!) we'll be using the folder format, at least for now. The fun part is that you can use multiple datapacks if you want to. So to make sure that we can separate our "conversion material" from the new stuff we'll be giving our datapack the same name as our world save.

For example: I'm working with a world called "RedSnap", a combination of "Redstone world" and "Snapshot". And so I'm creating a datapack called "redsnap" as well so that I'll always know what this is for.

So: start by creating a new folder, in my example this will be called "RedSnap". This will be the top of your datapack. Next we're going to tell Minecraft that this is actually a datapack. We do so by creating a new text file called "pack.mcmeta":

{
"pack":{
"pack_format": 1,
"description": "Collection of stuff from the 1.12 world."
}
}

That's all you need. Pretty simply don't you agree? Now we need to add the folders which will contain the rest. Create a folder called "data".

So, quick recap: we now have a folder called 'datapacks' and inside is a folder called 'RedSnap'. Inside this folder is a file called 'pack.mcmeta' (see above) as well as a folder called 'data'.

Now it's doing to get a little tricky. Functions, structures, advancements, loot tables.... they all use a so called "namespace". For example: if you want to give yourself a diamond pickaxe you'd use: /give @p minecraft:diamond_pickaxe. 'minecraft:' indicates a name space, in this case called minecraft which is also the default. Namespaces have 2 purposes. First of all they help us to separate things. Take the diamond pickaxe above. If I wanted to add one of my own I could create a new namespace, in which I would define the new item. For example catslair:diamond_pickaxe. This would ensure that both pickaxes can easily co-exist. The command above would give you the default pickaxe and /give @p catslair:diamond_pickaxe would give you my custom version.

The other reason is that namespaces also allow us to override existing things. If I didn't use 'catslair' but 'minecraft' in my example above I would have overruled the default pickaxe and replaced it with my own. This is not something we'd necessarily do in a datapack, but it's still important to understand the whole concept.

Because the next step in creating our datapack is... to determine a namespace. I prefer using 'default'. This will help us to separate our stuff in-game. As soon as you use something which uses 'default' you'll know what it is (something we're converting) and where to look: our new datapack. So create a new folder called "default".

Now: if you already have functions and structures then now is the time to move those into our new datapack. So in my example:

.\data\functions\* should be moved to: .\datapacks\RedSnap\data\default\functions
.\data\advancements\* should be moved to: .\datapacks\RedSnap\data\default\advancements
.\structures\* should be moved to: .\datapacks\RedSnap\data\default\structures

... of course you can simply move the entire directory. So just cut and paste the 'functions', 'advancements' and 'structures' folders and move them into the 'default' folder of our datapack.

The next step is optional but I prefer a datapack which provides me with full capabilities....

A datapack can also be used for tags, loot tables and recipes. Now, we could create those folders in our current namespace as well, but I don't like doing that because things will get messy; we'd be mixing old and new stuff. Instead I'm going to create a new namespace and put everything in there. So... go up into your datapack structure and create a new folder next to 'default'. I'm going to call mine 'catslair'. In this folder create all the following subfolders: advancements, functions, loot_tables, recipes, structures and tags. Then inside 'tags' create 3 more subfolders: blocks, items and functions.

So we now have:

datapacks
+- RedSnap
+---- pack.mcmeta
+---- data
+------- default
+---------- advancements
+---------- functions
+---------- structures
+------- catslair
+---------- advancements
+---------- functions
+---------- loot_tables
+---------- recipes
+---------- structures
+---------- tags
+------------- blocks
+------------- fluids
+------------- functions
+------------- items

Note that you don't have to fully follow my example, but I do suggest that you at least create your own namespace with a fully set up structure (comparable to 'catslair'). Because this will then allow you to quickly add new functions, structures, recipes and all of that into your Minecraft game.

So, to recap: I made a datapack called "redsnap" which has the same name as my world. I defined 2 namespaces: default and catslair. Default contains all the existing system stuff from the world: functions, structures and advancements. Catslair is completely empty and contains folders for everything which can be added to a datapack.

Now we're ready to fix some things!

First problem: The missing pyramid

When I started this world I wasn't fully familiar with commands such as /effect. And because I wanted to quickly move around I decided to place beacon pyramids. But a beacon has a limited range and as my world expanded one wasn't enough anymore. So I added more.

Unfortunately it's quite tedious if you have to build every pyramid manually again but fortunately there is a solution: the structure block. This is where I set up an experiment with those and as you can see: we have a problem.

First something important: as you can see the upgrade to 1.13 will break a lot, but not everything. As you can see my /title command still works as usual. So although there are definitely a lot of things which are in dire need to get fixed there will also be plenty of things which will still work as usual.

So what is going wrong here? Very simple, if we open the structure block then we'll see that it was trying to load beacon_pyramid. Well, that structure obviously no longer exists because one of the things which changed in 1.13 is that all structures (and functions) are now part of a datapack. Which means that they also need a namespace.

This is why we started with moving all structures, functions and advancements. So we need to change this into: default:beacon_pyramid. And what do you know?



But there's more... ignore the command block output for now, as I mentioned above I have a lot of stuff running in this world and we'll get to the farming stuff later on. I want to talk about the command block. I use that to /fill the space of the beacon with air in order to make it disappear.

I noticed that this command block still works but there's also a problem: fill -212 56 274 -204 61 283 air. As a rule of thumb: always specify a namespace. It might work, like in this example, but trust me when I say that you could easily run into problems later on. Don't be lazy, and do this as it should be done. So I changed this into: fill -212 56 274 -204 61 283 minecraft:air.

It wouldn't be the first time that Mojang changed some things within their command structure and enforced certain already existing standards to be used. Every player who already followed the standard (so: did things the correct way) had no issue. And those who relied on shortcuts (and broken command generators): bzzzt.

Second problem: the auto crafter

Now... In 1.12 we don't have ways to create our own recipes. So I found a way around that ;) If you activate this contraption (the repeating command block needs redstone) it will scan the area around you to find a stick. So: if you have a stick in your inventory and you throw it on the ground then this setup activates.

It then checks for any coal on the ground near the stick, and if it finds one: poof! Both blocks will disappear and you get a torch back in return. So basically you can craft a torch by throwing down a stick and a piece of coal. Nifty huh?

Here's how this works in 1.12 (from right to left, so starting with the repeating command block):

testfor @e[type=Item] {Item:{id:"minecraft:stick"}}
scoreboard players tag @e[type=Item,tag=!stick] add stick {Item:{id:"minecraft:stick"}}
execute @e[type=Item,tag=stick] ~ ~ ~ testfor @e[type=Item,r=1] {Item:{id:"minecraft:coal"}}
execute @e[type=Item,tag=stick] ~ ~ ~ summon Item ~ ~ ~ {Item:{id:torch,Count:1},Tags:["torch"]}
execute @e[type=Item,tag=stick] ~ ~ ~ kill @e[type=Item,r=5,tag=!torch]

Please note: I'm not claiming that this is the most efficient way. Keep in mind that we're also going over some of my experiments, and some of this stuff was still sitting on the "needs to be updated" todo list ;)

But it works! Well, worked. Because in 1.13 /testfor is no longer a command. Now what?!

First we're going to stop and think what we want Minecraft to do...

• Detect a stick.
  
• Detect a piece of coal.
  
• If both items have been detected then create a torch.
  
• Remove both original items.
  

As you can see I also used entity tags in order to delete the right items. I don't want to kill every dropped stick in existence because then this contraption could interfere with someone else playing survival. I'm always keeping multiplayer in mind.

Although we can't use /testfor anymore we can do a whole lot more with /execute. So we're going to start there. I mean: what is the difference between testing if an Item exists and doing more stuff if it does OR trying to /execute something as that item and then only continue if that works? Answer: hardly anything ;)

So our first command is going to be:

execute as @e[type=minecraft:item,nbt={Item:{id:"minecraft:stick"}}] run tag @s add stick

See what is happening here? I'm trying to execute code as an entity (@e) of type Item. Everything which you drop on the ground will match this. So I'm also adding an NBT tag which specifies the item I'm looking for: minecraft:stick. Then when all of this matches I'm finally running my command: tag @s add stick. /tag is a new command which is basically a shortcut for: /scoreboard players tag @s add. Note that this last command no longer exists in 1.13. /tag it is.

Let's continue with our project though.. I'm also using @s because I want to tag the actual entity which is running the command. Which is the stick. So now that we have identified the stick and tagged it (this makes it easier to find again) we can now proceed with step two: test for a piece of coal. Basically: an entity (@e) of type Item, same as above.

So now I'm going to detect the coal and if I do so summon a torch:

execute at @e[tag=stick] as @e[type=minecraft:item,nbt={Item:{id:"minecraft:coal"}},distance=..1] run summon minecraft:item ~ ~ ~ {Item:{id:"minecraft:torch",Count:1},Tags:["torch"]}

This is a good example of why I'm so excited for 1.13, this command would be totally impossible with 1.12. So...I am running a command at the location of the entity with the tag stick. So my previous stick. The command should be run as the coal entity near it (distance is one block at most) and if this is met it should summon a torch which has the tag 'torch'. Easy right?

So finally it's time to clean up after ourselves:

execute at @e[tag=torch] run kill @e[type=minecraft:item,distance=..3,tag=!torch]

Here I'm running a command at the location of the previously summoned torch and I'm basically killing all items which are at most 3 blocks away and which do not have the 'torch' tag. In other words: the stick and the piece of coal.

But there is a problem...

The first command (in the repeating command block) adds a tag to the stick we threw on the ground. But once the stick has a tag it can't get another one with the same name, so this command will only work once. And that is a problem because we also need to detect the piece of coal somehow.

The solution? Simple!



We use two repeating command blocks! Both are triggered by redstone so the lever will enable (and disable) both of them.

This ensures that both commands keep running: when a new stick is thrown onto the ground it gets tagged, and then it will try and use a nearby coal item to summon a torch after which both items get removed (killed) by the last (conditional) chain command block.

Chapter 2 - The case of the cloned chest

This was something I build to help someone out on a forum. It's a setup to retrieve the items of a player after they die. Not in a very sophisticated way though: a hopped collects the items and puts them into a chest after which the chest and its contents get cloned to another location, after which the contents of the "source chest" obviously get emptied.



Player dies on top of the hopper (due to fall damage) and their items get picked up. The comparator picks up a signal which will disable the redstone torch, the hopper also starts to fill up the chest. When done the comparator will stop detecting items, the redstone torch lits up again and that will trigger the command blocks behind it: these clone the chest and then empty it. It's a rather simple setup: a command block followed by a conditional chain command block.

clone -201 22 117 -201 22 117 -200 56 114 filtered force minecraft:chest

And:

setblock -201 22 117 minecraft:chest 3 replace

Unfortunately these commands no longer work. But the solution is rather simple sometimes. Instead of using 'filtered force' we now need to use: 'filtered <id> force'. So just swap 'minecraft:chest' and 'force'.

The last command is a bit more tricky though. To make this work again all you basically have to do is remove the '3', this was used to specify the direction of the chest but that is no longer needed. The downside here is that this will constantly replace the chest with a new one and a default direction which doesn't have to be what we want. At first this may not seem like a big deal, but when I design these routines I do so while trying to avoid instructions such as: "be sure to place the chest facing eastwards".

Fortunately for us Mojang gave us something far more powerful than /setblock: /data.

/data can be used to check and control just about everything, including the inventory of an entity or the items in a chest. So instead of using setblock we're going to use this:

data merge block -201 22 117 {Items:[]}

This will tell Minecraft to merge the NBT code in the command with that of the block. Effectively emptying its contents, despite the direction it's facing. All we're doing is changing the contents and nothing more.