-
-
Notifications
You must be signed in to change notification settings - Fork 74
1.16.5 to 1.17 and 1.18: Updates and Changes
This page is dedicated to listing out the notable changes between 1.16.5 and 1.17 for Curios API that modders should be aware of as they update their mods.
There's a new, required, non-defaulted method in the ICurio interface, getStack. Modders simply need to return the ItemStack associated with the curio instance. This was primarily done to ease default implementations and usages that required a reference to the ItemStack when given only the ICurio instance.
The canRender and render methods in ICurio and ICurioItem have been removed. These were immediately removed rather than deprecated due to class-loading concerns in certain niche situations as well as the changes that Minecraft made to entity model rendering that prompted taking a different approach.
There are two new classes in the new top.theillusivec4.curios.api.client package, ICurioRenderer and CuriosRendererRegistry.
ICurioRenderer is the new interface to use for implementing renderable curios, consisting of just a render method. These can be implemented wherever modders want, as the registration process will be described later.
Note that the old RenderHelper methods from ICurio have all been moved to this interface as well.
CuriosRendererRegistry is where modders need to use register(Item, Supplier<ICurioRenderer>) to register their renderer implementations to specific items. This should ideally be done in FMLClientSetupEvent on the mod event bus.
private void clientSetup(final FMLClientSetupEvent evt) {
CuriosRendererRegistry.register(item, () -> new CurioRenderer());
}
And that's it. Then Curios will look for the renderer when it tries to render an item in a Curios slot.
The crown, amulet, ring, and knuckle items and their respective code have been removed from the main mod and moved to a separate test mod examinable in the same repository. This was done both to trim down on the amount of bloat in the main mod and to avoid further inquiries about how to obtain these items in Survival mode when they weren't designed to be included in gameplay.
Most of the methods in the ICurio and ICurioItem interfaces have been deprecated in favor of slot context-sensitive alternatives. Some of this was already started in 1.16.5, but 1.17 introduces the overhaul to all of the methods possible. None of the old methods were removed, just deprecated, and the javadocs reflect both of the deprecation and the suggested alternative for each method. Implementations should still work as-is, but it's highly advised to update to the new methods as deprecated methods could be removed as soon as 1.18.
SlotContext was made to hold all current and future information necessary to the slot without requiring an update to each method's parameters every time new information is added. Currently, that info includes identifier, index, entity, cosmetic status, and visibility status.
Locked and unlocked states have been removed in favor of a new slot attribute system (read more about that here). This is easier to maintain and easier to deterministically incorporate all mods that want to manipulate slot sizes. Mods that want locked slots should simply register a slot type that defaults to size 0 so that none are available at first. This is not a breaking change because all references to locked and unlocked states currently redirect to slot size states, so implementations should still work as-is although certain nuances of this behavior may have changed.