SurviveTheNight

Hi!

This is the fourth devlog! In this thread I will talk about our creatures system, how creatures work in STN and what has changed (so far).

Introduction

Welcome to the first devlog about creatures. Atleast one more devlog about creatures follows after this!
Today I will introduce you to creatures in STN, how they work, what we have changed so far and what features might come up in the future!
I will not cover boss monsters in this devlog, there will be a seperate one specifically for those in the near future.

Minecraft Entities

Before talking about our creatures specifially, I want you to understand how entities and livingentities work in spigot (the server we are working with basically).

Let's talk about Ironic Golems for example - the annoying iron golems you may spawn by mining ores, that deal far too much damage and shoot iron bolts at you, do you remember?

You may have noticed: They attack you by default without you having to hit them and they also only attack you. No other players, not even other enemies like vanilla iron golems would do.

The Spigot API provides a set of very useful methods, especially when working with entities in minecraft. For example you can spawn them in at certain locations, give them a name, set certain attributes such as setRemoveWhenFarAway() (this basically allows you to keep entities where they are even when the chunks are not loaded) and much much more.

However there are almost no methods to properly change the AI of those creatures!
And now NMS comes into play!

What is NMS? NMS stands for net.minecraft.server and is basically a bunch of code provided directly by Mojang and contains all the important stuff such as server packets, client packets and everything else that's happening on the server.

Working with it allows you to do many many more things compared to the spigot API due to that API being very limited at the time of 1.8, however it also brings many possible issues with it.
Since you're somewhat directly communicating with the client when sending certain packets, you must be really careful when creating those sent packets.
Usually if something goes wrong when using the spigot API, it would just create an error in the log and the code after would not be executed anymore. The player however wouldn't notice too much apart from some features not working or an error message popping up.
When working with packets, if one packet is configured incorrectly, the player will at least get kicked from the server, and in some cases, the recipient's entire game may crash!

NMS also contains a bunch of entity-related things such as PathfinderGoals and allows you to change them.
Therefore we are using NMS to change the vanilla's behaviour of entites and change them as we like!

STN Creatures

STN Creatures are really complex. Not only do they have custom set attributes such as health, defense, damage values etc, but they also have custom appearance, particles, sounds and some even have custom behaviour and attacks.

Some STN Creatures don't even look like enemies but instead more like a player (Winter Mining Creatures or Inquisitive Agarics for example).
Those are even more complex because their behaviour has to be copied onto a player model.
An Inquisitive Agaric is made of 3 main pieces:

• The Nametag, an invisible ArmorStand without any hitbox.
  • Why an ArmorStand you may ask? ArmorStands are the only entity in 1.8 that when setting a custom name to them, they would still show it even when not directly looking at the entity.
• The Player Model which has all the animations such as hitting, taking damage, burning, dying and so on. This Player Model doesn't  have any AI.
• An invisible zombie which controls the Player Model. The zombie is modified with our custom PathfinderGoals.

As well as that, most entities are muted in this game. Meaning they don't play their default vanilla hit, death and idle sounds but instead received custom ones from us.

The main creature (the zombie in the case of the inquisitive agaric) then would receive all the mob tags such as which and how much skill exp to drop, which items you may drop from it and their drop chances, damage stats, defense stats, which bestiary to increase on kill and so on.

All of these tags are evaluated when hitting the creature or killing it.
Unfortunately though our current system was pretty bad for that:
In spigot certain events are getting triggered when certain things happen, such as hitting an entity.
So far we have used that one event and checked the hit entity, check if it has custom tags and then calculated loot, damage and everything else.
The class containing the event has well over 2,000 lines of code.

The Creature class itself only contains the custom attacks, setting up the creature and the appearance such as the nametag, custom armor, the player model and particle effects.

The new system

The new system is much better. Every creature now extends an overall Creature class which manages everything. It manages what happens when the creature is being hit, what happens when the creature dies, all the attributes and creature stats, behaviour and so on.

Let's say we want to add the Ice Guard creature to STN:
All we'd have to do now is creating an ICEGUARD object containing all the basic information (Health, Defense, Mob Level, Loot Table, etc.):

