Hello everybody!
Welcome to our first Development Blog of 2024! It’s been a hot second since our last blog, but nevertheless we’ve been hard at work. Since our last blog in July of last year, we have made significant progress on our 1.16 server upgrade, our Discord Bot, and various other quick wins along the way!
If you are interested in seeing our last 1.16 progress update or find out more about the Discord Bot revamp we are doing, please make sure to read our July 2023 Development Blog.
July 2023 Development Blog
In our last blog we spoke about our latest hurdles encountered as part of our 1.16 rewrite and how we addressed them. We also gave an insight into the new position of JavaScript Developer and outlined our goals for the Discord Bot rewrite.
For this blog, we’ll be covering these topics:
Our Recent Achievements
1.16 Progress Update
Discord Bot Progress Update
The Future
Let's go!
Our Recent Achievements
Our main focus of 2023 was to work away on our 1.16 upgrade. However that didn’t mean we turned our attention away from important server upkeep tasks and fun QOL additions!
Minigame Lag
Earlier this year we significantly overhauled the way we set up our minigame servers in order to address serious lag issues. Players would frequently report that upon joining minigames they would be hit with huge lag spikes. Ultimately this was caused by the way we loaded data into our minigames.
In every server that is created, it is important that we load in the key data from our database that helps Potterworld function. These are the things such as all our items, and all our interactions (anything that you can click, see sparkle, or see a hologram on). However as the server grew, so did the amount of data we had to load in. In these cases it meant loading in around 32,000 interactions and well over 19,000 custom items. Trying to load this much data, at the same time as loading in a map, and spawning in players was putting a huge demand on the server. This led to huge lag spikes.
In order to combat this, we made quite a “simple” fix, which was to make sure that we don’t load players into minigames until we have loaded all items, interactions and the map itself. It is clear this change had a huge impact on addressing the lag spikes, and we’re glad we finally got around to changing it!
Friends, Party Members, and Guild Members Locations
Before the end of last year, we pushed out a mini QOL update to our friends, parties and guild modules. This was adding the ability to see what your friends were doing if they were in class or in minigames. We found it not very useful to be told your friend is in “Class 1” or “MG 1”, and instead we made it possible for your friends/guilds/parties list to instead show that your player might be in “In Class (Wizarding Law)” or “Playing Party Games”!
Housing Resets
Our most recent release was of the Housing Resets in collaboration with the Store team. Housing Resets is something we’ve had planned for quite a while, but the opportunity arose between tasks, and we seized the moment. The reset allows for you to completely wipe your housing plot back to its default island, in order to start building again. We hope this helps make the task of knocking down those 2016-themed mega mansions a little bit easier!
1.16 Progress Update
In our last update we spoke about the challenges we faced when needing to tweak our code base so that we could have 1.10 and 1.16 contained within the same plugin. By doing this, it paved the way for us to merge our 1.16 code into our current 1.10 branch, which we have successfully done on two occasions now. What this means is, our 1.10 code and 1.16 code mirror each other, and if we need to make a fix to something that exists in both versions, we only need to change it once!
With that out of the way we moved onto our next set of goals. That was to get a proper 1.16 server up and running, that went beyond the small hub that we teased a few months ago. If you don't remember that preview, you can see it here! Since then we did successfully get an exact replica of our current 1.10 world up and running in 1.16. It looks a bit weird at the moment, but that is to be expected with all the new blocks that were added in recent Minecraft versions.
That segues nicely into our next challenge, which is, Minecraft likes to change the names of their blocks. We addressed this in a previous blog where we had to change all the references of items such as DIAMOND_SPADE to DIAMOND_SHOVEL in our code, but we still had all the references to the 1.10 material names in our database. These references exist everywhere you see an icon in game (such as in a GUI), as these have been manually entered by our staff members into our Admin Panel where the tech is made. We spoke about how these GUIs are created back in the July 2022 Development Blog, we recommend the read!
Obviously we needed to change all these items, or else they wouldn’t show in 1.16, and we’ll just have invalid items showing everywhere in GUIs. Thankfully we already had existing code that allowed us to convert items from their 1.10 names to 1.16 names during runtime. Yet we still ran into issues where items wouldn’t show, and this was due to… typos! Our first job was to normalise all our 1.10 data. This meant doing general cleanup to ensure two things: (1) all items are capitalised; and (2) we remove any ‘bogus’ items. We refer to ‘bogus’ items as items where they are missing a variant (e.g. BED should be BED:0) or have a redundant one (e.g. BEETROOT:5 where only BEETROOT exists). This normalisation has ensured that it is easier for us to eventually run one huge script over our entire database to convert all 1.10 names to 1.16.
With the database normalisation complete, we put that to one side and moved onto our next set of challenges. That is, items that we save completely with all their minecraft data (such as your bags, mail, shops and more), as opposed to our tech references which are just a material ID. The way we currently save items is that we convert them to a base64 version of themselves. However this was not the most efficient way of saving items, as now that we are changing minecraft versions, and items change, they won’t match up anymore, and some items might not even properly load (such as Monster Spawn Eggs). It’s for this reason that we made the decision to change the way we store items in our database to be in a json friendly structured version. Using an item converter that was written by our former Head of Development, Deniz, we have been able to convert items from their base64 version to instead a cleaner, more readable, and more scalable json structured version! This new structure also makes it easier to rename item materials as they change in Minecraft, as opposed to being unable to make changes as the entire item was encoded in base64.
An example can be seen below:
Welcome to our first Development Blog of 2024! It’s been a hot second since our last blog, but nevertheless we’ve been hard at work. Since our last blog in July of last year, we have made significant progress on our 1.16 server upgrade, our Discord Bot, and various other quick wins along the way!
If you are interested in seeing our last 1.16 progress update or find out more about the Discord Bot revamp we are doing, please make sure to read our July 2023 Development Blog.
July 2023 Development Blog
In our last blog we spoke about our latest hurdles encountered as part of our 1.16 rewrite and how we addressed them. We also gave an insight into the new position of JavaScript Developer and outlined our goals for the Discord Bot rewrite.
For this blog, we’ll be covering these topics:
Our Recent Achievements
1.16 Progress Update
Discord Bot Progress Update
The Future
Let's go!
Our Recent Achievements
Our main focus of 2023 was to work away on our 1.16 upgrade. However that didn’t mean we turned our attention away from important server upkeep tasks and fun QOL additions!
Minigame Lag
Earlier this year we significantly overhauled the way we set up our minigame servers in order to address serious lag issues. Players would frequently report that upon joining minigames they would be hit with huge lag spikes. Ultimately this was caused by the way we loaded data into our minigames.
In every server that is created, it is important that we load in the key data from our database that helps Potterworld function. These are the things such as all our items, and all our interactions (anything that you can click, see sparkle, or see a hologram on). However as the server grew, so did the amount of data we had to load in. In these cases it meant loading in around 32,000 interactions and well over 19,000 custom items. Trying to load this much data, at the same time as loading in a map, and spawning in players was putting a huge demand on the server. This led to huge lag spikes.
In order to combat this, we made quite a “simple” fix, which was to make sure that we don’t load players into minigames until we have loaded all items, interactions and the map itself. It is clear this change had a huge impact on addressing the lag spikes, and we’re glad we finally got around to changing it!
Friends, Party Members, and Guild Members Locations
Before the end of last year, we pushed out a mini QOL update to our friends, parties and guild modules. This was adding the ability to see what your friends were doing if they were in class or in minigames. We found it not very useful to be told your friend is in “Class 1” or “MG 1”, and instead we made it possible for your friends/guilds/parties list to instead show that your player might be in “In Class (Wizarding Law)” or “Playing Party Games”!
Housing Resets
Our most recent release was of the Housing Resets in collaboration with the Store team. Housing Resets is something we’ve had planned for quite a while, but the opportunity arose between tasks, and we seized the moment. The reset allows for you to completely wipe your housing plot back to its default island, in order to start building again. We hope this helps make the task of knocking down those 2016-themed mega mansions a little bit easier!
1.16 Progress Update
In our last update we spoke about the challenges we faced when needing to tweak our code base so that we could have 1.10 and 1.16 contained within the same plugin. By doing this, it paved the way for us to merge our 1.16 code into our current 1.10 branch, which we have successfully done on two occasions now. What this means is, our 1.10 code and 1.16 code mirror each other, and if we need to make a fix to something that exists in both versions, we only need to change it once!
With that out of the way we moved onto our next set of goals. That was to get a proper 1.16 server up and running, that went beyond the small hub that we teased a few months ago. If you don't remember that preview, you can see it here! Since then we did successfully get an exact replica of our current 1.10 world up and running in 1.16. It looks a bit weird at the moment, but that is to be expected with all the new blocks that were added in recent Minecraft versions.
That segues nicely into our next challenge, which is, Minecraft likes to change the names of their blocks. We addressed this in a previous blog where we had to change all the references of items such as DIAMOND_SPADE to DIAMOND_SHOVEL in our code, but we still had all the references to the 1.10 material names in our database. These references exist everywhere you see an icon in game (such as in a GUI), as these have been manually entered by our staff members into our Admin Panel where the tech is made. We spoke about how these GUIs are created back in the July 2022 Development Blog, we recommend the read!
Obviously we needed to change all these items, or else they wouldn’t show in 1.16, and we’ll just have invalid items showing everywhere in GUIs. Thankfully we already had existing code that allowed us to convert items from their 1.10 names to 1.16 names during runtime. Yet we still ran into issues where items wouldn’t show, and this was due to… typos! Our first job was to normalise all our 1.10 data. This meant doing general cleanup to ensure two things: (1) all items are capitalised; and (2) we remove any ‘bogus’ items. We refer to ‘bogus’ items as items where they are missing a variant (e.g. BED should be BED:0) or have a redundant one (e.g. BEETROOT:5 where only BEETROOT exists). This normalisation has ensured that it is easier for us to eventually run one huge script over our entire database to convert all 1.10 names to 1.16.
With the database normalisation complete, we put that to one side and moved onto our next set of challenges. That is, items that we save completely with all their minecraft data (such as your bags, mail, shops and more), as opposed to our tech references which are just a material ID. The way we currently save items is that we convert them to a base64 version of themselves. However this was not the most efficient way of saving items, as now that we are changing minecraft versions, and items change, they won’t match up anymore, and some items might not even properly load (such as Monster Spawn Eggs). It’s for this reason that we made the decision to change the way we store items in our database to be in a json friendly structured version. Using an item converter that was written by our former Head of Development, Deniz, we have been able to convert items from their base64 version to instead a cleaner, more readable, and more scalable json structured version! This new structure also makes it easier to rename item materials as they change in Minecraft, as opposed to being unable to make changes as the entire item was encoded in base64.
An example can be seen below:
JSON:
{
"material": "DIAMOND_HOE",
"amount": 1,
"damage": 36,
"nbt": [
{
"tagType": 3,
"key": "HideFlags",
"value": 63
},
{
"tagType": 3,
"key": "Damage",
"value": 36
},
{
"tagType": 1,
"key": "Unbreakable",
"value": 1
},
{
"tagType": 1,
"key": "keep",
"value": 1
},
{
"tagType": 10,
"key": "wand",
"value": [
{
"tagType": 8,
"key": "owner",
"value": "Harrison"
},
{
"tagType": 8,
"key": "template",
"value": "warpkeybag"
},
{
"tagType": 3,
"key": "version",
"value": 7
},
{
"tagType": 8,
"key": "owner_id",
"value": "432786a4-3c59-455e-a930-9aca489827c4"
}
]
},
{
"tagType": 1,
"key": "unstashable",
"value": 1
},
{
"tagType": 1,
"key": "undroppable",
"value": 1
},
{
"tagType": 10,
"key": "display",
"value": [
{
"tagType": 8,
"key": "Name",
"value": "{\"extra\":[{\"italic\":false,\"color\":\"dark_aqua\",\"text\":\"Warp Key\"}],\"text\":\"\"}"
},
{
"tagType": 9,
"key": "Lore",
"value": [
{
"tagType": 8,
"value": "{\"extra\":[{\"bold\":false,\"italic\":false,\"underlined\":false,\"strikethrough\":false,\"obfuscated\":false,\"color\":\"aqua\",\"text\":\"CLICK \"},{\"italic\":false,\"color\":\"gray\",\"text\":\"here to open your warp menu.\"}],\"text\":\"\"}"
},
{
"tagType": 8,
"value": "{\"extra\":[{\"bold\":false,\"italic\":false,\"underlined\":false,\"strikethrough\":false,\"obfuscated\":false,\"color\":\"gray\",\"text\":\"\"}],\"text\":\"\"}"
},
{
"tagType": 8,
"value": "{\"extra\":[{\"bold\":false,\"italic\":false,\"underlined\":false,\"strikethrough\":false,\"obfuscated\":false,\"color\":\"dark_gray\",\"text\":\"Category: Travel\"}],\"text\":\"\"}"
}
]
}
]
}
]
}However this too has led us to our next obstacle which is that some systems require a huge rewrite in order to facilitate the change of data structure. This is mainly the case for our shops system, which uses a hash of the base64 item as its primary ID for all items. By removing references to the base64 string of items, it means that our shops will no longer be able to run, and we’ll have to redesign a system that supports a new way of saving shop items by a different ID.
As a result our goals for the next few months will be to finish converting all items to use the new structure (mail, vaults, player bags and minigame items), rewrite our shops system, and deal with player inventories. After that our attention will be turned to upgrading our other plugins that we use, both in-house ones (such as minigames and housing), and third party ones (such as WorldEdit).
Discord Bot Rewrite Progress Update
In the last Development Blog, we mentioned wanting to rewrite our discord bot in JavaScript. This has been started after some time of thinking about design choices and features we want to keep. We started out by making a list of all commands of the discord bot and setting priorities for each command. This helped us decide what commands we should work on first, and what commands we don’t want anymore, as some are unused or don’t provide any value to the team.
Next up, we had to decide if we wanted to stick to prefix-based commands or switch over to slash commands. We ended up deciding to rewrite the commands as slash commands. This allows us to easily set up commands with various options. These options can be text, numbers or even channels. This helps us receive extra details when you use a command, such as the name of a player for the player command. It also makes it easier for us to set permissions for commands, making it so you can only see the commands you can use.
After the design stage was complete, we began coding! We decided to use a framework called Sapphire, built on top of discord.js. It made our job of coding the discord bot a lot easier! We didn’t have to worry about complex systems of the bot such as the command handler, because Sapphire has made one for us. A command handler is essentially a way for us to separate our commands in different files. The command handler listens for commands and directs them to the right part of the bot’s code. Being able to keep commands in different files keeps the code organised and lets us easily find the code of a specific command when we need it. So instead of worrying about a system like this, we could focus on working on commands and other features.
With that out of the way, we were able to start working on some easy commands to better our understanding of Sapphire and working with slash commands. Some of these commands include ‘player’ (receiving a player’s in-game information), ‘spells’ (getting a list of all spells on the server), and ‘gear’ (finding gear pieces with their stats). For some of these commands, we had to use our public API to get the data from our database. After getting more used to working with this framework, we started working on a staff release to allow staff to test the different features of the bot. When all of this has proved to be a success, we will continue to rewrite all the remaining features that are accessible to our players.
Now what’s next for our bot? We’re working towards rewriting more commands and features to JavaScript. After this has been done, we will have time to look into adding exciting new features! One such feature could be to receive notifications on Discord of something that happens on the PotterworldMC Minecraft server, like receiving a message from the bot when someone makes a purchase from your shop, or when your daily quests reset. There are a lot of opportunities here.
The Future
There’s not much that we have to add for this section! At the moment our current roadmap is predominantly occupied by 1.16 for our Java Developers, and the new Discord Bot for our JavaScript Developers.
As always however we are always open to receiving new suggestions from players, as well as your thoughts and feedback on things you would like to see the Developer team do!
Conclusion
That concludes our blog for today. We hope you enjoyed reading our updates, and we look forward to delivering more in the near future! We look forward to seeing you in the next Development Blog, bye for now.
