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.
Related changes
NovaBlock
has been renamed toBlockBehavior
- The
vanillaMaterialProperties
andattributeModifiers
fields inItemBehavior
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.
Related changes
- 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 asVanillaToolCategories
,VanillaToolTiers
, etc.). Nova's content is prefixed withDefault
(such asDefaultGuiMaterials
,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
Related changes
- If you've used the
VisualizeRegionItem
, you will now need to provide aPlayer
for which the region should be visualized. This also requires you to use anIndividualTileEntityGui
instead of aGlobalTileEntityGui
.
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.
- 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 nameGui
. - A lot of classes and functions that should've been internal have been made internal. This probably won't affect you.