Skip to content

Migration Guide 0.12 ➝ 0.13

Initialization

With 0.13, we bring a new way to initialize your registries and other classes. Simple annotate a class with @Init and it will be loaded during the initialization phase. We recommend annotating your registry classes with it. More info

The end of NovaMaterial

We've decided to split NovaMaterial into NovaItem and NovaBlock. This allows for more flexibility, as you can now have a block that is not an item. Currently, the materials.json file is still used to register items and blocks, but this might be changed in the future.

All extension functions / properties and the like have be renamed as you'd expect, i.e. ItemStack.novaMaterial is now ItemStack.novaItem, Block.novaMaterial is now Block.novaBlock, etc.
Please let us know if we've missed anything.

  • NovaBlock has been renamed to BlockBehavior
  • The vanillaMaterialProperties and attributeModifiers fields in ItemBehavior have been changed to getter functions

Registries

We've switched all "registry-like" classes to Minecraft's built-in Registry system. We've also added builders for NovaItem and NovaBlock to make it easier to register them and to reduce future breaking changes when adding new properties.™

Therefore, we've also deprecated NamespacedId in favor of Mojang's ResourceLocation.

Check out the registering items, registering blocks sections again.

  • With the new registry system, all default entries are now in separate classes. If they're related to vanilla minecraft, the classes are prefixed with Vanilla (such as VanillaToolCategories, VanillaToolTiers, etc.). Nova's content is prefixed with Default (such as DefaultGuiMaterials, DefaultGuiTextures, DefaultItems, etc.).

ItemStack data

We've changed how data is stored in ItemStacks. Previously, this used Bukkit's PersistentDataContainer, but we've changed this to use our custom CBFCompoundTag. Using ItemStack.novaCompound, you can now retrieve a NamespacedCompound to store data in. This should generally improve performance, as we won't need to (de)serialize data every time it's accessed, as the data is now cached in our new NBT tag type.

You can still use the ItemStack.retrieveData and ItemStack.storeData extension functions. They will automatically move your data from the old PersistentDataContainer to the new CBFCompoundTag.

TileEntity GUIs

We've reworked how TileEntity GUIs work. There is no longer a lazy gui property in TileEntity, instead the GUI class is now retrieved using reflection and needs to be annotated with @IndividualTileEntityGui or @GlobalTileEntityGui. This makes TileEntity GUI's more flexible as you now have the option to have one GUI instance per player. More Info

  • If you've used the VisualizeRegionItem, you will now need to provide a Player for which the region should be visualized. This also requires you to use an IndividualTileEntityGui instead of a GlobalTileEntityGui.

Tool Levels -> Tool Tiers

ToolLevel is now ToolTier and allows for better customization of tool tiers that have the same mining level. More info

Switch to kyori adventure api (chat components)

We've completely switched to kyori adventure components. Boss- and action bar overlays now use the Component class instead of md_5's Array<out BaseComponent>. This also includes CharSizes, MovedFonts, MoveCharacters, FontChar and everything else.
We've removed related utility functions for the bungee component api.

Reworked BossBarOverlay

Boss bar overlays have been completely reworked. More info

New Hitbox System

With Mojang adding interaction entities in 1.19.4, we've reworked our hitbox system to support them. More Info

New MultiModel System

With Mojang adding display entities in 1.19.4, we've reworked our Model and MultiModel system to use those instead of armor stands. This feature is not yet documented here, but you can use MovableMultiModel and FixedMultiModel to deal with a larger amount of display entities that are supposed to display models from an item stack.

Removal of default upgrade types

If you've previously used any of the upgrade types that came with Nova, these have been moved to the simple_upgrades addon.

build.gradle.kts dependencies { }
implementation("xyz.xenondevs:simple-upgrades:1.0-SNAPSHOT")
build.gradle.kts addon { }
depend.add("simple_upgrades") // (1)!
  1. Create a hard dependency on the simple_upgrades addon!

The SimpleUpgrades addon also provides several top level functions for creating holders so that you won't have to change much in your code.
See: UpgradeFunctions.kt

Removal of nova-api from transitive dependencies

We've seen that some people accidentally used classes from the nova-api module in their addons. This module is intended for third party plugin developers and provides a very limited api. To avoid confusion and accidental imports of the wrong class, we've removed nova-api from the transitive dependencies of the nova module.

This means that you can no longer instantiate the Plugin API events (it's really just one). Instead, we now offer the NovaEventFactory class which provides methods to create and call those events, without the need of having the event class in your compile time classpath.

Since nova-api is still in the runtime classpath, you can add the nova-api module back to your compile time dependencies if you really want to, but we generally discourage this.

InvUI 1.0

InvUI has been updated to 1.0. This includes a lot of api-breaking changes, so please check out the InvUI Docs.

General Refactoring

  • A lot of classes have been moved around or renamed.
  • We've moved a lot of utility stuff to the xenondevs-commons project (specifically: providers, json utilities, collection utilities and some reflection utilities). This means that you might need to change some imports of extension functions and the like. Using IntelliJ's "Optimize Imports" feature should fix most of these issues.
  • We've renamed all classes containing GUI to their proper upper camel case name Gui.
  • A lot of classes and functions that should've been internal have been made internal. This probably won't affect you.