ICEGUARD("§bIce Guard", 500L, 100L, 200L, 0.15D, false, new AppearanceContainer(EntityType.SKELETON, true, "SkinData",
            "SkinData"),
            null, SkillType.MINING, 15L, 7, IceGuard.class, new SoundContainer(Sound.HURT_FLESH, 1f, 1.1f), new SoundContainer(Sound.GLASS, 1f, 1f), new SoundContainer(Sound.CAT_PURR, 1f, 1.7f), false, false, new ModifierContainer[]{new ModifierContainer(MobModifiers.FROZEN, null, false, true, false)}, true,
            new LootTableContainer[]{new LootTableContainer(Items.ICE, new int[]{2, 3, 4}, 1_000_000_000, false, null),
                    new LootTableContainer(Items.BRIGHT_CRYOCHUNK, new int[]{1, 2, 3}, 1_000_000_000, false, null),
                    new LootTableContainer(Items.BLOOD_FRAGMENT, new int[]{1}, Creature.getBloodFragmentOdds(7), true, ConsumableBuffs.MAGICALFISH)},
            new LootObjectContainer[]{new LootObjectContainer(Ender.class, 33, null, true)}, 240, 0);

And an IceGuard class which extends our Creature class:

class IceGuard extends Creature {

    @Creatures
    public IceGuard(Location location, boolean playerSpawned, boolean playerBound, Player player, boolean defaultBehaviour, boolean vector){
        super(CreatureTypes.ICEGUARD, location, EntityHeight.NPC, player, playerSpawned, playerBound, defaultBehaviour, vector, Bestiary.MLICEGUARD);
    }

    @Override
    public void kill(double damage, DamageTypes damageType, Player player) {
        super.kill(damage, damageType, player);
        // Add custom behaviour for when this creature is being killed
    }

    @Override
    public void setPathFinderGoals() {
        // Setting PathfinderGoals
    }

    @Override
    public void keepCreatureInBounds() {
        if(!isPlayerSpawned()){
            new BukkitRunnable(){
                public void run() {
                    // Keep Creature in bounds (Teleport them back to their spawnlocation when they leave their respective area)
                }
            }.runTaskTimer(Core.getPlugin(Core.class), 10, 10);
        }
    }
}

As you can see it is not too much code for a creature as complex as the Iceguard. The Iceguard would already be registered on the server and has the default hit behaviour and kill behaviour any other creature has.

If we want to customize it a little more we could just take some of the methods and override it with the needed code.

In the actual event listener (which contained the 2,000 lines of code prior to the new system) only the hit method of the creature is called as that contains all the behaviour, loot dropping and everything else we need to handle creature hits and kills.

This makes the code much more effective, easier to modify and makes it much easier for us to add new enemies to the game.
It also allows us to modify creatures when spawning them in. For example we're able to make them playerbound or even disable their custom attacks which couldn't be done that easily with the old system.

Upcoming Features

Due to the overall improvements of that system, we are able to implement some more features we wanted to add for a while but weren't possible due to the sheer complexity of the previous code.

- Lootshare
I have started a poll on the discord server yesterday asking you guys if you'd like to see an overall Lootshare system for most creatures of STN.

At the time of writing this devlog 9 of you voted for yes, so it's looking good!

Lootshare has already been a thing for sewer monsters but it was hardcoded and ONLY affected them. With the new system we are now able to easily implement that system to all the other creatures (apart from bosses)!

The lootshare system would reward the top players who helped in killing the creature with the same loot, however the dropchances would be much lower!

The lootshare system would not affect playerbound creatures such as mining creatures as other players are not supposed to hit it!

- Other Damage Causes
As you may have seen in one of the more recent sneak peeks on the discord server, I have added more damage causes to entites apart from just playerdamage, magicdamage and explosion damage! They now suffocate, take fall damage, drown and so on!
This allows us to add more custom items and enchants that apply poison to an enemy for example!

We are also able to add bows to the game now since entity damage is no longer 100% playerbound anymore and they may take damage from other souces as well!

Conclusion

The new system allows us to handle creatures in a much better and easy way. We are able to customize them a little bit better, modify existing ones and add new ones without many issues!

