Over the past few months, I've taken on the task of updating WorldEdit, WorldGuard, and CraftBook to Minecraft 1.13. This article is the first post in a multi-part series that explains the changes made, and any significant differences from both a user and API user perspective.

On January 3rd 2018, I started work on the migration of WorldEdit over to "String IDs". This is one of the significant changes that occurred in the Minecraft codebase since the creation of WorldEdit. Over the past few years, Mojang has put considerable work into modernising the Minecraft codebase. This change has been a long time coming. The Sponge project, which started in 2014, was built with these changes in mind.

Glossary of Minecraft Changes

The first considerable change was the usage of "String IDs", or keys as I'll refer to them from now on, rather than numeric IDs. While this change had been made beforehand, up until 1.13, the numeric IDs as we knew them still existed.

The concept of 'metadata' (or data values) has also disappeared in 1.13, replaced by a property and value system. Each potential combination of properties and values for a block type is considered a state. An example of a state is the grass block, minecraft:grass_block[snowy=false] and minecraft:grass_block[snowy=true] are both states of the grass block. Overall this system means that blocks without metadata no longer waste space, and blocks that needed more metadata can have as much as they want.

That's not all though, Mojang flattened the block and item lists to minimise the usage of states. There used to be block variants, such as stone, diorite, and andesite; these are now separate block keys. This change means there are 16 keys for wool, rather than 1 with 16 states.

You may be thinking, "Storing strings rather than numbers sounds inefficient, will Minecraft get slower now?" Yes, storing strings would be inefficient; however, that's not quite how Minecraft works. The game contains a palette system, which maps the keys to a numeric state ID. These IDs are not guaranteed to be the same, and can therefore not be relied upon. To anyone thinking of using those to make migration more manageable, don't. Just don't.

There are two palettes used in the game, the global palette and the direct palette. The global palette is mostly used for inventories, advancement popups, etc., whereas each chunk section contains a direct palette. Each direct palette has a limit of 4096 different states, the same amount as was possible in 1.12, meaning no extra space is required. However, being per chunk section means there can be theoretically limitless blocks per world. As a chunk section is 16x16x16 (4096), there can be a different state for every position in the chunk section, with varying palettes for every chunk section.

The update process

Now that I've filled you all in on what has changed, I'll start talking about the update process. As of writing, (July 26th AEST) I have spent the equivalent of around five weeks of full-time work updating these plugins. Overall I've changed around 120000 lines of code across the three projects, as well as approximately 15000 in external tools.

Backwards compatibility for plugins interfacing into the plugins is NOT guaranteed. Backwards compatibility for server owners and players is attempted as much as possible. I updated the plugins in the order of WorldEdit, WorldGuard, and then CraftBook. These posts will follow that same order.

Part 2, focusing on the changes to WorldEdit, can be found here.

We've devoted countless hours to working on these projects. If you'd like to support us, we have a GitHub Sponsors. Thanks 😁

About the Author

Maddy Miller

Hi, I'm Maddy Miller, a Senior Software Engineer at Clipchamp at Microsoft. In my spare time I love writing articles, and I also develop the Minecraft mods WorldEdit, WorldGuard, and CraftBook. My opinions are my own and do not represent those of my employer in any capacity.