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 major changes that have occurred in the Minecraft codebase since the creation of WorldEdit. To anyone who's unaware, over the past few years, significant work has been undertaken to modernise the Minecraft codebase by Mojang. To put into perspective how long this has been going on for, Sponge was built with these changes in mind from the start.
Glossary of Minecraft Changes
The first considerable change was the usage of "String IDs", or keys as I'll refer to them as 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. This has all changed now, however.
The concept of 'metadata' has also disappeared in 1.13, being 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=true] are both states of the grass block. Overall this system means that blocks that didn't use metadata no longer waste space, and blocks that needed more metadata can have as much as they want.
That's not all though, the block and item lists were flattened to minimise the usage of states. Where there used to be block variants, such as stone, diorite, and andesite, there are now separate block keys. This means there are now 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 items in inventories, advancement popups, etc., whereas the direct palettes are stored per chunk section. 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 different 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, (26th July 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.
To preface, 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.