We don't have to copy-paste code anymore (Which you shouldn't do in general when coding in an OO programming language) and don't have to check code for 100% correctness as most code is only written once and automatically adopted to custom creatures and behaviour by the program.

STN Creatures aren't 100% done, bosses haven't been touched yet. Due to that the code I presented you may not be final and might be changed.

Systems that must still be reworked

This is more like a checklist with systems that will probably receive their own devlog once they're done.

• Items
• Achievements (abt 80%)
• STN Creatures (abt 70%)
• Inventories
• NPCs

Hi!

This is the third devlog! In this thread I will talk about our crafting system and how it has been improved.

Introduction

I didn't plan on writing a devlog about our crafting system, however many people have complained about it in the past, many things have been improved just now and the mechanics behind it are actually quite interesting.

Crafting System

As you probably could've guessed, our crafting system is completely custom. We don't rely on the vanilla crafting table and it's abilities and all recipes are self-made.

Why don't we use the vanilla crafting system? Minecraft is a little bit weird when it comes to crafting. Can you think of a vanilla recipe that requires more than just one single item on a slot? Like there is no recipe that requires putting multiple of the same item on a single slot to craft an item. And plugins don't allow us to do that either!

There are ways of creating custom recipes, however you cannot make it so players must put more than one item in a slot - and this would become an issue in terms of item cost and recipe possibilities.
Therefore we haven't had any other choice but making our own crafting system!

Our custom crafting system is made out of 5 core parts.

• The Crafting GUI: This is the menu you see when opening the crafting table. It doesn't look like the vanilla crafting table but instead is made out of a normal inventory with a bunch of glass panes.
  
  
• Recipe Data: All of our recipes are saved in custom recipe objects. They contain the items required on each slot, if items should be updated when being crafted (such as item modifiers), which item you should receive when crafting it and what it requires to unlock the recipe.
  
  
• Inventory Updater: This is basically a scheduler running in the background for each player having the crafting gui open. It checks all 9 slots of the crafting grid, checks all registered recipes and if it finds a matching recipe it displays the output item using the item updater.
  
  
• Item Updater: This basically checks for the item with the highest "modifier priority". Most recipes have an item which has modifier priority.
  For example when upgrading an axe, you not only need random materials but also the previous axe which may have custom modifiers (such as Bat-Suffused) applied to it. That item would become the item with the highest modifier priority. The Item Updater then takes all modifiers of that item and applies them to the item you're about to craft.
  
  
• Crafting Listener: This is a basic inventory listener which is getting triggered upon interacting with the menu. It blocks all sorts of dupes, checks the click and clicked slot and removes items upon crafting from the crafting gui so that you cannot craft items for free!

All of these systems must work without any flaws, otherwise it may lead into you being able to dupe items while crafting!

Registered Recipes

As already mentioned, our custom recipes are registered in seperate objects containing all the data required for crafting and displaying the recipe.

This is what a recipe looks like:

EXOTIC_AXE(new RecipeItemStack[]{item1, item2, item3,
            item4, item5, item6,
            item7, item8, item9},
            false, new RecipeLock(RecipeTypes.EXOTIC_AXE, -1), true, Items.EXOTIC_AXE, 1),

Item1-9 are sets of data containing the item, the amount and if it should have the modifier priority or not. They may also be "null" in case an empty slot should be in that recipe.

The bottom row contains data such as if the recipe should be unlocked by default, if not what the requirement should be, if the item should receive a modifier update when being crafted (only necessary for items that may actually have modifiers), what item the output item should be and how many of them you receive.
Pretty simple right?

Inventory and Item Updater

The inventory updater doesn't do anything special.
As already said it iterates through all registered recipes and compares them with the 9 slots of your current crafting gui. If it found a matching recipe it creates an output item using the item updater, adds some additional data to it and repeats the entire process.

The Item Updater receives the default output item (without anything on it) and then applies all modifiers of either the item with the modifier priority on it or the first item in the crafting grid.
If - for whatever reason! - there isn't an item in the grid, it just returns the default item.

This is what the updater basically looks like:

