Fabric

Fabric for Minecraft 26.2

2026-06-15T00:00:00+00:00

A new version of Minecraft is coming soon with some changes that affect most mod makers. As always, we ask all players to be patient, and give mod developers time to update to this new version. We kindly ask everyone not to pester them. We also recommend all players make backups of their worlds.

26.2 introduces the ability for the backend to be changed between the default OpenGL backend and an experimental Vulkan backend, with OpenGL planned to be removed once the Vulkan backend is stable. Developers making use of raw OpenGL calls rather than going through the Blaze3D API will need to migrate for their mods to work.

Here is a list of several major modder-facing changes in this version, using the names provided by the unobfuscated game.

Fabric changes

Developers should use Loom 1.17 and Gradle 9.5.1 (at the time of writing) to develop mods for Minecraft 26.2. Players should install the latest stable version of Fabric Loader (currently 0.19.3).

Enum extensions

Fabric Loader 0.19.0 and Loom 1.17 bring with them a new API for enum extensions, implemented via Fabric Mixin at runtime and classtweaking at compile time. For more information, see the dedicated article on the Fabric Docs.

Tag removal

Fabric API 0.150.1 introduced a new API for removing entries from tags, useful for both mod developers and modpack developers wishing to safely modify tags without replacing them in their entirety.

As an example, the below will remove minecraft:brick from the values of this tag. Other entries within #c:bricks will still be added.

{
  "replace": false,
  "values": [
    "#c:bricks",
    "minecraft:snowball"
  ],
  "fabric:remove": [
    "minecraft:brick"
  ]
}

Fluid interaction API

Fabric API 0.150.1 also introduced the currently experimental Fluid Interaction API, allowing mod developers greater control over how their fluids interact with entities. To use it, register a fluid tag containing your mod’s fluid, and an instance of FluidBehaviour, which can either be created directly or via a builder.

EntityFluidInteractionRegistry.register(ModTags.ACID, 
                                        FluidBehavior.simple()
                                        .allowBoats(true)
                                        .allowSwimming(false)
                                        .build());

Attended client commands

Fabric API 0.152.0 introduced the ability to set .requires(FabricClientCommandSource::attended) on client commands, allowing mods to ensure that the user has confirmed that they expect to run the given client command. Without this, the server could provide a text component that when clicked runs a client command without the user being able to see the command.

Minecraft changes

26.2 is a smaller update with more minor changes than 26.1, focused primarily on rendering (as always) and registration. We have only listed a few of the major non-rendering changes here. For a more comprehensive list of changes, please see NeoForged’s upcoming porting “primer”.

Registration and data generation

The vanilla game now stores block ids and item ids seperately, in BlockIds, BlockItemIds, and ItemIds. These keys are used for data generation rather than the raw Block or Item instances.

This necessitated the removal of valueLookupBuilder. It’s recommended to match vanilla and seperate your ids from your Blocks as well.

Gui reorganization

Various GUI and HUD methods have been moved to dedicated classes for the Gui and Hud, which included moving the methods for retrieving and setting the current screen out of Minecraft. The Gui and Hud are both available from Minecraft.

// Setting the screen
- Minecraft.getInstance().setScreen()
+ Minecraft.getInstance().gui.setScreen()

Fabric for Minecraft 26.1

2026-03-14T00:00:00+00:00

A new version of Minecraft is coming soon with changes that will affect all mod makers. As always, we ask all players to be patient, and give mod developers time to update to this new version. We kindly ask everyone not to pester them. We also recommend all players make backups of their worlds, especially due to the major changes to world storage in this version.

Preparing Fabric to support and full embrace the changes in 26.1 has been a major focus for the last several months by many contributors. The changes in the tooling and API are the largest we have ever made for a single release. There are still some rough edges and missing features however the changes put us in a great position to continue to update and improve Fabric for the foreseeable future. We are excited to see what the community will create with the new possibilities that 26.1 opens up.

26.1 is the first version of Minecraft to not be obfuscated. Because of that, no mods from 1.21.11 or before will work without, at a minimum, recompilation. If you have not yet transitioned your mods to Mojang’s mappings, now is the time to do so, as Yarn is no longer officially supported by Fabric.

26.1 is also expected to be the last Minecraft release to solely support OpenGL, with 26.2 snapshots expected to allow for the backend to be changed between OpenGL and Vulkan, with OpenGL planned to be removed once the Vulkan backend is stable. Developers making use of raw OpenGL calls rather than going through the Blaze3D API will need to migrate for their mods to work.

Here is a list of several major modder-facing changes in this version. Note that all code references are using Mojang’s official names.

Fabric changes

Developers should use Loom 1.15 and Gradle 9.4.0 (at the time of writing) to develop mods for Minecraft 26.1. Players should install the latest stable version of Fabric Loader (currently 0.18.4).

Minecraft 26.1 requires Java 25 minimum for the Gradle JVM. You can configure this in your IDE’s Gradle Settings. Additionally, if you are using IntelliJ IDEA, version 2025.3 or above is required for mixins to work correctly.

Note: The Fabric Model Loading API and Renderer/Indigo modules may not be available for the inital release of 26.1, but we hope to have them updated as soon as they are ready. If you are interested in helping with the development of these modules, please reach out to us on our Discord server.

Deprecations and removals

Fabric API no longer provides the fabric mod ID, which was deprecated more than three years ago. If your mod’s fabric.mod.json depends on fabric and not fabric-api, you will need to fix that.

The following previously deprecated modules have been removed.

fabric-convention-tags-v1
fabric-loot-api-v2

