Hello everybody!
Welcome to our second Development Blog of 2025! As the first six months of the year come to a close, we wanted to provide an update on what has already been a busy year of 1.18 work!
Our focus this year has primarily been on continuing our server upgrade work, including staff testing, and as such we will be dedicating this blog solely to recapping our 1.18 efforts. As will be explored in this blog, we turned away from getting our core features working in 1.18 to branching out to the other plugins and systems that help make Potterworld what Potterworld is. This includes ensuring Housing, Magic, MythicMobs, and all our quests, shops, and vaults work on 1.18.
February 2025 Development Blog
In this year’s first blog, we discussed our 2024 achievements, but also announced our plans of upgrading Potterworld to 1.18 instead of 1.16, and the factors behind this decision!
Don't forget you can also check out all of our past Developments Blogs in the Blog Posts folder here!
For this blog, we’ll be covering these topics:
1.18 Plugin Process
1.18 Config Migrations
1.18 Database Migrations
1.18 Word Migration
The Future
Let's go!
1.18 Plugin Process
One of the first things we tackled when upgrading the server was to make sure our minigames and Classes plugins were compatible. We chose to do these ones first as they were quick wins, and didn’t really change much between versions. Think for example in the Classes plugin, that doesn’t really do anything Minecraft version specific, so it was an easy job to change its version and call it a day. In addition to that Minigames (minus Quabbleball) were mostly the same story, they all existed on Minecraft logic that was pretty consistent throughout versions; start a timer, do some actions, calculate points, then award a winner.
Housing
This approach allowed us to get away with not converting Housing yet still feel like we were making significant progress in the upgrade. Unfortunately for us however, this meant Housing remained as the elephant in the room and still had to be converted. So that is what we embarked to do only a few weeks ago. Upgrading Housing was no straightforward job simply due to the way that Housing interacts with Minecraft. This is because we do a lot of things on Housing that are not native to vanilla Minecraft such as not only our sceneries, but also making sure plants don’t grow, snow doesn’t fall, the correct blocks break when you mine them (i.e. ores) and so much more!
Luckily this was all quite straightforward to convert, as our approach has been to make 1.10 code compatible, as opposed to adding in new 1.18 features (yet), thus we did not really need to account for any huge changes, minus any block renames.
That meant that for Housing, the real challenges were: (1) actually setting up the Housing world as this is huge and requires us to make room in our 1.18 environment, and getting it to correctly pull the Housing worlds, and make sure to save them; and (2) getting sceneries to work.
Housing sceneries took quite a bit of time, and required the drawing of a lot of weird diagrams and maths equations. But we got them done, and it was a great feat to tick off. The reason this took the longest is that Housing sceneries are all done manually, we do not use WorldEdit to just //paste in the scenery, each block is manually pasted. In 1.10 this was straightforward with the help of the WorldEdit/FAWE API, however in 1.18, naturally, this API had changed and as such we had to remake our code. Without getting too technical, the biggest challenge was understanding the new API and telling it how and where to load in the new housing sceneries, while ensuring to also delete the older ones. To ensure these are placed correctly, in 1.10 the API would automatically account for the offset of the scenery; this means that it would automatically determine where to start building the scenery with respect to a point on the player’s house and where the scenery lived. However in 1.18 this got removed, which meant we had to manually do the maths to calculate the positional offset of where to start pasting the housing scenery to ensure that it was pasted in the correct area of your world, and not just at some random coordinates. For example if all sceneries are built on a world and their coordinates are 100,100,100, and we copy from the far left corner, we need to ensure that on the housing plot it also places it on the far left corner, even though the coordinates of the plot are not 100,100,100, but more like 28,90,29. That is where the offset comes into effect, however as previously noted, we had to determine this ourselves, which was more complicated than it needed to be!
In addition to that, every scenery also has to be manually migrated and re-saved to a 1.18 compatible format! However with that out of the way, Housing was complete, and the satisfaction received when the scenery was swapped with no pasting errors made it all worth it.
Tab Complete
It is also fitting to give a quick mention to the 1.18 tab complete system. To those who have played on more recent versions of Minecraft, when you open chat and type “/” it brings up a list of every single command in the system. This is not ideal in a lot of ways as firstly it brings up a list of commands that players will never have to use, and secondly it is an absurdly long list that is just overwhelming to look at. As such we had to redo our permission system in such a way that meant in 1.18, you would only see the commands pop up in “/” that you have access to using. Due to the nature of the code, we also had to make this change in 1.10, but as the system does not exist there (really), there was no noticeable difference! We will note that we have not added support for smart tab complete that tells you what words to put where in a command, as again we are only making our code compatible for now, and not leaning into new features just yet!
However unfortunately like all things, we ran into an issue with this system. Our chat channel aliases were showing up in chat as being invalid commands, such as when you did “/l Hello!” as we do not define channel aliases as their own command (in order to keep the channels and their aliases dynamic), but instead had a system that listened for your message, and checked if it referred to a channel, before deleting that message and forwarding it to your channel of choice. To make this work in 1.18, we did have to make each alias its own command, but we did this in a dynamic way. However this did impact 1.10, as each chat channel was now its own command, we did have some overlap in commands with other plugins, thus causing issues such as accessing “/sc” (serpent chat) or “/d” (dark follower chat). For serpent chat, we overwrote the code to make it listen to “/sc” as a priority command, however for dark follower chat, the easiest solution was just to change the channel alias to “/df”.
1.18 Config Migrations
Another challenge we tackled earlier this year was what is referred to as our configs. To put it another way, these are the settings for external plugins that we use on Potterworld such as Magic, MythicMobs, Citizens (NPCs), and WorldGuard. Again it comes as no surprise that these needed migrating to make our 1.10 files compatible with 1.18. To reiterate, we perform migrations so that we do not need to manually update our files every time an update is done on 1.10, but instead make 1.18 automatically convert the files for us. This saves a lot of time and ensures that whilst working on 1.18, we do not need to perform any hard freezes on 1.10 content.
MythicMobs
The first configs we decided to convert were our MythicMobs files. This was important to ensure that our world mobs and quest mobs would work on the 1.18 server as there had been significant adjustments and improvements to the plugin over the years. To facilitate this, we wrote a script that iterates through every file and makes the required changes before uploading to the 1.18 server. Some examples of things we had to migrate were changing the names of the sounds that Mobs make, as some were renamed in 1.18, such as the “block.note.bell” sound our Fairies make which was renamed to “block.note_block.bell”. A small change, but one that makes the difference in whether or not the mob will make any noise when fought.
Other changes included renaming the entity types of mobs where they had changed between versions, as well as the villager professions and equipment that mobs wore (e.g. gold_helmet was renamed to golden_helmet).
Citizens
We also had to do a similar process for the NPCs on our world. The changes in Citizens were much less than that of MythicMobs, however we still needed to tweak the occasional NPC that had a villager profession or a renamed item as its hat or held item.
We also had to fix up the way that skins are applied to NPCs, but thanks to our built-in skin library, it was only a process of making a quick command to use in-game that refreshes and reapplies all the skin values back to the NPCs and saves them!
WorldGuard
Finally for WorldGuard, we only had to make two changes, and that was correcting the commands that are run on players when they step into regions on the world. The two problematic commands were the sound, and effect command. Similarly to above, for the sound command all we had to do was fix the name of the sound being played if a player entered a region, to make sure it was 1.18 compatible. For the effects however, this required more work as the syntax of the command changed. This will become more relevant later as it was a huge change we also had to account in our database for where the effect command was used in quests and on-world content.
That wraps up our config migration scripts. We’re glad we made these as it saves an enormous amount of time and allows Potterworld to continue to evolve whilst we work on 1.18, without needing the manual intervention of fixing every little file in our plugins that was renamed.
1.18 Database Migrations
Command Migrations
Continuing the trend of migrating and renaming changed commands and values, our next obstacle was doing the exact same thing, except this time inside of our 1.18 database copy. There are three main commands that have had to be altered in our 1.18 code, two of which have already been touched on. They are (1) the effect command; (2) the playsound command; and (3) the give command. For each of these commands we had to replace and migrate them in the various places in the database where they are in use, for example in GUI commands, dialogue commands, and even at the start or end of container sequences!
The effect command was the first renamed command that we noticed in 1.18. This was mainly due to its entire syntax changing. Instead of the command in 1.10 being “/effect @pn <effect_details>”, it was now expressed as “/effect <give/clear> @pn <effect_details>”. This meant we had to do a shuffle of the command to ensure that we inserted “give” or “clear” into the command syntax. There was only one other factor we forgot to account for, and that was effect commands that used a number instead of a written effect type. This was the way that it was traditionally done in older versions of Minecraft, for example writing “1” as the effect type would give out the speed effect. However 1.18 now requires us to write out “speed”, so we had to make sure we converted our numbers too! Nevertheless it was nothing we couldn’t handle!
Similarly, the playsound command also changed. As mentioned above in our config migrations, this was not a syntax issue, but rather just the names of sounds changing. This was a relatively easy change to make, as we had already been doing it for all our other migration scripts!
Finally that left us with the dreaded give command. There was a lot to unpack in the conversion of this command, as anyone who has played vanilla Minecraft would know, the give command can do a lot! On the face value the command is very helpful in just giving out vanilla blocks in the Mine Depot on Housing, such as Stone, Wooden Logs, Grass, Diamond Ore, or a Redstone Block. As has likely been previously discussed, in the move from 1.10 to 1.18, a lot of block names have changed, especially the woods, stones and other blocks that have a base but then different variants. An example of this is wool. In 1.10 there is one block “wool” and each colour variant is a data number appended to the end of the block ID, e.g. “wool:6” for “pink_wool”. This means that in the give command we have to account for the renamed block, and the dropping off the data field. However this is only the surface level of the give command, and it does so much more, which we also needed to account for.
On Potterworld our other usages of the command included spawning in firework items, custom skulls, enchanted tools, banners, firework changes, and dyed leather armour. Whilst a lot of these features are no longer used in our commands, quite a few usages still remain spread out both in the Housing Mine Depot and in a lot of helpful staff tools to spawn in items for gameplay. The syntax of the more complex give command usually involves data which is called mojangson which lives between two curly brackets “{}” at the end of the give command.
In the swap to 1.18, a lot of the data inside of here has changed, so our job in the migration scripts was to unpack the give command, rename the item it is giving (if applicable), and then adjust the mojangson data to ensure we get the correct enchantments, dye colour, or firework patterns! For the most part it was just a process of substituting in new values within the data, for example in enchanted items (such as the tools on Housing), like potions, we had to swap the enchantment ID to instead use the worded name of the enchantment. For banners, Minecraft weirdly decided to reverse the ordering of colours in the banner data, meaning once where you would have 15 to add a white layer to a banner, it was now 0. To those creating banners, this means nothing as the patterns are usually just copied from online command generators and pasted in to be run, however to ensure that when these commands are re-run they still produce the same banner, we had to update their data. Apart from that there were no real other big changes, except small internal changes, but nevertheless it was a fun insight into the internals of Minecraft mojangson.
Shops
Where we are currently at in our database migration journey is player shops. Shops were another piece of the puzzle we opted to leave until last in fear that we’d be opening a huge can of worms. This is primarily due to the way that we store shop data. In our shops, since we support vanilla items in addition to Potterworld items (CItems), they are stored in a way that links them with direct connection to their contents, rather than a specific ID. This may be helpful in understanding why sometimes in a shop you’ll find different listings of the same item, as usually one may be older than the other and there might be a difference in that item’s data (for instance fixing a typo in the lore, or making it so it cannot be dropped).
However as the listings are saved in that way, they’re linked to their 1.10 data, and not their 1.18 data. This meant that the first task was to download all ~16,000 shop items and generate them into 1.18, before re-saving and updating their IDs, and then reflecting these changes back into the player shops who have the item in stock. However upon doing this we encountered quite a large obstacle. Maps would not load in 1.18, and for some reason were turning to air. For newer players to Potterworld, you may be confused and have never seen a map, however for older players these are quite common. For starters they were the very first instance of Choco Hop Cards, and the original camera output too! We are still unsure why they are not loading in, as we only begun looking at shops this week, however we have plenty of strategies to try and fix their conversions, such as attempting to perform a staggered migration of the item (i.e. load it into 1.11, then 1.12, then 1.13, etc.) to determine what caused it to break and where. This also gives us the chance to do our own tweak to Minecraft’s internals to add whatever support is missing that prevents these items loading in.
It is worth also noting, we also had to make sure to properly rename the materials that we use in the shop categories and blacklists to ensure they all still work on 1.18, even with the renamed items and variants!
1.18 World Migration
All of the above scripts we have made help with one goal, and that is allowing us to pull our current 1.10 Potterworld onto 1.18 at any time, with the most up to date data, and allow it to fully run without any manual conversions. This has saved us lots of time, and as previously iterated, ensures we do not need to place a hold on the current Potterworld during development.
Obviously all that was left in this process was the part that actually pulled the world files from 1.10 to 1.18, so again we made an automatic script to do that! It grabs our current Potterworld map, uses Minecraft’s built in world converter, and also copies across all our configs and database information before running it through the aforementioned conversion scripts, and out pops 1.18 Potterworld! This process is almost entirely without fault, except that when upgrading worlds in Minecraft, they sometimes make what we refer to as ‘illegal blocks’ break. In this sense an illegal block is any block that is placed specially in the world that would not exist in normal vanilla Minecraft, for example floating torches, chorus fruit (our chair and book stack models), and oddly placed pistons (our tables). This means that unfortunately when upgrading the map, a lot of these blocks break, and they need to be manually replaced, but other than that it works relatively well!
The Future
And that brings us to where we are today, still investigating shops. It’s been a busy 6 months, and we’re so proud of the progress we have made. Once we pinpoint the cause of our map problem, we will be moving onto converting other parts of our playerdata such as vaults and then finally player inventories, enderchests and armour.
There is also one remaining elephant in the room (that we know of), and that is the resource pack. We have been hesitant to touch this as of yet simply due to the magnitude of the task ahead of us and the limited number of people who can work on it.
Conclusion
We are sure there are still many tasks we have not thought up of yet, but for now this is where things currently stand, and we are excited to continue to provide more updates over the next few months! We have also been up to a few miscellaneous features and bug fixes here and there alongside our 1.18 work, and those will be detailed in a Development Patch Note that we’ll be sending out tomorrow, so make sure to give it a read!
Finally, we’d like to thank everyone for reading and hope you enjoyed! If you have any questions or want us to expand further on anything discussed today, please do not hesitate to reach out or reply.
Welcome to our second Development Blog of 2025! As the first six months of the year come to a close, we wanted to provide an update on what has already been a busy year of 1.18 work!
Our focus this year has primarily been on continuing our server upgrade work, including staff testing, and as such we will be dedicating this blog solely to recapping our 1.18 efforts. As will be explored in this blog, we turned away from getting our core features working in 1.18 to branching out to the other plugins and systems that help make Potterworld what Potterworld is. This includes ensuring Housing, Magic, MythicMobs, and all our quests, shops, and vaults work on 1.18.
February 2025 Development Blog
In this year’s first blog, we discussed our 2024 achievements, but also announced our plans of upgrading Potterworld to 1.18 instead of 1.16, and the factors behind this decision!
Don't forget you can also check out all of our past Developments Blogs in the Blog Posts folder here!
For this blog, we’ll be covering these topics:
1.18 Plugin Process
1.18 Config Migrations
1.18 Database Migrations
1.18 Word Migration
The Future
Let's go!
1.18 Plugin Process
One of the first things we tackled when upgrading the server was to make sure our minigames and Classes plugins were compatible. We chose to do these ones first as they were quick wins, and didn’t really change much between versions. Think for example in the Classes plugin, that doesn’t really do anything Minecraft version specific, so it was an easy job to change its version and call it a day. In addition to that Minigames (minus Quabbleball) were mostly the same story, they all existed on Minecraft logic that was pretty consistent throughout versions; start a timer, do some actions, calculate points, then award a winner.
Housing
This approach allowed us to get away with not converting Housing yet still feel like we were making significant progress in the upgrade. Unfortunately for us however, this meant Housing remained as the elephant in the room and still had to be converted. So that is what we embarked to do only a few weeks ago. Upgrading Housing was no straightforward job simply due to the way that Housing interacts with Minecraft. This is because we do a lot of things on Housing that are not native to vanilla Minecraft such as not only our sceneries, but also making sure plants don’t grow, snow doesn’t fall, the correct blocks break when you mine them (i.e. ores) and so much more!
Luckily this was all quite straightforward to convert, as our approach has been to make 1.10 code compatible, as opposed to adding in new 1.18 features (yet), thus we did not really need to account for any huge changes, minus any block renames.
That meant that for Housing, the real challenges were: (1) actually setting up the Housing world as this is huge and requires us to make room in our 1.18 environment, and getting it to correctly pull the Housing worlds, and make sure to save them; and (2) getting sceneries to work.
Housing sceneries took quite a bit of time, and required the drawing of a lot of weird diagrams and maths equations. But we got them done, and it was a great feat to tick off. The reason this took the longest is that Housing sceneries are all done manually, we do not use WorldEdit to just //paste in the scenery, each block is manually pasted. In 1.10 this was straightforward with the help of the WorldEdit/FAWE API, however in 1.18, naturally, this API had changed and as such we had to remake our code. Without getting too technical, the biggest challenge was understanding the new API and telling it how and where to load in the new housing sceneries, while ensuring to also delete the older ones. To ensure these are placed correctly, in 1.10 the API would automatically account for the offset of the scenery; this means that it would automatically determine where to start building the scenery with respect to a point on the player’s house and where the scenery lived. However in 1.18 this got removed, which meant we had to manually do the maths to calculate the positional offset of where to start pasting the housing scenery to ensure that it was pasted in the correct area of your world, and not just at some random coordinates. For example if all sceneries are built on a world and their coordinates are 100,100,100, and we copy from the far left corner, we need to ensure that on the housing plot it also places it on the far left corner, even though the coordinates of the plot are not 100,100,100, but more like 28,90,29. That is where the offset comes into effect, however as previously noted, we had to determine this ourselves, which was more complicated than it needed to be!
In addition to that, every scenery also has to be manually migrated and re-saved to a 1.18 compatible format! However with that out of the way, Housing was complete, and the satisfaction received when the scenery was swapped with no pasting errors made it all worth it.
Tab Complete
It is also fitting to give a quick mention to the 1.18 tab complete system. To those who have played on more recent versions of Minecraft, when you open chat and type “/” it brings up a list of every single command in the system. This is not ideal in a lot of ways as firstly it brings up a list of commands that players will never have to use, and secondly it is an absurdly long list that is just overwhelming to look at. As such we had to redo our permission system in such a way that meant in 1.18, you would only see the commands pop up in “/” that you have access to using. Due to the nature of the code, we also had to make this change in 1.10, but as the system does not exist there (really), there was no noticeable difference! We will note that we have not added support for smart tab complete that tells you what words to put where in a command, as again we are only making our code compatible for now, and not leaning into new features just yet!
However unfortunately like all things, we ran into an issue with this system. Our chat channel aliases were showing up in chat as being invalid commands, such as when you did “/l Hello!” as we do not define channel aliases as their own command (in order to keep the channels and their aliases dynamic), but instead had a system that listened for your message, and checked if it referred to a channel, before deleting that message and forwarding it to your channel of choice. To make this work in 1.18, we did have to make each alias its own command, but we did this in a dynamic way. However this did impact 1.10, as each chat channel was now its own command, we did have some overlap in commands with other plugins, thus causing issues such as accessing “/sc” (serpent chat) or “/d” (dark follower chat). For serpent chat, we overwrote the code to make it listen to “/sc” as a priority command, however for dark follower chat, the easiest solution was just to change the channel alias to “/df”.
1.18 Config Migrations
Another challenge we tackled earlier this year was what is referred to as our configs. To put it another way, these are the settings for external plugins that we use on Potterworld such as Magic, MythicMobs, Citizens (NPCs), and WorldGuard. Again it comes as no surprise that these needed migrating to make our 1.10 files compatible with 1.18. To reiterate, we perform migrations so that we do not need to manually update our files every time an update is done on 1.10, but instead make 1.18 automatically convert the files for us. This saves a lot of time and ensures that whilst working on 1.18, we do not need to perform any hard freezes on 1.10 content.
MythicMobs
The first configs we decided to convert were our MythicMobs files. This was important to ensure that our world mobs and quest mobs would work on the 1.18 server as there had been significant adjustments and improvements to the plugin over the years. To facilitate this, we wrote a script that iterates through every file and makes the required changes before uploading to the 1.18 server. Some examples of things we had to migrate were changing the names of the sounds that Mobs make, as some were renamed in 1.18, such as the “block.note.bell” sound our Fairies make which was renamed to “block.note_block.bell”. A small change, but one that makes the difference in whether or not the mob will make any noise when fought.
Other changes included renaming the entity types of mobs where they had changed between versions, as well as the villager professions and equipment that mobs wore (e.g. gold_helmet was renamed to golden_helmet).
Citizens
We also had to do a similar process for the NPCs on our world. The changes in Citizens were much less than that of MythicMobs, however we still needed to tweak the occasional NPC that had a villager profession or a renamed item as its hat or held item.
We also had to fix up the way that skins are applied to NPCs, but thanks to our built-in skin library, it was only a process of making a quick command to use in-game that refreshes and reapplies all the skin values back to the NPCs and saves them!
WorldGuard
Finally for WorldGuard, we only had to make two changes, and that was correcting the commands that are run on players when they step into regions on the world. The two problematic commands were the sound, and effect command. Similarly to above, for the sound command all we had to do was fix the name of the sound being played if a player entered a region, to make sure it was 1.18 compatible. For the effects however, this required more work as the syntax of the command changed. This will become more relevant later as it was a huge change we also had to account in our database for where the effect command was used in quests and on-world content.
That wraps up our config migration scripts. We’re glad we made these as it saves an enormous amount of time and allows Potterworld to continue to evolve whilst we work on 1.18, without needing the manual intervention of fixing every little file in our plugins that was renamed.
1.18 Database Migrations
Command Migrations
Continuing the trend of migrating and renaming changed commands and values, our next obstacle was doing the exact same thing, except this time inside of our 1.18 database copy. There are three main commands that have had to be altered in our 1.18 code, two of which have already been touched on. They are (1) the effect command; (2) the playsound command; and (3) the give command. For each of these commands we had to replace and migrate them in the various places in the database where they are in use, for example in GUI commands, dialogue commands, and even at the start or end of container sequences!
The effect command was the first renamed command that we noticed in 1.18. This was mainly due to its entire syntax changing. Instead of the command in 1.10 being “/effect @pn <effect_details>”, it was now expressed as “/effect <give/clear> @pn <effect_details>”. This meant we had to do a shuffle of the command to ensure that we inserted “give” or “clear” into the command syntax. There was only one other factor we forgot to account for, and that was effect commands that used a number instead of a written effect type. This was the way that it was traditionally done in older versions of Minecraft, for example writing “1” as the effect type would give out the speed effect. However 1.18 now requires us to write out “speed”, so we had to make sure we converted our numbers too! Nevertheless it was nothing we couldn’t handle!
Similarly, the playsound command also changed. As mentioned above in our config migrations, this was not a syntax issue, but rather just the names of sounds changing. This was a relatively easy change to make, as we had already been doing it for all our other migration scripts!
Finally that left us with the dreaded give command. There was a lot to unpack in the conversion of this command, as anyone who has played vanilla Minecraft would know, the give command can do a lot! On the face value the command is very helpful in just giving out vanilla blocks in the Mine Depot on Housing, such as Stone, Wooden Logs, Grass, Diamond Ore, or a Redstone Block. As has likely been previously discussed, in the move from 1.10 to 1.18, a lot of block names have changed, especially the woods, stones and other blocks that have a base but then different variants. An example of this is wool. In 1.10 there is one block “wool” and each colour variant is a data number appended to the end of the block ID, e.g. “wool:6” for “pink_wool”. This means that in the give command we have to account for the renamed block, and the dropping off the data field. However this is only the surface level of the give command, and it does so much more, which we also needed to account for.
On Potterworld our other usages of the command included spawning in firework items, custom skulls, enchanted tools, banners, firework changes, and dyed leather armour. Whilst a lot of these features are no longer used in our commands, quite a few usages still remain spread out both in the Housing Mine Depot and in a lot of helpful staff tools to spawn in items for gameplay. The syntax of the more complex give command usually involves data which is called mojangson which lives between two curly brackets “{}” at the end of the give command.
In the swap to 1.18, a lot of the data inside of here has changed, so our job in the migration scripts was to unpack the give command, rename the item it is giving (if applicable), and then adjust the mojangson data to ensure we get the correct enchantments, dye colour, or firework patterns! For the most part it was just a process of substituting in new values within the data, for example in enchanted items (such as the tools on Housing), like potions, we had to swap the enchantment ID to instead use the worded name of the enchantment. For banners, Minecraft weirdly decided to reverse the ordering of colours in the banner data, meaning once where you would have 15 to add a white layer to a banner, it was now 0. To those creating banners, this means nothing as the patterns are usually just copied from online command generators and pasted in to be run, however to ensure that when these commands are re-run they still produce the same banner, we had to update their data. Apart from that there were no real other big changes, except small internal changes, but nevertheless it was a fun insight into the internals of Minecraft mojangson.
Shops
Where we are currently at in our database migration journey is player shops. Shops were another piece of the puzzle we opted to leave until last in fear that we’d be opening a huge can of worms. This is primarily due to the way that we store shop data. In our shops, since we support vanilla items in addition to Potterworld items (CItems), they are stored in a way that links them with direct connection to their contents, rather than a specific ID. This may be helpful in understanding why sometimes in a shop you’ll find different listings of the same item, as usually one may be older than the other and there might be a difference in that item’s data (for instance fixing a typo in the lore, or making it so it cannot be dropped).
However as the listings are saved in that way, they’re linked to their 1.10 data, and not their 1.18 data. This meant that the first task was to download all ~16,000 shop items and generate them into 1.18, before re-saving and updating their IDs, and then reflecting these changes back into the player shops who have the item in stock. However upon doing this we encountered quite a large obstacle. Maps would not load in 1.18, and for some reason were turning to air. For newer players to Potterworld, you may be confused and have never seen a map, however for older players these are quite common. For starters they were the very first instance of Choco Hop Cards, and the original camera output too! We are still unsure why they are not loading in, as we only begun looking at shops this week, however we have plenty of strategies to try and fix their conversions, such as attempting to perform a staggered migration of the item (i.e. load it into 1.11, then 1.12, then 1.13, etc.) to determine what caused it to break and where. This also gives us the chance to do our own tweak to Minecraft’s internals to add whatever support is missing that prevents these items loading in.
It is worth also noting, we also had to make sure to properly rename the materials that we use in the shop categories and blacklists to ensure they all still work on 1.18, even with the renamed items and variants!
1.18 World Migration
All of the above scripts we have made help with one goal, and that is allowing us to pull our current 1.10 Potterworld onto 1.18 at any time, with the most up to date data, and allow it to fully run without any manual conversions. This has saved us lots of time, and as previously iterated, ensures we do not need to place a hold on the current Potterworld during development.
Obviously all that was left in this process was the part that actually pulled the world files from 1.10 to 1.18, so again we made an automatic script to do that! It grabs our current Potterworld map, uses Minecraft’s built in world converter, and also copies across all our configs and database information before running it through the aforementioned conversion scripts, and out pops 1.18 Potterworld! This process is almost entirely without fault, except that when upgrading worlds in Minecraft, they sometimes make what we refer to as ‘illegal blocks’ break. In this sense an illegal block is any block that is placed specially in the world that would not exist in normal vanilla Minecraft, for example floating torches, chorus fruit (our chair and book stack models), and oddly placed pistons (our tables). This means that unfortunately when upgrading the map, a lot of these blocks break, and they need to be manually replaced, but other than that it works relatively well!
The Future
And that brings us to where we are today, still investigating shops. It’s been a busy 6 months, and we’re so proud of the progress we have made. Once we pinpoint the cause of our map problem, we will be moving onto converting other parts of our playerdata such as vaults and then finally player inventories, enderchests and armour.
There is also one remaining elephant in the room (that we know of), and that is the resource pack. We have been hesitant to touch this as of yet simply due to the magnitude of the task ahead of us and the limited number of people who can work on it.
Conclusion
We are sure there are still many tasks we have not thought up of yet, but for now this is where things currently stand, and we are excited to continue to provide more updates over the next few months! We have also been up to a few miscellaneous features and bug fixes here and there alongside our 1.18 work, and those will be detailed in a Development Patch Note that we’ll be sending out tomorrow, so make sure to give it a read!
Finally, we’d like to thank everyone for reading and hope you enjoyed! If you have any questions or want us to expand further on anything discussed today, please do not hesitate to reach out or reply.