private ItemStack updateModifiers(ItemStack outputItem, CraftingRecipes recipe, Inventory inventory){
        int[] slots = new int[]{10, 11, 12, 19, 20, 21, 28, 29, 30};
        for(int i = 1; i  9; i++){
            if(recipe.getItemOnSlot(i).isHighestModifierPriorityOnCraft()){
                return new ItemUtils().createItemByOriginal(inventory.getItem(slots[i-1]), outputItem);
            }
        }
        for(int slot : slots) {
            if(inventory.getItem(slot) != null && inventory.getItem(slot).getType() != Material.AIR){
                return new ItemUtils().createItemByOriginal(inventory.getItem(slot), outputItem);
            }
        }
        return outputItem;
    }

Crafting Listener

The Crafting Listener is probably one of the most important systems. Not only does it allow you to actually craft items, but it also blocks any kinds of item dupes regarding crafting.

It checks the type of inventory click you're performing (e.g. leftclick, rightclick, shiftclick), it checks what item you have on your cursor, it checks clicked slots and it checks other inventory actions such as if you're trying to collect items to your cursor (basically when you double click with an item on your cursor and it merges all identical items of the entire inventory with the ones on your cursor).

Upon crafting an item it checks wether you shift-clicked or not, then removes all unnecessary data from the output item and either gives you one set of items or as many as you may craft.

After that it simply just removes the used items from the crafting grid and that's it!

Improvements

So as you could probably guess, if there's one thing that goes wrong, this entire system may lead into massive issues with dupes or performance. However I have made some improvements to it!

Over the past few months, one of STN's biggest flaws was probably the crafting system. You could only craft one set of items at a time, then you'd have to wait for like .5 seconds, then you can craft another set. I've received a lot of feedback, what I could add in addition to make crafting less painful and how this system needs a change and here are the changes:

• Due to our new item system and improvements in recipe registration, the server no longer needs .5 seconds delay in order to check recipes and display the output item correctly
• There is no longer a cooldown on crafting items
• You may now shift click with any item on your cursor to immediately craft as many items as you can instead of just one set of items
  • If your inventory is full, is getting cancelled
  • Non-stackable items are not affected by this! You may only craft one non-stackable item per click!
• Instead of blocking the click, you may now click on the output item with the same item on your cursor to increase the amount of the items on your cursor
• The modifier checker has been improved so it doesn't come to future issues when upgrading tools/weapons/armor

Conclusion

The crafting system may look simple for you guys but in reality it isn't! In fact this might be one of STN's most complex systems as basically nothing relies on the default minecraft crafting mechanics!

The crafting system is still not 100% done just yet, however it's looking promising!

Systems that must still be reworked

This is more like a checklist with systems that will probably receive their own devlog once they're done.

• Items
• Achievements (abt 80%)
• STN Creatures
• Inventories
• NPCs

Hi!

This is the second devlog! In this thread I will talk about our achievements, inventories and what could be some upcoming features.

Introduction

It's been a while since the last devlog - however nothing worth mentioning happened.
About 85% of the database connections have been reworked, as well as several core functions, features and behind-the-scenes stuff (which can now easily be implemented to front-end stuff such as GUIs (inventories) or chat messages etc.)

Achievements

Achievements have been a major issue in the current code of STN - simply just because they were pretty much hardcoded.

Hardcoded basically means that something is coded specifically for one situation and the same code cannot be used for a similar situation unless you copy-paste it. And as you may have guessed: This causes massive issues when working on a giant project such as STN.

Why was it hardcoded? The achievements system and its code were one of the first systems made for STN. You probably noticed that every achievement currently in the game is only achievable in dungeons, there is not a single achievement for the main lobby or any other area of the game.
The achievements were introduced with STN v2.2, that was two or three content updates before STN was public for the first time to all players. The main lobby didn't even exist back then!

We didn't really think STN would become this complex at that time and my coding skills were way way worse than before, so I thought hardcoding these would be totally fine!

The achievements are still not 100% reworked, however they are no longer hardcoded and new achievements should be much easier to add and existing achievements are easier to modify and work with now.

Inventories and Shops