In addition, deprecated conventional tags labeled for removal in 1.22 have finally been removed (#5056), and the deprecated HudRenderCallback event has been removed in favour of HudElementRegistry. As always, other APIs have been changed in response to 26.1 refactors, see below for more information.

Unobfuscated Loom

As mappings are not provided for 26.1, developers should switch from the old net.fabricmc.fabric-loom-remap or fabric-loom plugins to the new net.fabricmc.fabric-loom plugin, which does not remap Minecraft or mods. Any use of modImplementation, modCompileOnly, or similar should be switched out for the standard implementation or compileOnly, and any use of remapJar should be switched out for jar.

For further details, see the buildscript changes on the Fabric Docs and the new Fabric example mod.

Fabric API renames

Previously, Fabric API was built with Yarn mappings in mind, but with the move to official mappings, API names have been updated to match the official names where applicable. These changes are not backwards compatible, so you will need to update your mod to use the new names. As an example, ItemGroupEvents became CreativeModeTabEvents.

For a full list of changes, as well as an IntelliJ IDEA migration map to automatically make these changes, please see the Fabric Docs.

New Fabric API changes

Dimension events

Rather than use the biome modification API to iterate through and modifying every individual biome within a dimension, Fabric now provides an event that directly interacts with a dimension’s attributes. Datapack and modpack creators still retain granular control, as dimension-level modifications are designed with lower priority than biome-specific definitions during attribute evaluation in vanilla.

DimensionEvents.MODIFY_ATTRIBUTES.register((dimension, attributes, registries) -> {
  if (dimension.is(BuiltinDimensionTypes.OVERWORLD)) {
    attributes.set(EnvironmentAttributes.CLOUD_COLOR, PURPLE);
  }
});

Block/Item events

Fabric now provides 4 new events which allow for more precise modification of item/block use interactions. Compared to the existing UseBlockCallback and UseItemCallback events, these new events run only in specific contexts and keep the rest of vanilla logic around the use method calls.

BlockEvents#USE_ITEM_ON - called before Block#useItemOn, replacing it for non-null returns.
BlockEvents#USE_WITHOUT_ITEM - called before Block#useWithoutItem, replacing it for non-null returns.
ItemEvents#USE_ON - called before Item#useOn, replacing it for non-null returns.
ItemEvents#USE - called before Item#use, replacing it for non-null returns.

Block Color Registry

As ColorProviderRegistry has solely been used for blocks since 1.21.4, its implementation has been simplified in 26.1 to the new BlockColorRegistry.

Old code:

ColorProviderRegistry.BLOCK.register((state, level, pos, tintIndex) -> [...], ModBlocks.EXAMPLE_BLOCK)

New code:

BlockColorRegistry.register(List.of(new BlockTintSource() {
   [...]
  }), ModBlocks.EXAMPLE_BLOCK)

Minecraft changes

26.1 is a very large update with many changes, especially to the rendering engine. We have only listed a few of the major non-rendering changes here. For a more comprehensive list of changes, please see NeoForged’s porting “primer”.

ItemStackTemplate

An ItemStack can no longer be created until a world is loaded. As a replacement, the game provides a new class, ItemStackTemplate, an immutable class representing an non-empty Item, a count, and a DataComponentPatch. Many methods that used to return an ItemStack now return an ItemStackTemplate. Note that until the world is launched, components on an ItemStackTemplate are not bound and the game will throw if they are accessed too early.

Recipe serializers

Rather than having every recipe have an inner class than implements RecipeSerializer, recipe serializers have been simplified to just be a MapCodec and StreamCodec.

Registry.register(BuiltInRegistries.RECIPE_SERIALIZE, "mod_recipe", new RecipeSerializer<>(ModRecipe.CODEC, ModRecipe.STREAM_CODEC));

Automatically set render layers

ChunkSectionLayer is RenderType/RenderLayer’s replacement for terrain. Whereas before you had to manually register blocks to chunk layers like this…

// Before BlockRenderLayer (Yarn)
BlockRenderLayerMap.INSTANCE.putBlock(MyModBlocks.TATER_GLASS_BLOCK, RenderLayer.TRANSLUCENT);

// 1.21.6 (Yarn)
BlockRenderLayerMap.putBlock(MyModBlocks.TATER_GLASS_BLOCK, BlockRenderLayer.TRANSLUCENT);

…Minecraft now automatically sets the ChunkSectionLayer for each quad based on the assigned sprite’s properties which are as follows:

Translucency: the sprite has translucent pixels
Cutout: the sprite has only solid and transparent pixels
Solid: the sprite has no transparency or translucency

This can be overridden with a block model or with MutableQuadView and Model Loading API.

Villager trading

Villager trading, including Wandering Traders, has been made data-driven in 26.1, removing the need for Fabric’s TradeOfferHelper API. A villager trade is stored in the new data/<namespace>/villager_trade directory, a set of trades is defined in the data/<namespace>/trade_set folder, which uses tags in the data/minecraft/tags/villager_trade/<profession> folders.

In general, to add your mod’s trade to an existing profession:

Create a new villager trade in data/<namespace>/villager_trade
Add it to the appropriate tag in data/minecraft/tags/villager_trade/<profession>.

Fluid rendering

The new FluidModel replaces a lot of functionality previously provided by Fabric API’s FluidRenderHandler. You can register an unbaked fluid model by creating a FluidModel.Unbakedand registering it with FluidRenderingRegistry.register. In most cases there is no longer a need to create a FluidRenderHandler for your mod’s fluids.

mcsrc.dev

Over the last few months we have been developing mcsrc.dev, a new online tool to view the decompiled source code of Minecraft. It works by downloading the Minecraft jar directly from Mojang’s servers, decompiling it with Vineflower that has been compiled to WASM. mcsrc.dev also provides tools to aid with creating mixins and AccessWideners/ClassTweakers. We have plans to use this as the base for a javadoc editor that will allow users to provide documentation for Minecraft, this is still in the early stages of development.

Fabric for Minecraft 1.21.11

2025-12-05T00:00:00+00:00

As you may be aware, we expect 1.21.11 to be the last version of Minecraft that is obfuscated. The next snapshot will be the first version of Minecraft that will not be obfuscated.

Mojang have also recently announced that they will be changing how the game is versioned. The next version will be known as 26.1. This new versioning nicely lines up with the unobfuscation process, as 1.21.11 will be the last obfuscated version.

Here is a list of several major modder-facing changes in this version. Note that all code references are using Mojang’s mappings; modders using alternative mappings, including our previously default Yarn mappings, may need to use different names.

Fabric changes

Developers should use Loom 1.14 (at the time of writing) to develop mods for Minecraft 1.21.11. Players should install the latest stable version of Fabric Loader (currently 0.18.1).

World Render Events

The World Render Events were recently reintroduced into Fabric API for 1.21.10. Mods that required them to port can now do so. The new World Render Events are intended to match with recent changes to Minecraft itself, focusing on separating extraction from rendering.

Rendering in the world has been documented on the Fabric Docs.

Packet Splitter and Recipe Sync API

Fabric now offers an opt-in packet splitter, allowing for mods that have packets that would exceed the size of a vanilla one to easily be split between multiple packets.

Implementing the packet splitter is simple - use the new registerLarge method when registering your packet.

PayloadTypeRegistry.playS2C().registerLarge(YourPayload.ID, YourPayload.CODEC, DATA_SIZE);

Thanks to this API, Fabric also now offers a way for mods to synchronize recipes from the server to the client, comparable to the behavior prior to 1.21.1. This API has already been adopted by recipe viewers like JEI, but means that recipe viewers are required on the server.

RecipeSynchronization.synchronizeRecipeSerializer(YourRecipeSerializers.RECIPE_TYPE);

Minecraft changes

The following section details a few of the more notable changes to Minecraft that affected the Fabric API.

Game rules

Game rules were refactored to use the Registry system; Mods should now use the new GameRuleBuilder API to create and register custom game rules.

public static final GameRule<Boolean> EXAMPLE = GameRuleBuilder.forBoolean(true)
   .buildAndRegister(Identifier.fromNamespaceAndPath("fabric", "example"));

The above snippet creates and registers a new boolean game rule with the default value of true. The GameRuleBuilder API provides the following factory methods forInteger, forDouble, forBoolean, and forEnum to create game rules of different types. The builder also allows for additional configuration such as setting the category, required features and command result suppiler.

The new version of Fabric API also includes a GameRuleEvents class that provides an event for listening to game rule changes. Mods can use this event to perform actions when a game rule is changed.

GameRuleEvents.changeCallback(GameRules.FIRE_DAMAGE).register((value, server) -> {
   // Your code here
});

Environment Attributes

The Biome Modification API has been updated to support the new Environment Attributes system. Mods can now modify environment attributes such as temperature, humidity, and altitude for biomes using the BiomeModificationContext#AttributesContext class. You can access the attributes context by using the getAttributes() method on the BiomeModificationContext object.

An update on unobfuscation

Alongside updating to each 1.21.11 snapshot, Fabric has been working towards making this transition as smooth as possible. Currently, Mojang has been releasing experimental unobfuscated versions of Minecraft alongside the obfuscated ones, allowing us to test and prepare for the transition.

With that in mind, this is a good time to begin remapping your mods to the official Mojang Mappings, as Yarn will not be available for the version of Minecraft after 1.21.11. The differences between Mojang mappings and the unobfuscated game do not affect compilation, so switching to Mojang mappings now will allow for an easier transition when porting to future snapshots. There is no immediate rush to do this, as we anticipate the first unobfuscated stable release will be a few months into 2026.

The unobfuscation process has raised many questions. We’ve answered some of the more common ones here, but please reach out in the Fabric Discord if you have any specific questions.

Is 1.21.11 obfuscated or not?

Yes, 1.21.11 is still obfuscated. The next version of Minecraft after 1.21.11, 26.1, will be the first unobfuscated version.

Are Yarn and Intermediary still going to be updated past 1.21.11?

No, the plan is to stop updating Yarn and Intermediary after 1.21.11. Modders should begin migrating to Mojang Mappings as soon as possible.

What if I want to use custom mappings?

You can still opt to use custom mappings, we plan to continue to maintain support for remapping in Loom. However, please be aware that using custom mappings may require additional work to ensure compatibility with the unobfuscated game and other mods.

Will my simple mod still work on 26.1 without changes?

No, all mods that interact with Minecraft code will need to be recompiled to be compatible with the unobfuscated version of Minecraft.

My mod is using Yarn mappings, how do I migrate?

We’ve put together an updated article on the Fabric Docs site that covers the process of migrating mappings. In short - Loom should be able to handle most mods, and is now able to remap mixins, and third-party tools like Ravel can be used for more complicated projects (like Fabric API itself) or mods using Kotlin.

What is Intermediary?

Intermediary is a project we used to create stable names for Minecraft code across versions. This worked by giving each unique class, method, and field an ID that would remain the same across versions. This is not the same as the obfuscated names that Mojang uses as these change completely with each version. Intermediary allowed mods compiled against one version of Minecraft to continue working on future versions, as long as the underlying code did not change significantly.

Once the game is unobfuscated, there will no longer be a need for Intermediary, as method names should no longer change drastically between releases.

What changes if I am already using Mojang’s mappings?

If you are already using Mojang Mappings, the transition to the unobfuscated version of Minecraft should be relatively smooth. You may need to adjust any code that relies on synthetic methods or fields (search for ‘method_’ or ‘field_’ in your project.). Any usage of Fabric Loader’s MappingResolver can likely be removed. You will need to migrate your build script to the new Loom variant that does not support remapping. We will provide more detailed guidance as we get closer to the release of the unobfuscated version of Minecraft.

Will Fabric be quicker to update?

Yes! With the removal of obfuscation, we no longer need to manually update Yarn and Intermediary for each new version of Minecraft. This means that Fabric Loader and Loom will be able to use new versions as soon as they are released by Mojang. Fabric API will still require updates to accommodate changes to Minecraft itself. For stable releases where Fabric API has already been updated to a release candidate, we expect there will be no delay in fully supporting the new version of Minecraft.

So Minecraft is open source now?

No, nothing really changes in that regard. Mojang previously released their obfuscation mappings publicly allowing anyone to see the deobfuscated names of classes, methods, and fields if they remaped the code. This change simply means that the code itself that players use will no longer be obfuscated, making it easier for modders to work with without needing an extra step. The Minecraft EULA has also not changed.

How much easier will modding be?

A little bit, as local variable names will now be available in the code, which helps to make debugging and understanding Minecraft’s code easier. Crash reports will no longer require translation. However, developing mods will still require a good understanding of Java, Minecraft’s systems and the modding APIs being used. This will not allow mods to do anything they weren’t able to do before.

Removing Obfuscation from Fabric

2025-10-31T00:00:00+00:00

Mojang recently published a blog post announcing that they will be removing obfuscation from Minecraft: Java Edition starting with the first snapshot after the Mounts of Mayhem launch later this year. There will also be supplementary “experimental” releases starting with next Tuesday’s snapshot to allow us time to prepare and migrate.

This is a major change that will affect the entire modding community. This blog post will attempt to give a rundown of how the Fabric toolchain will be affected, and what this means for Fabric mod developers.

What is obfuscation?

Obfuscation is a practice by which the names of classes, methods, fields, etc. in the code of the game are hidden by changing them into meaningless sequences of letters that change every version. So, as an example, the class for Creepers may have been changed from Creeper to something like brc.

This has been a practice used for practically the entire time Minecraft has existed, and has meant that people who want to mod the game needed to figure out what each part of the code did, and use tools to apply readable names back to the code.

What has been done about obfuscation before?

In the Fabric world, we have had projects called Intermediary and Yarn. Intermediary would take the obfuscated names and give them stable numbers - so brc might become class_1548. Yarn would then apply readable names to those numbers - so class_1548 might become CreeperEntity. These Yarn names were created and determined by our community by analysing the code. (If you’ve seen things in the code named with the Intermediary numbers - those are things we didn’t get around to naming in Yarn!)

Since 2019, while the code of the game itself has still used the scrambled letters, Mojang has released their own official set of readable names, colloquially known as ‘Mojmap’, which are the names they themselves use when developing the game. This set of names was different from Yarn, and many developers embraced them, though some continued using Yarn names out of preference. Fabric has supported the option to use either set of names.

What does it mean that obfuscation is being removed?

Now, the names in the actual code of the game will match those that Mojang has been releasing since 2019. What’s more, for the first time, mod developers will now be able to see official names for method parameters and local variables, which were previously missing from those names.

However, as the Fabric toolchain has been built around the need to apply our own names, this means a lot of work will have to go into supporting this change.

What is Fabric going to do?

We have plans in place to update our toolchain, but there’s a lot to do, and this may take some time.

The future of Fabric API

Fabric API will not undergo major rewrites as a result of this, and all of your favourite APIs will stay on course. However, the naming of the APIs and their associated methods and javadoc will change to accurately reflect the official Mojang names.

The first stage of this will be to migrate Fabric API to use the official Mojang names in a non API-breaking way. This will happen fairly quickly as it can be done with no impact to modders and players.

When the new fully deobfuscated version is released, we will rename Fabric’s own API functions to match those of the official names.

Loom

Development of a new Loom version has begun. The initial goal is to provide a solution for mod developers to begin using the new experimental releases for testing. This will likely take the form of Loom 1.13.

In the long run we may look into making a totally new version of Loom that is more modular. Loom 2.0 may provide a slim version that contains no support for remapping. This will likely take some time, and is still in the design phase so please be patient.

Support for modding older game versions with the latest Loom is a very high priority and something that we wish to continue to provide as we have done previously. We also understand that not everyone wishes to use the new official names, we hope to provide a remapping solution for those advanced users who wish to use their own names.

The future of Yarn

The Fabric community as a whole thanks all 261 Yarn contributors for their 9 years, 2 months, and 17 days of Identifier glory. Your contributions have been and continue to be greatly appreciated.

Unfortunately, given the current circumstances we can’t see a way to justify maintaining Yarn in its current state.

Yarn for existing Minecraft versions will continue to welcome contributions.

If you are a mod developer using Yarn mappings, you will likely need to migrate to Mojang’s names. See the ‘For mod developers’ section below.

What do I need to do?

For players

Very little! This is largely only going to affect developers. We aim to keep supporting all existing launchers.

In good news, this also means once all this is sorted, updates for some things like Fabric API will likely be quicker in the future, and crash logs might be slightly easier to read. Rejoice!

And as always, we ask all players to be patient, and give mod developers time to update. We kindly ask everyone not to pester them. We also recommend all players make backups of their worlds before updating to any new version.

For mod developers

This is going to be a large change, especially for those that are using Yarn. There is no expectation to update your mods right away, but you may wish to prepare. Nothing will change until after the Mounts of Mayhem (1.21.11) drop.

We recommend that all new mods should be created using the official Mojang mappings, this will provide an easier upgrade path in the future.

If you have a mod using Yarn, don’t worry! Loom has existing automated tooling that will help you to rename your code. We are actively looking at ways to improve this tooling and plan to provide some resources in the future to help you.

Once you have upgraded, you will benefit from a much simpler and faster toolchain, improved logs/crash reports and new debugging options.

TL;DR: What will affect you

Players

Be patient while mods update.
Crash logs may be slightly easier to read.

Modders

Don’t worry! There is no rush.
Most Yarn users will need to migrate to the official names.
Your build script will require some changes.
Production crash logs may be slightly easier to debug.
Intermediary will no longer exist; the game will use Mojang’s names at runtime.

Fabric for Minecraft 1.21.9 & 1.21.10

2025-09-23T00:00:00+00:00

A new version of Minecraft is coming soon with some changes that affect most mod makers. As always, we ask all players to be patient, and give mod developers time to update to this new version. We kindly ask everyone not to pester them. We also recommend all players make backups of their worlds.

Here is a list of several major modder-facing changes in this version. Note that all code references are using Yarn mappings; modders using alternative mappings may need to use different names.

Fabric changes

Developers should use Loom 1.11 (at the time of writing) to develop mods for Minecraft 1.21.9. Players should install the latest stable version of Fabric Loader (currently 0.17.2).

Yarn Mappings

In this update, several mapping name changes were forced by changes in the vanilla class hierarchy. While a full diff may be found here, there is one major change affecting almost all mods: Entity#getWorld was renamed to Entity#getEntityWorld.

World Render Events

The current event suite for rendering in the world has been removed. A suitable replacement is planned asap, but not ready yet. In the meantime, please use mixins to implement what your mod needs.

Resource Loader API v1

A major rework of the resource loader API is present in the 1.21.9 version of Fabric API. This will make current functionality easier to acomplish, as well as opening doors for features like runtime resource generation in the future.

The first part of this rework has just landed with the focus being on ResourceReloader. Historically this API based itself on the IdentifiableResourceReloadListener interface which allowed ResourceReloader to both be identifiable and specify dependencies. However this API had limits, which prevented to run before another ResourceReloader or was difficult to use in multiloader environments. This has been fixed with this new iteration of the API.

From now on, ResourceReloader do not need to implement a Fabric-provided interface, instead they can be registered with an identifier directly:

- ResourceManagerHelper.get(ResourceType.SERVER_DATA).registerReloadListener(new CustomResourceReloader())
+ ResourceLoader.get(ResourceType.SERVER_DATA).registerReloader(Identifier.of("modid", "custom_resource_reloader"), new CustomResourceReloader());

Ordering is now specified akin to events:

ResourceLoader.get(ResourceType.SERVER_DATA).addReloaderOrdering(
    Identifier.of("other", "other_reloader_to_depend"), // Triggers first
    Identifier.of("modid", "custom_resource_reloader") // Triggers second
);

You can also order based on Vanilla reloaders thanks to ResourceReloaderKeys, which provides both per-resource-reloader an identifier, and two global keys: before and after vanilla.

Thanks to 1.21.9 Vanilla changes the way to register reloaders which need registry access has been simplified, instead of using a specialized registration method, now you can get registries and feature flags in ResourceType.SERVER_DATA reloaders via the shared state Store:

class DataReloader implements ResourceReloader {
    @Override
    public CompletableFuture<Void> reload(
        Store store,
        Executor prepareExecutor,
        Synchronizer reloadSynchronizer,
        Executor applyExecutor
    ) {
        RegistryWrapper.WrapperLookup registries = store.getOrThrow(ResourceLoader.RELOADER_REGISTRY_LOOKUP_KEY);
        FeatureSet featureSet = store.getOrThrow(ResourceLoader.RELOADER_FEATURE_SET_KEY);
        // Code
    }
}

This change also allows for ResourceReloaders to communicate data between them.

See #4574 for more details about what else is planned and the current progress.

Enchantments

Transitive access wideners have been added for all of the utility methods in EnchantmentHelper and Enchantment. We hope that this will make it easier for developers to implement custom enchantment effect components. See #4819 for more details.

Serialization

We have added a new module for utilities related to serialization. Currently, this module includes additional methods in ReadView and WriteView, and provides Codecs for some types that base vanilla doesn’t. Please feel free to suggest anything else that may be useful in this area. See #4745 for more details.

Block Conversions

To closer align with vanilla code flow, OxidizableBlocksRegistry now supports registering a CopperBlockSet direclty. Simply call OxidizableBlocksRegistry.registerCopperBlockSet(set) to register. The prior methods for block pairs are still avalible for those that prefer them. See #4807 for more details.

StrippableBlockRegistry now provides multiple overloads to satisfy all your stripping needs. As before, simple conversions can be registered by calling StrippableBlockRegistry.register(Block, Block). You may also call StrippableBlockRegistry.registerCopyState(Block, Block) to register a stripping conversion that automatically copies all properties from the previous state, or register(Block, Block, StrippingTransformer) to have full control over the stripping process. See #4829 for more details.

GUI Rendering

When using a custom RenderPipeline to render in the GUI, vanilla may assume that the VertexFormat being used is QUADS. Fabric now provides a way to override this behavior with RenderPipeline.Builder.withUsePipelineDrawModeForGui.

var pipeline = RenderPipeline.builder(
        snippet1, 
        snippet1
    )
    .withUsePipelineDrawModeForGui(true)
    .build();

// ...
fictionalRenderInGuiInNonGuads(pipeline); // will respect the VertexFormat set in the pipeline

See #4824 for more details.

Mixin & MixinExtras

With version 0.17.0 of Fabric Loader, MixinExtras 5.0.0 and Fabric Mixin 0.16.3+mixin.0.8.7 are now bundled.

MixinExtras 5.0.0 brings expressions, a new way to discribe mixins to java code in a syntax that mirrors the target, leading to mixins that are easier to maintain, more expressive, and potentially even more compatible with other mixins. See the release notes and wiki pages for more details.
Fabric Mixin 0.16.3 brings many bug fixes, along with scaffolding in mixin for potential widespread performance increases.

Screen Key Events

With many breaking changes from mojang regarding keybindings, we’ve taken the opportunity to improve our events. Most parameters in the event have been consolidated into a context object known as a KeyInput. The afterMouseX style events now also take and return a boolean representing whether the event has been consumed. Returning true from these events will prevent further vanilla handling.

See #4846 and #4620 for more details.

Minecraft Changes

Rendering

Almost all world rendering has been reworked to group objects with similar rendering requirements together. Most places now use OrderedRenderCommandQueue to submit things to be drawn later, when all objects of a similar type have been rendered.

Block Entities

Block entities now use OrderedRenderCommandQueue. The following example shows rendering text on the block using the queue.

public class TestBlockEntityRenderer implements BlockEntityRenderer<TestBlockEntity, BlockEntityRenderState> {
    public TestBlockEntityRenderer(BlockEntityRendererFactory.Context context) {
    }

    @Override
    public BlockEntityRenderState createRenderState() {
        return new BlockEntityRenderState();
    }

    @Override
    public void render(BlockEntityRenderState state, MatrixStack matrices, OrderedRenderCommandQueue queue, CameraRenderState cameraRenderState) {
        queue.submitText(
                matrices,
                0,
                0,
                Text.literal("Hello, world!").asOrderedText(),
                false,
                TextRenderer.TextLayerType.NORMAL,
                state.lightmapCoordinates,
                Colors.WHITE,
                0,
                Colors.BLACK
        );
    }
}

public class TestBlockEntityRenderer implements BlockEntityRenderer<TestBlockEntity> {
    public TestBlockEntityRenderer(BlockEntityRendererFactory.Context context) {
    }

    @Override
    public void render(TestBlockEntity entity, float tickProgress, MatrixStack matrices, VertexConsumerProvider vertexConsumers, int light, int overlay, Vec3d cameraPos) {
        MinecraftClient.getInstance().textRenderer.drawWithOutline(
                Text.literal("Hello, world!").asOrderedText(),
                0,
                0,
                Colors.WHITE,
                Colors.BLACK,
                matrices.peek().getPositionMatrix(),
                vertexConsumers,
                light
        );
    }
}

Particles

Particle rendering has been changed to use the same queue system as above. Many good examples for implementing custom rendering via the queue can be found in the vanilla particle classes.

Entities

Entity rendering has changed to use the same queue as shown above. Changes will be similar.

Keybinding Changes

Keybinding categories have become more structured. You could do the following before:

public class ModKeybindings {
  private static final KeyBinding RANDOM_KEYBIND = new KeyBinding(
    "key.test.random_keybind",
    InputUtil.Type.KEYSYM,
    InputUtil.UNKNOWN_KEY.getCode(),
    "key.category.test.main"
  );

  private static void tickKeybindings(MinecraftClient client) {
    while (RANDOM_KEYBIND.wasPressed()) {
      System.out.println("Random keybind pressed!");
    }
  }

  public static void init() {
    ClientTickEvents.END_CLIENT_TICK.register(ModKeybindings::tickKeybindings);
  }
}

Now you could do:

public class ModKeybindings {
  private static final KeyBinding.Category TEST_CATEGORY = KeyBinding.Category.create(Identifier.of("test", "main"));
  private static final KeyBinding RANDOM_KEYBIND = new KeyBinding(
    "key.test.random_keybind",
    InputUtil.Type.KEYSYM,
    InputUtil.UNKNOWN_KEY.getCode(),
    TEST_CATEGORY
  );
  // ...
}

Each category may only be registered once; Registering a category twice, or two categories with the same id will lead to an exception.

When Fabric API is installed, mod-provided categories will be sorted by alphabetically according to their identifiers, first by namespace, and then by path. All vanilla categories will remain in their natural order.

Debug Text API

It is now possible to register debug HUD entries to be added to the debug (F3) overlay. The debug overlay is now also available outside of a world. Use DebugHudEntries to register entries to be rendered as follows:

DebugHudEntries.register(
  Identifier.of("test", "example"), 
  new DebugHudEntry() {
    @Override
    public void render(
      DebugHudLines lines, 
      @Nullable World world, 
      @Nullable WorldChunk clientChunk, 
      @Nullable WorldChunk chunk
    ) {
      if (world != null) lines.addLine("Example in-world line :)");
      else lines.addLine("Example out-of-world line :(");
    }

    @Override
    public boolean canShow(boolean reducedDebugInfo) {
      // return false if your debug text 
      // is not applicable with reduced debug info
      return true;
    }
  }
);

Misc

MacOS

MinecraftClient.IS_SYSTEM_MAC has been replaced by SystemKeycodes.IS_MAC_OS.

Fabric for Minecraft 1.21.6, 1.21.7 & 1.21.8

2025-06-15T00:00:00+00:00

A new version of Minecraft is coming soon with some changes that affect most mod makers. As always, we ask all players to be patient, and give mod developers time to update to this new version. We kindly ask everyone not to pester them. We also recommend all players make backups of their worlds.

Here is a list of several major modder-facing changes in this version. Note that all code references are using Yarn mappings; modders using alternative mappings may need to use different names.

Fabric changes

Developers should use Loom 1.10 (at the time of writing) to develop mods for Minecraft 1.21.6. Players should install the latest stable version of Fabric Loader (currently 0.16.14).

Deprecations and removals

The following previously deprecated modules have been removed (#4651):

fabric-command-api-v1
fabric-commands-v0 (Deprecated almost 5 years ago!)
fabric-keybindings-v0
fabric-rendering-data-attachment-v1

The following modules have been merged into other modules for simplicity:

fabric-client-tags-api-v1 was merged into fabric-tag-api-v1 (#4647)
fabric-blockrenderlayer-v1 was merged into fabric-rendering-v1 (#4675)

The tag API changes are technically breaking for some developers who explicitly depend on these modules. The removal and merging of these modules has been done to help improve peformance when setting up a new development environment.

The Fabric Rendering API previously provided a Material API, to allow modders more control of the way their models rendered. This has been removed.

Materials were removed … because they were deemed to be an unnecessary part of the API design, and the breaking change induced by changes in 1.21.6 was related to materials, which made this the perfect time to remove them - PepperCode1

See (#4675) for more info.

In addition to being relocated, the BlockRenderLayerMap API was also updated to be more consistent out current API style:

- import net.fabricmc.fabric.api.blockrenderlayer.v1.BlockRenderLayerMap;
+ import net.fabricmc.fabric.api.client.rendering.v1.BlockRenderLayerMap;
 ...
- BlockRenderLayerMap.INSTANCE.putBlock(ModBlocks.MY_EPIC_BLOCK, BlockRenderLayer.CUTOUT)
+ BlockRenderLayerMap.putBlock(ModBlocks.MY_EPIC_BLOCK, BlockRenderLayer.CUTOUT)

See (#4664) for more info.

Breaking changes

Fabric’s brand new HUD API had to be totally rewritten in 1.21.6. The new HudElementRegistry provides all of the functionality provided by the old API. The following basic example shows how you can draw text after all of the vanilla HUD layers:

HudElementRegistry.addLast(Identifier.of("example", "hud"), (context, tickCounter) -> {
	context.drawTextWithShadow(MinecraftClient.getInstance().textRenderer, "This is an example", 10, 10, Colors.WHITE);
});

If you wish to render your custom hud element before the vanilla chat you can do the following:

HudElementRegistry.attachElementBefore(VanillaHudElements.CHAT, Identifier.of("example", "ud"), (context, tickCounter) -> {
	// ...
});

New Fabric API features

Since Item#appendTooltip has become deprecated, Fabric API now provides the ComponentTooltipAppenderRegistry. This registry provides addAfter, addBefore, addFirst, and addLast to allow you to position your tooltips relative to vanilla and other mods.

record MyAmazingComponent() implements TooltipAppender {
	@Override
	public void appendTooltip(Item.TooltipContext context, Consumer<Text> textConsumer, TooltipType type, ComponentsAccess components) {
		textConsumer.accept(Text.literal("Amazingness Awaits!"));
	}
}
ComponentType<MyAmazingComponent> myAmazingComponentComponentType = /*...*/;
ComponentTooltipAppenderRegistry.addAfter(
	DataComponentTypes.DAMAGE,
	myAmazingComponentComponentType
);

Any ItemStack that has your component applied will call your component’s appendTooltip method, allowing you to append as you wish. (#4587)

The LootTable API has been expanded to make certain extreme usages more convenient. The LootTableEvents.MODIFY_DROPS event allows modders to customize the collective output of LootTables. The LootTableEvents.MODIFY event should still be preferred when possible, for mod compatibility reasons. This event may also recurse if you generate loot from within a listener. (#4643)

var matchGetter = ServerRecipeManager.createCachedMatchGetter(RecipeType.SMELTING);

// smelt any smeltable drops from blocks broken with a diamond pickaxe
LootTableEvents.MODIFY_DROPS.register((entry, context, drops) -> {
	if (!context.hasParameter(LootContextParameters.TOOL)) return;
	if (!context.hasParameter(LootContextParameters.BLOCK_STATE)) return;
	ItemStack tool = context.get(LootContextParameters.TOOL);
	if (!tool.isOf(Items.DIAMOND_PICKAXE)) return;
	var world = context.getWorld();
	var lookup = world.getRegistryManager();
	drops.replaceAll(drop ->
		matchGetter.getFirstMatch(new SingleStackRecipeInput(drop), world)
			.map(RecipeEntry::value)
			.map(recipe -> recipe.craft(input, lookup))
			.orElse(drop)
	);
});

Continuing with our conventional tag API, we added new biome tags, allowing modders to differentiate biomes based on their primary wood type. The ServerChunkEvents.CHUNK_LEVEL_TYPE_CHANGE event was added to allow more control over the timing of chunk events. This event fires for changes in chunk loading level, to react to changes not previously possible without mixins. (#4541)

An event was added for attachment changes, allowing reaction to an attachment value changing. This event can be recursive in nature, as if you set an attachment value from within a listener, the event will be invoked again. Modders should use proper recursion techniques to prevent infinite recursion. (#4606)

Two more events were added for players joining and leaving the game:

AttachmentType<Instant> JOINED_TIME = /*...*/;
ServerPlayerEvents.JOIN.register(player -> {
	// runs on the main thread, no need to use player.getServer().execute(() -> ...);
	player.setAttached(JOINED_TIME, Instant.now());
});

List<ServerPlayerEntity> activePlayers = /*...*/;
ServerPlayerEvents.LEAVE.register(activePlayers::remove);

These events are designed for initializing and de-initializing state related to players, and run along vanilla code with the same purpose on the main thread, unlike the current events. (#4642)

The FabricSoundsProvider class was added to allow convenient creation of sounds.json from within datagen. (#4560)

The Client Game Test API has been tweaked to support filtering tests run by model, allowing more precise and efficient testing. (#4597)

The Model Loading API now supports registering extra unbound models (#4565)

// A ModelKey is a unique identifier for a model you want to bake.
public static final ModelKey<BlockStateModel> HALF_RED_SAND_MODEL_KEY = ModelKey.create();
public static final Identifier HALF_RED_SAND_MODEL_ID = id("half_red_sand");

public static void init() {
	ModelLoadingPlugin.register(pluginContext -> {
		pluginContext.addModel(HALF_RED_SAND_MODEL_KEY, HALF_RED_SAND_MODEL_ID, (model, baker) -> {
			ModelTextures textures = model.getTextures();
			return new SimpleBlockStateModel(new GeometryBakedModel(
				model.bakeGeometry(textures, baker, ModelRotation.X0_Y0),
				model.getAmbientOcclusion(),
				model.getParticleTexture(textures, baker)
			));
		});
	})
}

public static BlockStateModel getModel() {
	return MinecraftClient.getInstance().getBakedModelManager().getModel(HALF_RED_SAND_MODEL_KEY);
}

FabricTrackedDataRegistry has been added to allow registering tracked data handlers for entities. This removes conflicts between mods registering tracked data handlers and ensures that the order is consistent between the client and server. If you previously used the vanilla API the following 1 line change is all you need to take advantage of this new API:

- TrackedDataHandlerRegistry.register(TRACKED_DATA_HANDLER);
+ FabricTrackedDataRegistry.registerHandler(TRACKED_DATA_HANDLER_ID, TRACKED_DATA_HANDLER);

Bug Fixes

Thanks to the diligent developers and players, many bugs in Fabric API were reported and patched during this update cycle. See The Fabric Github for more info.

Minecraft changes

Rendering

Mojang is currently working on separating Minecraft’s rendering pipeline into two stages:

The extraction stage, where all renderable data is seperated from the game
The render phase, where the previously extracted data is rendered.

This process began in 1.21.2, and is still incomplete as of this update. Chunk, GUI and HUD rendering have all been converted to use the new separate rendering style. The ultimate goal of this separation is to enable the game to render one frame while the next is being extracted.

Many methods in RenderSystem have been removed without direct replacement. In most cases, there isn’t a one-to-one translation from the old code to the new, but the same capabilities exist by combining the new RenderPipelines with RenderLayers.

NBT

BlockEntitys now abstract saving to NBT through ReadViews and WriteViews. These views are responsible for storing errors from encoding / decoding, and keeping track of registries throughout the serialization process. You can read from a ReadView using the read method, passing in a Codec for the desired type. Likewise, you can write to a WriteView by using the put method, passing in a Codec for the type, and the value in question. there are also methods for primitives, under get(Int, Short, Boolean, ...) and put(Int, Short, Boolean, ...). The View also provides methods for working with lists, nullable types, and nested objects.

class BE extends BlockEntity {
	private int anInt;
	private String aString;
	private Extra extra;
	// Ctor excluded for brevity
	@Override
	public NbtCompound toInitialChunkDataNbt(RegistryWrapper.WrapperLookup registries) {
		return createNbt(registries); // createNbt takes care of adapting to / from WriteView
	}

	@Override
	protected void writeData(WriteView view) {
		super.writeData(view);
		view.putNullable("extra", Extra.CODEC, this.extra);
		if (aString != null) // putString will eventually throw if we pass null
			view.putString("aString", aString);
		view.putInt("anInt", anInt);
	}

	@Override
	protected void readData(ReadView view) {
		super.readData(view);
		view.read("extra", Extra.CODEC).ifPresent(extra -> this.extra = extra);
		view.getOptionalString("aString").ifPresent(aString -> this.aString = aString);
		view.getOptionalInt("anInt").ifPresent(anInt -> this.anInt = anInt);
	}

	record Extra(int i, int j) {
		public static final Codec<Extra> CODEC = RecordCodecBuilder.create(instance -> instance.group(Codec.INT.fieldOf("i").forGetter(extra -> extra.i), Codec.INT.fieldOf("j").forGetter(extra -> extra.j)).apply(instance, Extra::new));
	}
}

Data Generation

getOrCreateTagBuilder should be replaced with the new valueLookupBuilder.

Fabric for Minecraft 1.21.5

2025-03-24T00:00:00+00:00

A new version of Minecraft is coming soon with some changes that affect most mod makers. As always, we ask all players to be patient, and give mod developers time to update to this new version. We kindly ask everyone not to pester them. We also recommend all players make backups of their worlds.

Here is a list of several major modder-facing changes in this version. Note that all code references are using Yarn mappings; modders using alternative mappings may need to use different names.

Fabric changes

Developers should use Loom 1.10 (at the time of writing) to develop mods for Minecraft 1.21.5. Players should install the latest stable version of Fabric Loader (currently 0.16.10).

Loom 1.10

Loom 1.10 requires Gradle 8.12, and comes with performance improvements and enhanced testing setup support. You can checkout the new Loom documentation here.

Deprecations and removals

In Content Registries, VillagerInteractionsRegistries#registerGiftLootTable overload that takes an Identifier was removed. This method was previously deprecated.

In Object Builder, two deprecated classes, namely VillagerProfessionBuilder and VillagerTypeHelper, have been removed. Use the VillagerProfession constructor and VillagerType#create instead. TradeOfferHelper#refreshOffers, which had been deprecated and did nothing, was also removed.

HudRenderCallback has been deprecated in favor of newly added HudLayerRegistrationCallback.

Breaking changes

When a mod creates a new dynamic registry, the data pack JSON files for the registry must now be placed inside namespaced directories. For example, if the new registry is example:potato_variant, the file for variant test:tiny will be placed in data/test/example/potato_variant/tiny.json.

BiomeModificationContext#addSpawn has a new parameter, weight. This was previously part of SpawnEntry.

TradeOfferHelper now takes a RegistryKey of the profession instead of VillagerProfession. Wandering trader trades must now be added via the builder, which was previously used for the Rebalance experiment. (The rebalanced trades are now used in all worlds.)

New Fabric API changes

With the help of many contributors, Fabric API has received some new features since the last update blog post:

New module: Client Game Test API, which can be used to automatically test client rendering and GUI (Earthcomputer)
New module: Fabric Tag API, which currently handles tag aliases (Juxxel)
Convention Tags: Sync remaining c tags with NeoForge (TelepathicGrunt)
Convention Tags: Add c:flowers, c:flowers/tall, and c:flowers/small block and item tags (TelepathicGrunt)
Convention Tags: Add TagKey for c:tools/wrench (TelepathicGrunt)
Convention Tags: Convention Drink Tags (TheDeathlyCow)
Convention Tags: Add Pumpkin Block and Item Tags (JT122406)
Data Generation: Add vararg helper methods for multi-tag support in FabricTagBuilder (Starexify)
Data Generation: Add FabricEntityLootTableProvider (Antikyth)
Item API: Add a method for overriding modelId in item settings (Patbox)
Item API: Add contains method to FabricComponentMapBuilder (TheDeathlyCow)
Item Group API: Change Creative Buttons Texture (matthewperiut)
Item Group API: Use page up/down to change creative inventory pages (modmuss50)
Model Loading API: Allow retrieving model loading plugins (PepperCode1)
Networking API: Add ServerPlayNetworking.reconfigure (modmuss50)
Object Builder: Allow setting canPotentiallyExecuteCommands in builders (PepperCode1)
Recipe API: Add getAllMatches and getAllOfType methods to ServerRecipeManager (Patbox)
Registry Sync: Add RegistryAttribute#OPTIONAL that can be used to not disconnect clients lacking an entire registry; note that optional registry values are still unsupported (modmuss50)
Registry Sync: Registry aliasing (Syst3ms)
Rendering: Add SpecialBlockRendererRegistry (PepperCode1)
Rendering: Add HUD Render Events (kevinthegreat1)
Resource Loader: Implement builtin mod resource/data pack sorting (Apollo)

Tag and registry aliases

The new tag and registry alias APIs allow for mods to seemlessly migrate their tags and registry aliases to new names. Thanks to Juuxel and Syst3ms respectively for implementing these new APIs.

Registries.BLOCK.addAlias(Identifier.of("my_mod", "old"), Registries.BLOCK.get(Identifier.of("my_mod", "new")));

Registry aliases are really simple; with the code above, any access to the old ID in the registry is redirected to the new ID. This allows worlds to be upgraded to use the new ID; for example, a block with the old ID becomes the one with the new ID.

Tag aliases are defined in data packs like tags. For example, a block tag alias group for fences would be located at data/my_mod/fabric/tag_aliases/block/fences.json with the contents:

{
  "tags": [
    "minecraft:fences",
    "c:fences"
  ]
}

Client GameTest

For a long time, Fabric has had an internal client test framework that was used for testing that Fabric API was working correctly on the client. In a series of PRs, Earthcomputer has worked to expand and expose this framework to mod developers. The new experimental API has the following features:

World creation API, for specifying options used to generate the test world.
Screenshot API, with support for comparing against golden images.
Input API, to simulate a user interacting with the game.
Advanced threading setup, to make the tests more repoducible.
Network synchronization, to ensure packets are handled consistently.
Herobrine removal, to bring peace to the Kingdom of Tiny Potato.

For more information checkout the full documentation here.

HUD Render Events

Fabric API 0.116.0 added HudLayerRegistrationCallback event, providing full control over the HUD rendering process. The new API assigns idenftifiers to each layer that can be used to specify where things will be rendered. The new API also allows replacing or removing existing layers. A big thanks to kevinthegreat1 and many other people for making this happen!

Minecraft changes

NBT

Significant changes to NBT handling code have been made.

NbtCompound methods now return Optional instead of the value. If the key is not in the compound or if the value is not of the correct type, an empty optional is now returned instead of that type’s default value.

- int value = nbt.getInt("value");
+ Optional<Integer> value = nbt.getInt("value"); // not OptionalInt

For primitives (numbers and strings), instead of checking for the existence of a key and handling a fallback, the fallback can now be passed to get methods:

- int value;
- if (nbt.contains("value", NbtElement.NUMBER_TYPE)) {
-   value = nbt.getInt("value");
- } else {
-   value = 1000;
- }
+ int value = nbt.getInt("value", 1000);

Also note that NbtElement#NUMBER_TYPE and type-aware contains have been removed. There is no fallback method for getIntArray, getLongArray, and getByteArray. (Use Optional#orElse.)

For getCompound and getList methods, methods with the previous behavior (returning empty objects) are provided with OrEmpty suffix.

- NbtCompound config = nbt.getCompound("config");
+ NbtCompound config = nbt.getCompoundOrEmpty("config");

Finally, for those who want to encode/decode codec-based values (such as Identifier) stored in a NbtCompound field, new methods simplify the process:

NbtCompound nbt = new NbtCompound();
nbt.put("Id", Identifier.CODEC, id);
// for reading
Optional<Identifier> id = nbt.get("Id", Identifier.CODEC);

And if there is a codec for the whole object:

NbtCompound nbt = new NbtCompound();
// have to use the RegistryOps since an item is a registry entry
nbt.copyFromCodec(ItemStack.MAP_CODEC, wrapperLookup.getOps(NbtOps.INSTANCE), stack);
// for reading
Optional<ItemStack> stack = nbt.decode(ItemStack.MAP_CODEC, wrapperLookup.getOps(NbtOps.INSTANCE));

Typed arrays (ByteArray, IntArray, and LongArray) are no longer Lists. They can be converted to a list using .stream().toList(), but this is usually not necessary. NbtList can now contain values of differing types, but this should be a transparent change unless you work with binary data.

GameTest

In Minecraft 25w03a, Mojang totally refactored the vanilla testing framework, exposing it to datapack developers. Unfortunately, the new API is a little bit cumbersome for mod developers. Fabric API now provides its own @GameTest annotation that functions similarly to the old one. The options in the new Fabric-provided @GameTest annotation directly map the vanilla data-driven options, removing the need to have a JSON file for each test function. Data driven tests will still work if you wish to use the vanilla system.

Miscellaneous

DataPool has been replaced with Pool.
AbstractBlock#onStateReplaced has been significantly changed, the state provided is the old state and it now runs after block entities get removed. Block entities should use BlockEntity#onBlockReplaced instead.

Fabric for Minecraft 1.21.4

2024-12-02T00:00:00+00:00

Minecraft 1.21.4, the Garden Awakens drop, releases December 3rd. Like with other updates, this drop contains some significant changes affecting mod makers.

As always, we ask all players to be patient, and give mod developers time to update to this new version. We kindly ask everyone not to pester them. We also recommend all players make backups of their worlds.

Here is a list of several major modder-facing changes in this version. Note that all code references are using Yarn mappings; modders using alternative mappings may need to use different names.

Fabric changes

Developers should use Loom 1.9 (at the time of writing) to develop mods for Minecraft 1.21.4. Players should install the latest stable version of Fabric Loader (currently 0.16.9).

Deprecations and removals

The following deprecated module was removed: fabric-rendering-v0. FabricModelPredicateProviderRegistry, which was previously deprecated, was also removed.

BuiltinItemRenderer and BuiltinItemRendererRegistry from the Rendering v1 module were removed and have been replaced by a transitive access widener to SpecialModelTypes.ID_MAPPER.

AttachmentRegistry#builder was deprecated in favor of create methods. The old method is inconvenient, as it requires explicit type parameters. (See the “Data Attachment Syncing” section for an example.)

BlockPickInteractionAware was removed, the new pick item events should be used instead.

Breaking change

CustomIngredient#getMatchingStacks must now return a stream, not a list.

New Fabric API changes

With the help of many contributors, Fabric API has received some new features since the last update blog post:

Convention Tags: Add more tags (JT122406, TelepathicGrunt, IThundxr)
Data Attachments: Registration enhancements (forgetmenot13579)
Data Attachments: Sync API (Syst3ms)
Lifecycle Events: Add ServerChunkEvents.Generate (jpenilla)
Lifecycle Events: Add AFTER_CLIENT_WORLD_CHANGE (fishshi)
Transfer API: Add support for Item-containing Items (BasiqueEvangelist)

In addition, a longstanding bug that caused language files to not load after overriding assets/minecraft/lang/en_us.json in a dedicated server mod was fixed.

Data Attachment Syncing

Fabric API can now sync data attachments. To make a syncable attachment, call syncWith inside the builder. The passed packet codec is used to serialize the attached data. Here is how a thirst attachment would look like:

public static final AttachmentType<Integer> THIRST = AttachmentRegistry.create(
    Identifier.of("modid", "thirst"),
    builder -> builder 
        .initializer(() -> 20) // start with a default value like hunger
        .persistent(Codec.INT) // persist across restarts
        .syncWith(PacketCodecs.VAR_INT, AttachmentSyncPredicate.targetOnly()) // only the player's own client needs the value for rendering
    );

The sync predicate (AttachmentSyncPredicate) controls who gets the synced data. For example, global data can be synced using all(). For more granular control, you can also pass a custom predicate.

Pick item events

Minecraft 1.21.4 moves the ‘Pick Block’ functionality from the client to the logical server. As such, the existing client events have been replaced with new, server-side ones. This replaces ClientPickBlockApplyCallback, ClientPickBlockCallback, and ClientPickBlockGatherCallback. This change also applies to entities (EntityPickInteractionAware).

The new events are PlayerPickItemEvents#BLOCK for picking a block and PlayerPickItemEvents#ENTITY for picking an entity(‘s spawn egg). Return ItemStack.EMPTY to stop the picking, and return null to use the default behavior.

PlayerPickItemEvents.BLOCK.register((player, pos, state, requestIncludeData) -> {
    if (state.isIn(MyTags.NOT_PICKABLE)) return ItemStack.EMPTY;

    return null; // use default behavior
})

requestIncludeData is true if the client requests NBT to be included in the returned item stack (by holding Ctrl while picking block). This parameter is also available to the entity pick item event, even though vanilla does not use this functionality (spawn eggs do not include the picked entity’s NBT).

Note that this only checks if the client is asking NBT data, and does not check game mode or permission level. In vanilla, NBT data is only included for Creative mode players.

Client Data Generation

Starting with Minecraft 1.21.4, Mojang has moved a number of data generation classes to the client. Loom 1.9 adds a new option that allows you to run your data generation against the client. See the following example if you are using the fabricApi utility to set up data generation:

  fabricApi {
-     configureDataGeneration()
+     configureDataGeneration {
+       client = true
+     }
  }

If you are using the createSourceSet option, your datagen source set will now have access to Minecraft’s client-only classes and classes in your client source set. Other than updating the data generators themselves, no other changes will be necessary.

If you are using the splitEnvironmentSourceSets option but not the createSourceSet option, you should move your DataGeneratorEntrypoint implementation from the main source set to the client source set.

Model Loading API

ModelModifier events and callbacks have been split; there is now one set for static models and one set for block models. This was necessary because static models use UnbakedModel and are baked with settings while block models use GroupableModel (which no longer extends UnbakedModel) and are not baked with settings. It also allowed cleaning up the identifier getters and providing the BlockState directly to ModelModifier.OnLoadBlock.

However, all BeforeBake and AfterBake events were removed. This is because their behavior can now be achieved using the OnLoad events, by wrapping the given model and overriding the bake method to replace the unbaked model passed to super.bake (to replicate BeforeBake) or replace the result of super.bake (to replicate AfterBake). This is possible because 1.21.4 made it so the parent of a JsonUnbakedModel no longer has to be another JsonUnbakedModel. To make this easier, the utility classes WrapperUnbakedModel and WrapperGroupableModel were added, which forward all method calls to a wrapper field. There were also some minor fundamental issues with BeforeBake and AfterBake events, which prompted their removal.

ModelModifier.OnLoad can now accept a null model, which is a model that was requested during resolution but does not have a corresponding JSON file. With this change, ModelResolver was removed as its behavior could now be achieved with ModelModifier.OnLoad with OVERRIDE_PHASE.

DelegatingUnbakedModel was removed as GroupableModel no longer extends UnbakedModel, so BlockModelResolvers can no longer use it, which was its original purpose.

textureGetter was removed from ModelModifier callback contexts as it is now accessible through Baker#getSpriteGetter.

FRAPI’s WrapperBakedModel was moved to Model Loading API and was renamed to UnwrappableBakedModel to avoid conflicts with vanilla’s new WrapperBakedModel. UnwrappableBakedModel is also implemented and interface injected on vanilla’s WrapperBakedModel. A new static UnwrappableBakedModel#unwrap method was added which accepts a Predicate saying when to stop unwrapping. See the documentation for more details.

Minecraft changes

Block Models

Previously, block entities could choose whether they rendered their block model in addition to any custom block entity rendering. This method has been removed, as now all block entities render their block models:

- @Override
- protected BlockRenderType getRenderType(BlockState state) {
-     return BlockRenderType.ENTITYBLOCK_ANIMATED;
- }

While block models were already used to provide particle textures in these cases, mods should still ensure their block entities’ block models are correct.

Item Models

Similar to the blockstate definition json files found in assets/<namespace>/blockstates, items now utilize new item model definition json files in assets/<namespace>/items to determine which models to use.

These can be quite simple…

{
  "model": {
    "type": "minecraft:model",
    "model": "modid:item/my_item"
  }
}

or more complex…

{
  "model": {
    "type": "minecraft:condition",
    "property": "minecraft:fishing_rod/cast",
    "on_false": {
      "type": "minecraft:model",
      "model": "modid:item/netherite_fishing_rod"
    },
    "on_true": {
      "type": "minecraft:model",
      "model": "modid:item/netherite_fishing_rod_cast"
    }
  }
}

utilising conditions and other logic to determine which model to use.

They also control applying color tints to item textures.

{
  "model": {
    "type": "minecraft:model",
    "model": "minecraft:item/template_spawn_egg",
    "tints": [
      {
        "type": "minecraft:constant",
        "value": 6925483
      },
      {
        "type": "minecraft:constant",
        "value": 12238402
      }
    ]
  }
}

These tints can be constant or based on other factors such as potion contents, map colors, etc.

As a result of these files being introduced, blocks whose item models previously simply referred to their block model no longer require a separate item model file, as the block model is referred to in the model definition file instead. For example,

- {
-  "parent": "modid:block/maple_planks"
- }

at assets/modid/models/item/maple_planks.json can be removed, in favor of

+ {
+  "model": {
+    "type": "minecraft:model",
+    "model": "modid:block/maple_planks"
+  }
+ }

in assets/modid/items/maple_planks.json.

Additionally, ItemColors and related APIs for tinting items have been removed, as item color tints are now controlled by these files.

For further information, these jsons are well documented on the vanilla Minecraft wiki here and all the ones used by vanilla items can be easily found in the game files.

For modders using data generation, these can be generated much like any other JSON asset.

Miscellaneous

Resource Metadata files now use Codec serializers
Equipment assets were moved from assets/<namespace>/models/equipment to assets/<namespace>/equipment
The minecraft:tall_flowers block tag was removed
The minecraft:flowers, minecraft:tall_flowers, and minecraft:trim_templates item tags were removed
The minecraft:herobrine entity was removed
Trim Material jsons no longer specify an item model index, as trimmed items now use separate item models for each material
Textures for item outlines shown in empty slots in certain GUIs are now located in assets/<namespace>/textures/gui/sprites/container/slot

Yarn changes

There have been many changes to Yarn mappings to reflect refactors to the vanilla game, fix issues with the mappings, or to otherwise improve them.

Some notable examples include:

The net/minecraft/data/client package got moved to net/minecraft/client/data, to reflect the classes now being client-only
To match this, the net/minecraft/data/server package was removed and its contents moved down to net/minecraft/data
All references to xp got changed to experience
BlockStateModelGenerator.TintType was changed to BlockStateModelGenerator.CrossType
CherryLeavesBlock was changed to ParticleLeavesBlock
CherryLeavesParticle was changed to LeavesParticle
LichenGrower was changed to MultifaceGrower
EntityModelLoader was changed to LoadedEntityModels
CocoaBeansTreeDecorator was changed to CocoaTreeDecorator
BakedQuad#colorIndex was changed to tintIndex

Fabric for Minecraft 1.21.2 & 1.21.3

2024-10-14T00:00:00+00:00

Minecraft 1.21.2, the “Bundles of Bravery” drop, is expected to release soon. Mojang has recently announced that they will release these “drops” throughout the year. Like with other updates, this drop contains some significant changes affecting mod makers.

As always, we ask all players to be patient, and give mod developers time to update to this new version. We ask everyone kindly not to pester them. We also recommend all players to make a backup of their worlds.

Here is a list of all major modder-facing changes in this version. Note that all code references are using Yarn mappings; modders using alternative mappings may need to use different names.

Fabric changes

Developers should use Loom 1.8 (at the time of writing) to develop mods for Minecraft 1.21.2. Players should install the latest stable version of Fabric Loader (currently 0.16.7).

Fabric Loader changes

Fabric Loader 0.16.0 was released some time ago. Most notably, this release updates the bundled MixinExtras to 0.4.0.

In addition, Fabric Loader 0.16.7 added support for Java 23. However, you should continue to use Java 21 for mod development and gameplay.

MixinExtras additions

The following new features have been added:

@WrapMethod, which allows wrapping the entire method
@Cancellable, which allows cancellation from all injectors.
namespace parameter in @Share to share values between Mixins

Loom 1.8

Loom 1.8 adds support for configuration caches, Gradle 8.10, and other changes and fixes.

Configuration cache is an opt-in Gradle performance enhancement feature that will be enabled by default in Gradle 9. Because this may break existing setup, we only recommend using this if you are familiar with Gradle buildscripts. To support this change, multi-project optimization has been removed.

New Fabric API changes

With the help of many contributors, Fabric API has received some new features since the last update blog post:

Convention Tags: Add more tags (TelepathicGrunt, Juuz)
Crash Report Info: Print the full stack trace from the dedicated server watchdog (TelepathicGrunt)
Entity Events: Add after damage event (TheDeathlyCow)
Item API: Modify enchantment and add component map builder extensions (TheDeathlyCow)
Item Group API: Add API to control creative inventory screen (modmuss50)
Loot API: Loot API v3 (modmuss50)
Networking: Add MinecraftClient/Server instances to networking contexts (modmuss50)
Networking: Add ClientConfigurationConnectionEvents#START (modmuss50)
Networking: Add access to ClientConfigurationNetworkHandler in context (Earthcomputer)
Object Builder: Add an API to add additional supported blocks to block entity types (modmuss50)
Renderer API: Add ShadeMode (PepperCode1)
Renderer API: Quads overloads for joml interfaces (SHsuperCM)
Resource Conditions: Allow conditions inside pack overlays (Apollo)
Resource Loader: Add API to create reload listeners with a registry lookup (modmuss50)
Removed Herobrine (Tiny Potato)
Transfer API: Crafter support (modmuss50)
Transfer API: Add ItemVariant#withComponentChanges (BasiqueEvangelist)

Breaking changes and deprecations

Note: breaking changes related to vanilla changes are addressed separately below.

One deprecated module was removed: fabric-renderer-registries-v1.

In Resource Condition, the test method now takes RegistryOps.RegistryInfoGetter. Tags can no longer have resource conditions. Similarly, in Resource Loader, ResourceReloadListenerKeys#TAGS was removed.

The following deprecations were made since the last blogpost:

Content Registries: VillagerInteractionRegistries#registerCollectable was deprecated. Use the vanilla tag, minecraft:villager_picks_up, instead.
Loot API: Loot API v2 was deprecated. Use Loot API v3, which passes registry contexts, instead.
Networking:ClientConfigurationConnectionEvents#READY was renamed to COMPLETE. (This was done during the 1.21 update cycle, but after we published the last blogpost.)

Minecraft changes

`ServerWorld` parameters

Many methods that must be executed on the server side only now require ServerWorld to be passed explicitly. Do not cast just to fix a type error; many events and overridden method are still called on both the client side and the server side.

Instead, wrap all logic that must be run only on the server side with if (world instanceof ServerWorld serverWorld). The serverWorld can be passed to those methods.

For example, Entity#damage now requires ServerWorld, and is therefore only called on the server side. There is an additional method, clientDamage, which is called only on the client side.

Block and item settings

Minecraft 1.21.2 uses registry keys to pre-compute certain block or item settings. This allows referencing them in default item components. For example, rather than computing a default name based on an item’s registry key inside getName method if the minecraft:item_name component is not present, every item now contains the minecraft:item_name component.

Because of this, you must manually set registry keys in the settings of every block and item. Failure to do so will result in crashes such as:

NullPointerException: Block id not set
NullPointerException: Item id not set

Both settings classes provide a simple method which should be called for every item or block with their respective registry key:

Identifier id = Identifier.of("mymod", "test_item");
RegistryKey<Item> key = RegistryKey.of(RegistryKeys.ITEM, id);

Item.Settings settings = new Item.Settings()
    // If your item is based on a block
    .useBlockPrefixedTranslationKey()
    .registryKey(key);

Registry.register(Registries.ITEM, key, new Item(settings));

Identifier id = Identifier.of("mymod", "test_block");
RegistryKey<Block> key = RegistryKey.of(RegistryKeys.BLOCK, id);

Block.Settings settings = new Block.Settings()
    .registryKey(key);

Registry.register(Registries.BLOCK, key, new Block(settings));

Make sure to call the Item.Settings#useBlockPrefixedTranslationKey method for block items so that they use the block.<namespace>.<path> translation key format.

This change affects the following traits:

Item names (minecraft:item_name component)
Item models (minecraft:item_model component)
Block models
Block loot table key

Some traits, such as the cooldown group of items with cooldowns, still dynamically look up a registry key, but this pattern should be avoided as much as possible.

Block#getLootTableKey now returns Optional<RegistryKey>. A block without a corresponding loot table now returns an empty optional instead of the minecraft:empty loot table registry key.

In Fabric API, the previously-deprecated FabricBlockSettings class was removed. Use the vanilla AbstractBlock.Settings class instead.

Furnace fuels

Furnace fuels are now registered through an event, which allows access to new parameters:

- FuelRegistry.INSTANCE.add(ModItems.TEST_ITEM, 50);
+ FuelRegistryEvents.BUILD.register((builder, context) -> {
+     builder.add(ModItems.TEST_ITEM, context.baseSmeltTime() / 4);
+ });

The base smelt time can be used to express a fuel’s smelt time in terms of a ratio. The default base smelt time is 200 ticks, or 10 seconds.

Entities

EntityType received a registry key change similar to the block and item one described above. When building an EntityType, pass a RegistryKey for the entity type. The no-argument version of the EntityType.Builder#build method, injected by FabricEntityTypeBuilder, has been removed. For example:

Identifier id = Identifier.of("mymod", "test_entity_type");
RegistryKey<EntityType<?>> key = RegistryKey.of(RegistryKeys.ENTITY_TYPE, id);

EntityType<TestEntity> entityType = EntityType.Builder.<TestEntity>create(TestEntity::new, SpawnGroup.MISC)
    .build(key);

Registry.register(Registries.ENTITY_TYPE, key, entityType);

Mob conversion (such as zombie villager curing or slimes splitting on death) was overhauled. The exact behavior of conversion is now handled by methods implemented by values of the EntityConversionType enum. When using the MobEntity#convertTo method to convert a mob, an EntityConversionContext is now required. This context is also now passed to Fabric API’s ServerLivingEntityEvents#MOB_CONVERSION event.

When creating an entity, a spawn reason is now required:

- Entity pig = EntityType.PIG.create(overworld);
+ Entity pig = EntityType.PIG.create(overworld, SpawnReason.SPAWN_ITEM_USE);

The prefixes of attributes in EntityAttributes, like GENERIC, have been dropped. This matches a change in the identifiers of attributes:

- public static final RegistryEntry<EntityAttribute> GENERIC_ATTACK_KNOCKBACK = register(
-    "generic.attack_knockback",
-    new ClampedEntityAttribute("attribute.name.generic.attack_knockback", 0, 0, 5)
);
+ public static final RegistryEntry<EntityAttribute> ATTACK_KNOCKBACK = register(
    "attack_knockback",
    new ClampedEntityAttribute("attribute.name.attack_knockback", 0, 0, 5)
);

Data generation

A recipe provider must now override getRecipeGenerator instead of generate. The new method takes the registries and exporter, and returns a new instance of RecipeGenerator that actually generates the recipes.

- public void generate(RecipeExporter exporter) {
-    offerPlanksRecipe2(exporter, SIMPLE_BLOCK, ItemTags.ACACIA_LOGS, 1);
+ protected RecipeGenerator getRecipeGenerator(RegistryWrapper.WrapperLookup registries, RecipeExporter exporter) {
+    return new RecipeGenerator(registries, exporter) {
+        @Override
+        public void generate() {
+            offerPlanksRecipe2(SIMPLE_BLOCK, ItemTags.ACACIA_LOGS, 1);

ActionResult

Previously, action results have been represented in several ways, including the ActionResult, ItemActionResult, and TypedActionResult classes. In Minecraft 1.21.2, these classes have been merged into a single ActionResult class, which provides direct replacements for the previous methods for all three classes:

Old	New
`ActionResult.success(world.isClient())`	`ActionResult.SUCCESS`
`TypedActionResult.pass(stack)`	`ActionResult.PASS`
`TypedActionResult.fail(stack)`	`ActionResult.FAIL`
`TypedActionResult.success(stack, world.isClient())`	`ActionResult.SUCCESS`
`TypedActionResult.consume(stack)`	`ActionResult.CONSUME`

If an action replaces the hand stack with another instance of ItemStack, then it should be marked with the ActionResult#withNewHandStack method. For example, an Item#use implementation that replaces the hand stack might be:

public ActionResult use(World world, PlayerEntity user, Hand hand) {
    ItemStack stack = user.getStackInHand(hand);
    
    if (stack.getCount() > 16) {
        ItemStack newStack = new ItemStack(Items.BLAZE_ROD, 16);
        return ActionResult.SUCCESS.withNewHandStack(newStack);
    }
    
    return ActionResult.PASS;
}

On the other hand, if the ItemStack instance for the hand stack is the same as the one provided to an interaction method such as Item#use, the ActionResult#withNewHandStack method should not be called.

This change affects all places where TypedActionResult and ItemActionResult were previously used in Minecraft’s code. In Fabric API, the UseItemCallback event in the Events Interaction module now returns ActionResult instead of TypedActionResult<ItemStack>.

Item components

Because elytra behavior is now controlled by a new item component, minecraft:glider, FabricElytraItem was removed. Add the component to your elytra item instead.

Block entities

In Minecraft 1.21.1 (released in August), a change was made that required mods to add all supported blocks to block entities. For example, a mod with a new sign block must add the block to BlockEntityType#SIGN:

BlockEntityType.SIGN.addSupportedBlock(ModBlocks.TEAL_SIGN);

In Minecraft 1.21.2, block entity types are no longer constructed using builders. Therefore, FabricBlockEntityType.Builder was removed, while FabricBlockEntityTypeBuilder is no longer deprecated.

Registries

Registry now implements RegistryEntryLookup. This resulted in several name changes. To query a RegistryEntry from RegistryKey, use getOptional or getOrThrow. (Same applies to RegistryEntryList from TagKey.) If you want to query the registry value, use getValueOrThrow. See the table below for all changes.

Old	New
`getEntry`	`getOptional`
`entryOf`	`getOrThrow`
`getOrThrow`	`getValueOrThrow`
`getOrEmpty`	`getOptionalValue`
`getEntryList`	`getOptional`

Similarly, DynamicRegistryManager#get and RegistryWrapper.WrapperLookup#getWrapperOrThrow has been renamed to getOrThrow. getOptionalWrapper was renamed tp getOptional.

Rendering

Entity rendering

Entity rendering has received a large refactor that decouples the Entity instance from its respective rendering calls. EntityRenderer now has an additional type parameter, S extends EntityRenderState, which represents a ‘render state’, which is a mutable class containing only the parameters of the entity that are used in rendering.

Previously, renderer methods accessed the entity instance directly. However, accessing entity information now happens in three steps.

First, the EntityRenderer#createRenderState method is called to construct an instance of S for the given entity with placeholder values:

public T createRenderState() {
    return new T();
}

Next, the EntityRenderer#updateRenderState method performs the operation of copying information from the entity to its render state:

public void updateRenderState(T entity, S state, float tickDelta) {
    super.updateRenderState(entity, state, tickDelta);

    // Example: entity has an 'is saddled' field
    state.isSaddled = entity.isSaddled();
}

Finally, the EntityRenderer#render method (as well as other renderer methods) accesses information from the entity’s render state:

public void render(S state, MatrixStack matrices, VertexConsumerProvider vertexConsumers, int light) {
    super.render(state, matrices, vertexConsumers, light);
    
    if (state.isSaddled) {
        // Render the saddle
    }
}

Shaders

In Fabric Rendering API, CoreShaderRegistrationCallback was removed. Vanilla resource pack now allows loading modded core shaders.

Other changes

WorldRenderer methods for rendering certain vertices (like a box) were transferred to VertexRendering.

Recipes

The recipe system was reworked. To summarize:

Recipes are now identified using RegistryKey<? extends Recipe>, not Identifier.
Recipe and the recipe ID is now server-side only. It cannot be accessed from the client.
Instead, clients receive RecipeDisplayEntry. It contains all information needed to display and run the recipe book. Recipes are identified using an integer (NetworkRecipeId) on the client. A recipe can have multiple display entries.
IngredientPlacement controls the placement of ingredients on the crafting table, while RecipeMatcher handles recipe matching.

Ingredient is now internally a list of items, not item stacks.

In Fabric API, CustomIngredientSerializer#getCodec: allowEmpty param removed, empty now always disallowed.

Biome

Water cave carvers (which, before 1.18, were seen in seabeds) were removed, along with GenerationStep.Carver.

In Fabric Biome API, biome modification methods like addCarver and removeCarver no longer takes GenerationStep.Carver argument.

Profiler

The shared profiler is now accessed using Profilers#get.

- world.getProfiler().push("tinyPotato");
+ Profilers.get().push("tinyPotato");

Loot tables

LootTables#EMPTY was removed. The game uses Optional to mark the lack of loot tables.

Some loot context-related logics are now shared with recipes, resulting in name changes. LootContextParameter is now ContextParameter, and LootContextType is now ContextType.

Yarn renames

This section only affects those using the Yarn mapping.

As part of regular Yarn maintainace, the following changes were made. These should be a simple replacement:

ModelTransformationMode is transferred to net.minecraft.item.
RealmsLoadingWidget is renamed to LoadingWidget and transferred to client.gui.widget.
Several Brain and Task-related names: see the pull request for details.
registryLookupFuture is renamed to registriesFuture in several locations.
Codecs#NONNEGATIVE_INT is renamed to NON_NEGATIVE_INT.
QUATERNIONF and VECTOR3F are renamed to QUATERNION_F and VECTOR_3F.
Screen#initTabNavigation is renamed to refreshWidgetPositions.
ComponentMapImpl is renamed to MergedComponentMap.
ContainerComponentModifier#create is renamed to apply.
ItemStack#encode is renamed to toNbt.

Fabric for Minecraft 1.21 & 1.21.1

2024-05-31T00:00:00+00:00

Minecraft 1.21 is expected to be released on June 13, with some significant changes affecting mod makers.

It’s been only a month and a half since we last released a blogpost. Yet, this update is nothing small - some changes are likely to affect most, if not all, mods.

Here is a list of all major modder-facing changes in this version. Note that all code references are using Yarn mappings; modders using alternative mappings may need to use different names.

Fabric changes

Developers should use Loom 1.6 (at the time of writing) to develop mods for Minecraft 1.21. Players should install the latest stable version of Fabric Loader (currently 0.15.11).

New Fabric API changes

With the help of many contributors, Fabric API has received some new features since the last update blog post:

Conventional Tags: Default English Translations for c namespaced tags (TelepathicGrunt)
Data Generation: Support extending dynamic registries in datagen (SquidDev)
Item API: Add API to modify default item components (modmuss50)
Resource Conditions: Support loading a single resource condition instead of array (Apollo)
Resource Conditions: Registry resource conditions (SquidDev)
Removed Herobrine (Tiny Potato)

Tag translation

Mods are now strongly encouraged to provide an English translation for item tags it provides. For example, the translation for test:potatoes should be declared like this:

{
    "tag.item.test.potatoes": "Potatoes"
}

Although these are not used by the API itself, other mods (such as recipe viewers) rely on them for proper display.

Breaking Changes

Note: breaking changes related to vanilla changes are addressed separately below.

One deprecated module was removed: fabric-models-v0.

In Item API, EquipmentSlotProvider#getPreferredEquipmentSlot is now passed a LivingEntity. Implementations are expected to check themselves whether the slot is available, using entity.canUseSlot(EquipmentSlot). FabricItem#getAttributeModifiers was removed; use Default Components API instead.

Registry Sync now freezes the registry at an earlier point. This does not affect mods that register things in their ModInitializers, but might affect more complex mods. Make sure to register everything during ModInitializer.

Minecraft changes

This version brought many breaking changes, including data-driven Enchantments. Data pack structures also changed, using singular nouns (instead of plurals) in many places.

Identifier

Identifier constructor is now protected. Use the static method of or ofVanilla to construct Identifier. Replacing new Identifier with Identifier.of using text editors or IDEs should be sufficient.

- var id = new Identifier("example", "foo_bar");
- var id2 = new Identifier("test:single_argument");
- var creeper = new Identifier("minecraft", "creeper");
- @Nullable var customId = Identifier.of("namespace", unsanitizedInput);
+ var id = Identifier.of("example", "foo_bar");
+ var id2 = Identifier.of("test:single_argument");
+ var creeper = Identifier.ofVanilla("creeper"); // very slightly improved performance
+ @Nullable var customId = Identifier.tryParse("namespace", unsanitizedInput);

Pro tip: make a method to construct Identifier for your mod’s namespace; this can be imported later using import static to shorten your code.

public static Identifier id(String path) {
    return Identifier.of("mod_namespace", path);
}

Enchantments

Enchantments are now data-driven. This means that they are no longer hardcoded - instead, they’re part of data packs. Consequentially, there are several important changes in how mods handle enchantments.

Generally, enchantments either “do something” (like causing an explosion), or “modify a value” (like attack damage). Example: Instead of checking if the player has Thorns and applying damage to the attacker, a mod should now call EnchantmentHelper#onTargetDamaged which should automatically handle this. Example 2: Instead of checking the level of Knockback, a mod should now call EnchantmentHelper#modifyKnockback with the original knockback.
Sometimes, a code needs to check if an item has certain enchantments. Because enchantments are no longer hard-coded, this is done using enchantment tags. Example 3: Breaking a beehive with Silk Touch prevents bees from getting released. Previously, this was done by checking for the Silk Touch enchantment. Now, this is done by calling EnchantmentHelper#hasAnyEnchantmentsIn(stack, EnchantmentTags#PREVENTS_BEE_SPAWNS_WHEN_MINING).

Enchantment Code Structures

An Enchantment is, well, an enchantment. Because it is now defined by a dynamic registry, it is often handled as RegistryEntry<Enchantment>. These can be obtained from the dynamic registry, i.e. world.getRegistryManager() or the registryLookup passed to various methods.

An enchantment has effect components, which is a map of effect types to list of effects. Effect types are pre-defined keys that enchantments can define behaviors for. For example, an enchantment may want to add “multiply by 2” behavior for DAMAGE effect type, or “explode” behavior for POST_ATTACK effect type. These are defined in EnchantmentEffectComponentTypes.

The values of effect components are EnchantmentEffectEntry. This is a pair of the effect and an optional condition. LootCondition is reused for this purpose.

Enchantment effects can be categorized into three categories:

EnchantmentValueEffect. When given a value, the effect calculates the modified value. Examples include Protection (which modifies DAMAGE_PROTECTION), Lure (FISHING_LUCK_BONUS), Unbreaking (ITEM_DAMAGE), and Multishot (PROJECTILE_COUNT).
EnchantmentEntityEffect. This effect does something when triggered. Examples include Thorns and Channeling (POST_ATTACK) and Flame (PROJECTILE_SPAWNED).
AttributeEnchantmentEffect, which adds an attribute to the entity. Unlike entity effects, attributes persist until the enchantment becomes inapplicable.

EnchantmentLocationBasedEffect is an interface implemented by EnchantmentEntityEffect and AttributeEnchantmentEffect. In addition, some enchantment effect types simply require effective values to be specified directly - like CROSSBOW_CHARGING_SOUNDS, which is a list of sounds. Some effects, like PREVENT_ARMOR_CHANGE, cannot be configured further.

Using Vanilla Enchantments

EnchantmentHelper methods can be used to handle vanilla enchantments.

// Example of modifying a value
float newDamage = EnchantmentHelper.getDamage(
    world,
    stack,
    attackTarget,
    damageSource,
    baseDamage
);

// For values with no base value (such as Protection)
float protection = EnchantmentHelper.getProtectionAmount(
    world,
    user,
    damageSource
);

// Entity-based effect
EnchantmentHelper.onTargetDamaged(
    world,
    attackTarget,
    damageSource,
    weapon
);

// Checking if an ItemStack is enchanted with certain enchantments
if (EnchantmentHelper.hasAnyEnchantmentsIn(
    stack,
    EnchantmentTags.PREVENTS_BEE_SPAWNS_WHEN_MINING
)) {
    return;
}

// Checking for nonconfigurable effects
// e.g. checking for Curse of Binding
if (EnchantmentHelper.hasAnyEnchantmentsWith(
    stack,
    EnchantmentEffectComponentTypes.PREVENT_ARMOR_CHANGE
)) {
    return;
}

Adding a new Enchantment

Adding a new enchantment is now done by writing JSON files. You can use Data Generation to generate enchantments easily.

An enchantment can perform many tasks, like applying attributes, replacing blocks or summoning an entity. However, not all things are possible. To add a custom effect type, a new effect class must be created and its codec registered. An effect type must exist in both the client and the server.

Enchantment tags are used to specify exclusive enchantments (e.g. Fortune and Silk Touch) and where the enchantments can be obtained. Make sure to add your enchantments to those tags.

The following event callbacks now pass RegistryEntry<Enchantment> instead of Enchantment:

EnchantmentEvents.AllowEnchanting#allowEnchanting
FabricItem#canBeEnchantedWith
FabricItemStack#canBeEnchantedWith

EnchantmentContext was reworked. Previously, a context was one of RANDOM_ENCHANTMENT, ANVIL, ENCHANT_COMMAND, or LOOT_RANDOM_ENCHANTMENT. To clarify its purpose, they are now one of ACCEPTABLE (e.g. anvils) or PRIMARY (e.g. enchanting tables). For example, a helmet can be enchanted with Thorns using anvils but not in enchanting tables, because only chestplates are PRIMARY in case of Thorns.

Teleportation

Both intra-dimensional and cross-dimensional teleportation can now be performed using Entity#teleportTo (previously known as moveToWorld). TeleportTarget now contains the destination world and position.

FabricDimensions was removed, because its only API, teleport, is effectively superseded with Entity#teleportTo.

Data Pack Paths

Data packs now use singular nouns in the following paths:

Tag subdirectories such as tags/blocks, tags/entity_types, tags/functions. They are now tags/block, tags/entity_type, and tags/function, respectively. The tags directory itself remains plural.
Advancements (previously advancements, now advancement).
Functions (functions to function).
Item modifiers/loot functions (item_modifiers to item_modifier).
Loot tables (loot_tables to loot_table).
Predicates/loot conditions (predicates to predicate).
Recipes (recipes to recipe).
Structures (structures to structure).

In Fabric API news, GameTest structure directories are now singular as well; instead of gametest/structures, they are now placed in gametest/structure.

Rendering Changes

In the Fabric Rendering API, HudRenderCallback now passes RenderTickCounter instead of tickDelta. tickDelta can be obtained from the counter. WorldRenderContext’s tickDelta and limitTime methods are also replaced with tickCounter.

There are some other, significant internal refactors to rendering. For example, BufferBuilder#next() was removed, and the methods for beginning or ending the building process has changed:

- BufferBuilder builder = tessellator.getBuffer();
- builder.begin(...);
+ BufferBuilder builder = tessellator.begin(...);
- builder.vertex(...).texture(...).color(...).next();
+ builder.vertex(...).texture(...).color(...)
- tessellator.draw();
+ BufferRenderer.drawWithGlobalProgram(builder.end());

Miscellaneous

FabricCodecProvider now has a new constructor that takes RegistryKey instead of directory name. This can be used with, for example, item modifier providers. The old constructor can still be used for non-registered codecs.