Inventories and Shops are one of the core parts of the front-end of STN, simply because minecraft doesn't offer many other ways of displaying things and of letting players interact with stuff, therefore reworking these was quite an essential thing to do.

Just image: Every single inventory was coded manually before, there wasn't any layout (even tho many inventories look pretty much the same ingame). And that would get quite annoying to do every single time we needed a new inventory!

Same thing goes for shops: I had to add every item to a shop manually, define its price and then create a listener for each item individually, check its item price manually, check if a player could even hold it in their inventory and then add it.
This would also become quite annoying to do (considering the amount of items we have in shops right now), also maintaining shops, changing prices of items etc. would become a time-consuming task.

This is why I finally added templates for inventories and shops. They now rely on a pre-built inventory which only requires a couple information to create (just as inventory size, if it's a shop or no and so on).

After that I can simply just add the inventory-specific items to it and that's it!

Shops rely on pretty much the same layout, however they are slightly different as they also have to contain the "Sell Item"-item or the recently sold item for item buyback depending on if you sold something or not.
However for shops I just have to create a ShopItem instance which contains the price, the item amount and everything else required for buying an item.
All of these shop items listen to the same listener, so that I don't have to create one manually.
Sounds good right? Yes! I really don't know why I haven't done this earlier.

More things changed

This obviously wasn't everything I have done since the past dev-log. I have reworked the scoreboard system and reworked many many other systems such as our custom recipes.

The new recipe system for example would allow us to add some sort of quick crafting.
As well as that you could potentially now also click on items in recipe overviews to check how they are crafted instead of having to go back to their respective collection.

Many many more things have been reworked which are now ready to be implemented to GUIs etc, however I won't go over all of them as that'd take too long.

Upcoming features

None of these features are guaranteed to find their way into STN, however they might!

- Extra Item Attributes
We would like to track more information of your items ingame! Therefore we might add some more NBTs to your items (non stackable items are affected only!):

• Origin Tag: This would contain information on where you obtained the item (e.g. Crafting Table, Dungeon Loot Chest).
• Item Date Tag: This would contain the exact timestamp on when you obtained the item.

Not sure on how you'd profit from that, however future updates might use that data to your advantage.

- Modifying ingame appearance
I already stopped several things from being hardcoded that are part of your appearance ingame.
For example the STN Level icon (☬).

I have added methods to the code which allow us to change the icon for either everyone or a specific player.
This could become an official feature of STN where you might be able to customize your STN Level icon (visible for everyone) by achieving certain things ingame or unlock new icons by progressing in the game.

- Pre-generated Dungeon maps
Soon after the backend changes are completed, I want to experiment with a way of pre-generating dungeon maps.

You may have noticed the major lag when joining a dungeon instance and starting it. This is caused by the server generating a random dungeon, preparing all locations and finding a path through it and as there are several million blocks affected by this, this lags the server for quite a while.

This can be really annoying when you want to do some fast runs and actually grind, as that's like a minute of downtime.

I want to experiment with a pre-loading system, which generates a couple maps on a seperate server and then just takes one of the already generated maps when a dungeon instance is requested. After that the external server generates another map to keep up but you won't notice the generation as it happens on a completely different server! This way you would get your dungeon map immediately without any lag or having to wait for the server to generate anything!

- API
This feature might not be available for a while if we decide to actually do it, however some people already requested an API or client-side mods for STN.

However since I am busy with working on the game itself and I don't know anything on how to code minecraft modifications, I am not able to provide any official QOL STN mods.

With adding an API to the game you guys would be able to do so!
This API would contain most core information about the player, such as storage, any types of currencies, quest progress, dungeons and much more!

With that information some creative minds out there could create something really nice for STN - however these modifications will most likely not be official and confirmed by us, so you'd rely on other players!

Conclusion

A lot of what was to do has been done already, however we are not quite at the end just yet!
I will keep you updated however!

Systems that must still be reworked

This is more like a checklist with systems that will probably receive their own devlog once they're done.

• Items
• Achievements (abt 80%)
• STN Creatures
• Inventories
• NPCs

Hi!

This is the first devlog! In this thread I will talk about our items system, what we have changed and how this may improve future development.

Introduction

Items are an extremely essential part of SurviveTheNight. They give you some stats, they allow you to use certain abilities and you can customize them! Or atleast some of them.

While it looked like our items were working fine and there was no reason for us to change them: No! They weren't fine nor were they easy to work with.

The previous system

Before I get into how our previous system was like, you have to understand how an item (or ItemStack) is constructed.

An ItemStack can be split up into atleast three different parts:

• The general information: This includes the Material type (For example STICK, BOOK, STONE, so basically what the item looks like), the amount (How many of them should be in that stack we're creating) and the sub ID (STONE:0 would be stone while STONE:3 would be diorite)
• The ItemMeta: This contains a bunch of different data such as the item description (also known as the item lore), the displayname, vanilla enchants, some special attributes to hide certain properties and much more.
• Custom NBT: You may also add custom NBT to the items. Why would this be useful? It allows us to save custom data on an item without it being visible for casual players. These can be useful to store certain values such as an NPC value, a UUID, etc. on the item.

Okay!
So how did our previous system look like?

Every STN item was coded manually. Each item has its individual STN ID which is used to identify the original item when it's modified, add certain abilities to it and just check for items in general.

All the possible modifiers were coded manually and whenever joining a server a brand new copy of the original itemstack (depending on their STN ID) would be loaded from the plugin and then every applied modifier of the original item would be applied to the new item.

This basically allowed us to keep all the items updated when switching servers but also make them not lose any of your applied modifiers. However the main issue was applying the modifiers in the first place.

As I already said every modifier was coded manually instead of having a modular design.
There was a bunch of code repitition (which is never fun and not what you should be doing when coding), which lead into the modifiers class containing about 4.000 lines of code and the entire modifier system not being modular at all. Adding new modifiers would be a pain as I'd have to implement that modifier at like 30 different locations in various classes in the entire code.

     Creating/Crafting new items:
As you may have noticed: Loading in items or crafting new items in the crafting menu would take a couple ticks for them to actually load in and update properly.
This was caused by another issue we've had: This issue required us to wait a couple ticks for the server to properly create a new copy of the original itemstack before being able to modify it, otherwise it would modify the original itemstack and apply the modifier to EVERY item with the same STN ID on the entire instance - crazy, I know! (This issue caused me alot of pain in the past btw, I really hate it.)

    The NBT structure:
Aswell as all of that, the NBT on the items were kinda confusing and hard to read - not like you should read them, however for us for debugging purposes it was really annoying to work with:

All of our custom NBT was saved into "STNData" on the item and a pickaxe for example would end up looking like this:

STNData: {
            itemUUID: "0abd2c29-b306-4082-8522-cdeac2f1718e",
            itemType: "Pickaxe",
            stnID: "CRYSTALLIZED_PICKAXE",
            efficiency: 5,
            pickaxeUnlockedModes: "engine:handle:prism",
            doubleDrop: 0,
            npcValue: 720,
            miningExpReq: 25,
            handMiningFortune: 350,
            itemUUIDDC: "ca30a282-0a61-4c60-818f-a4a0f9c6e160",
            breakingPower: 7,
            pickaxeModeSelected: "handle",
            handDiggingRate: 1950,
            propertyOne: "multiblocks5",
            propertyTwo: "overflow5"
        },

As you can see: Nothing is sorted nor are the values or names easy to understand.

The new system

The main reason we did the revamp was because of the difficulty when it comes to adding new modifiers to items.

I managed to figure out a system where I can just add one line of code which contains all the necessary information to add a whole new modifier - and trust me: This is way way easier to work with than before.

This would be how a modifier in the new system looks like:

MAGICIMBUED(ModifierTypes.GLOBAL, "MAGICIMBUED", new Object[]{"STNData", "magicImbued"}, null, true) {@Override public <t> ItemStack addNBTTags(ItemStack iS, T additionalData, boolean update, ItemStack... prevStack){return new GlobalModifiers().addNBTAndLoreMAGICIMBUED(iS);}},</t>

It may look a little confusing, however this is probably the easiest I could do.

It contains a ModifierType which basically says which item types this modifier can be applied to,
a modifier name which is required for updating the item,
an NBT "path" to the data of the modifier on the item and
an STN ID blacklist which contains IDs with items that cannot have this modifier ("null" in this example as there's no exception).

I also reworked the system which made new items require a couple ticks before being able to be modified, so that any types of delay when it comes to creating new items, crafting new items or loading new items should be completely gone.

The NBT structure of items is way easier to read now, even tho it may not seem like it at first sight:

STNData: {
            coreItem: {
                itemType: "pickaxe",
                stnID: "CRYSTALLIZED_PICKAXE"
            },
            miningExpReq: 25,
            mOrigTag: "ITEMUUID&&ITEMUUID&&PICKAXEPROPERTY_1&&PICKAXEPROPERTY_2&&PICKAXETIER&&PICKAXEPERK&&PICKAXEMODE&&PICKAXEMODEACTIVE",
            itemUUID: "ca30a282-0a61-4c60-818f-a4a0f9c6e160",
            enchants: {
                efficiency: 5
            },
            npcValue: 720,
            modifiers: {
                pickaxePerk: {
                    extradrops: 1
                },
                breakingPower: 7,
                pickaxeMode: {
                    draconicPrism: "true",
                    active: "reinforcedHandle",
                    reinforcedHandle: "true",
                    pickaxeEngine: "true"
                },
                propertyOne: {
                    multiblocks: 5
                },
                propertyTwo: {
                    overflow: 5
                }
            },
            profileStats: {
                diggingSpeed: 1950L,
                miningFortune: 350L
            }
        },

And saving the itemstacks to databases has also been improved. Instead of being saved as some type of yml "string" (which is like a million characters long), they're now being saved as Base64 encoded itemstacks.

I also took some time to rework the design of item descriptions! This is what a pickaxe will look like when the changes come to the main server:

The overall structure of modifiers has been changed, every modifier now has its own section.
The pickaxe now also not only shows the selected pickaxe mode but also the already unlocked ones on the pickaxe.

Future development

If you took a look at the new NBT structure you may have noticed an enchants section.
Yes! We are finally able to properly add multiple enchants to the game without any issues.

Aswell as that we are able to easily add new pickaxe perks, modifiers, attributes, stats and make changes to the current ones.

Every item now has a proper item category so that we can make global changes to every item in a certain category.

Overall it's just much much easier to modify, add and remove new items, their stats and modifiers.

Conclusion

This system took a lot of time to rework. Obviously a system like this wasn't my first approach when thinking of a new modular item modifier system, so it took a couple days to experiment with NBTs and much more.

After about two weeks of coding, trying and fixing bugs this system does seem to work decently fine. It does require more testing and if you notice anything disappearing on your items once the servers are back online, please immediately report issues!

However especially when looking into the future, reworking this system was necessary and will allow us to bring new enchants, modifiers or items almost effortlessly to the server!

Systems that must still be reworked

This is more like a checklist with systems that will probably receive their own devlog once they're done.

• Items
• Achievements
• STN Creatures
• Inventories
• NPCs

That's it! Hope you learned something new! I didn't go too much into detail on this one, otherwise you'd read for another 2 hours probably.

I'm sorry for not including too many pictures, I'll try and add more in the upcoming devlogs.

Hi!

This is a thread regarding the current maintenance and backend changes.
While STN is down I thought I'd give you something to read about STN and the current backend situation since it's offline right now!

Introduction

Before I start I just want you to know:
We've NOT lost interest in working on STN nor has this project been abandoned!

STN is a somewhat RPG Minecraft server with various custom features, items, monsters etc.
Most of you probably aren't too familiar with the technical aspects behind it, so I'll introduce you a little bit to what I've been doing here.

I've split up this thread into a few parts so it's easier to navigate for you or if you only want to read certain parts of the thread:

• Minecraft Plugins and complexity
• Our current situation
• The Backend Changes
• Why is STN down and when will it be back?

Minecraft Plugins and complexity

Atleast some of you probably haven't coded a minecraft plugin before. The main problem with coding plugins is that coding these is pure java code above minecraft basically. You have nothing, you don't have a game engine you can work with. The only thing you can work with pretty much is a set of commands and functions to interact with the minecraft server, also known as an API.

STN itself is almost completely self-made. Our Lobby services for example only run three download plugins:

• LuckPerms (A permissions and ranks plugin, so players have certain permissions across the entire network depending on their rank)
• ViaVersion (A plugin which allows players to join the server even if they're joining with a newer version than the server is running on)
• WorldEdit (Well-known plugin which allows to edit your world basically, paste in things and replace other blocks)

All of these systems run on a Cloud system (CloudNet) which hasn't been made by me either.

Everything else is coded by us - or me rather.

STN also comes with ALOT of security and background-running systems, so everything you're actually looking at works the way it does right now.

Our current situation

If you may think that everything is fine with the server because most things work as expected and those that don't work require just some minor patches: Unfortunately not.

Some pieces of code, especially code related to our STN Dungeons is EXTREMELY outdated and not coded well in any way. I've started working on this project when I was 14, so about 5 years ago from now.

Due to that and to my extremely lacking knowledge back then when it comes to Java, most of the code is poorly written and not really easy to add new features to.

I do know alot better by now, however when it comes to our Lobby systems, I basically just was too lazy to write decent code from the beginning, so the code pretty much became a mess again.

Our newest update - the early game update - was extremely painful to code: Not only because it required me to use some techniques I've never used before, but also because the Lobby code wasn't made to be extended for new features. This became an issue really fast and adding new things such as Collections require way too many lines of code to be properly implemented.
Some systems in STN are even worse as I rushed through the process of coding them instead of taking my time and thinking about what possibly could happen with it in the future and if or how we want to extend certain things or make them more customizable.

Another issue is the server performance - Accessing databases and processing their data mostly happens synchronously (It basically runs on the main thread of the server and therefore slows it down) instead of asynchronously (Runs on a seperate thread to the main thread: If anything lags out you wouldn't notice a performance drop such as bad TPS or a lagspike).

The Backend Changes

Backend itself is way harder for me personally to focus on and to code a proper future-proof major system like the background-running systems for STN compared to frontend.

I took a look into the general structure of our systems and immediately knew it would take a while to fix this issue.

As already said most internal systems are not coded to be extended with new features nor to be customized. Changing the drop chance of an item a monster may drop for example shouldn't require multiple changes in the code but instead only one.

Right now I'm working on our databases, adding new data to them, making them future-proof and merging your profiles to them!
It requires alot of time, especially for our system that manages all the ingame items. Items were encoded very poorly so far, aswell as them losing custom data sometimes. I won't go too much into detail with that, otherwise you'd be reading for a couple hours probably.

After the databases I can finally focus on more fun things: The overall systems.
If the databases work fine, then the rest will also work decently fine most likely. If all the data can be stored and retrieved safely, then the systems may start working and processing that data.

Why is STN down and when will it be back?

You may ask why STN is currently offline? Well, we are "only" doing backend changes instead of adding alot of content which may break the game, however I wasn't expecting these changes to take this long. I've already started merging your profiles to new databases, so if I'd reopen STN all of your progress you'd gain until the backend changes are fully done would be lost and I wouldn't be able to restore it.

Yes. I could merge your data again once the backend changes are done, however that is more effort than you may think and could possibly lead to some data loss.

When will STN be back? Unfortunately I can't tell. It fully depends on how the progress is going and how bad the code is that I have left to rework.

I really wasn't too motivated to work on the backend changes over the past 1-2 weeks, therefore I took a short coding break instead of writing some bad code once again that would need a rework in a couple months.
As you probably guessed: Coding on STN is not my actual job, we are not earning any money with this, this all happens in our freetime. Therefore I don't have too much time to work on this project in general and since I'm the only developer as of right now everything takes even longer.

Either way: I'm giving my best to bring back STN to all of you as soon as possible!

Once we are ready for some major testing of our backend changes, we will let you know!

Alright, this is it. You now got a short insight in what I'm actually doing here and why everything is delayed, aswell as why exactly we are doing these backend changes.

If you made it until here: Congratulations!

Further necessary updates on the current maintenance will be posted in the discord!