Fabric

Fabric for Minecraft 1.21.11

2025-12-05T00: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.

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.

Fabric for Minecraft 1.20.5 & 1.20.6

2024-04-19T00:00:00+00:00

Minecraft 1.20.5 is to be released in the near future with significant changes affecting mod makers.

But first, we need to make this clear: 1.20.5 is a record-breaking update. This development cycle spans from December 18, 2023 to April of 2024, the longest for any “dot release”. We saw 15 snapshots, the first time it became two digits for a dot release (previous record was 1.20.3 for 8 snapshots). And no surprise: the amount of changes is also unprecedented.

For this reason, 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. 1.20.5 is expected to be the last update of the 1.20 series.

We recommend all players to make a backup of the world. For content mod users, creating a new world is recommended, as most mods do not handle world data upgrades of this magnitude.

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.

Java 21

Minecraft 1.20.5 now requires Java 21 to run. This means mods can be compiled for Java 21 and use the latest features. This also marks the end of 32-bit support.

To set up a development environment you will need to use Java 21, Loom 1.6, and Gradle 8.6 or higher.

Fabric changes

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

Loom 1.5 & 1.6

There has been two major updates to Loom since the last blogpost: 1.5 and 1.6.

Loom 1.5 includes several performance boosts and small bug fixes. Notably, the mixins can now be remapped using the Tiny Remapper instead of Mixin annotation processor. When enabled, the mixins are remapped in-place and the output jar no longer contains a refmap. This is currently experimental and opt-in.

Loom 1.6 also brought more performance improvements. Decompiler caches were added, meaning that changes to access wideners no longer cause the entire game to be decompiled. There is also an update to how Loom handles existing locks (such as when two Gradle runs occur simultaneously) - it will no longer clear the cache, instead waiting for one process to exit. The error message for locked files is now more detailed, as well.

Please see the Loom 1.5 and Loom 1.6 release notes for all of the changes.

Localization

Fabric has recently moved to using Crowdin to help manage translations for our projects. This makes it much easier to contribute translations across all Fabric projects.

Current projects include Fabric API and installer. If you are able to help translate Fabric into your language, please visit the Crowdin website.

New Fabric API changes

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

New API: Data Attachments. This allows attaching custom data to block entities, chunks, entites, and worlds. Attached data can be saved or persisted between mob conversions. (Syst3ms)
Interaction Events: add client after block break event (kevinthegreat1)
GameTest API: add a system property for a custom output directory for gametest structures (ErrorCraft)
Entity Events: add mob conversion event (Syst3ms)
Fabric Rendering: add AtlasSourceTypeRegistry (PepperCode1)
Data Generation: add FabricCodecDataProvider (ErrorCraft)
Resource Loader: significant refactors to support pack.mcmeta metadata like filters and overlays. (apple502j)
Fabric Rendering: add support for custom ColorResolvers (PepperCode1)
Fluids Rendering: expose a function for querying the non-default fluid renderer (jellysquid3)
Lifecycle Events: add save events to ServerLifecycleEvents (MrNavaStar)
Item API: add enchantments API (Syst3ms)

There is one more addition for advanced developers: you can now declare Fabric API as a dependency using BOM or version catalogs. Check the pull request for more details.

Breaking changes and deprecations

Note: breaking changes related to vanilla changes are discussed below.

The following APIs were removed:

fabric-containers-v0 (previously deprecated)
fabric-events-lifecycle-v0 (previously deprecated)
fabric-mining-level-api-v1
ScreenRegistry and ScreenHandlerRegistry

ModifyItemAttributeModifiersCallback from the Item API was removed without replacement due to code changes making it infeasible to port.

In Object Builder API, FabricItemSettings was removed. Use vanilla Item.Settings instead; interface injection provides settings added by Fabric API. Similarly, FabricBlockSettings was deprecated and replaced with vanilla AbstractBlock.Settings. FabricEntityTypeBuilder and FabricBlockEntityTypeBuilder were also deprecated; use vanilla builders instead.

Codec-based Resource Conditions

Unrelated to the 1.20.5 update, a significant change was made to Resource Conditions’ internal workings. This update was developed by Apollo and apple502j. The only breaking change to the JSON syntax is the removal of (block/item/fluid)_tags_populated conditions, but data generation is heavily affected.

The ConditionJsonProvider interface has been removed and been replaced by ResourceCondition. ResourceCondition has a test method, for determining whether the condition should pass, and getType, which returns a ResourceConditionType. withConditions methods in data providers now take ResourceCondition instances. Methods in DefaultResourceConditions that created conditions have been moved to ResourceConditions. A custom ResourceConditionType should be registered with ResourceConditions#register.

In addition, fabric:true condition was added. This condition always passes.

Convention Tag unification

Another significant change was made in the Convention Tags. As part of collaborative efforts with NeoForge, TelepathicGrunt has prepared (and we released) the version 2 of the tags. Version 1 is now deprecated.

As the changes are too long to list here, developers are encouraged to check the pull request.

Minecraft changes

In short, these are the veeery major changes:

Item Components. Item stacks no longer use NBT as runtime data storage, instead using predefined “components” to keep values like custom name, enchantments, or damage.
Networking. Instead of manually processing PacketByteBuf, packets are now serialized using PacketCodecs. In Fabric Networking API, the previous PacketByteBuf-based APIs were removed; the newer, FabricPacket-based API was rewritten to make use of the vanilla CustomPayload interface.
Registries. Likely as a preparation for data-driven blocks and items, serialization/deserialization of most objects now require RegistryWrapper.WrapperLookup instance. This is most noticeable in texts and data generation. In addition, loot tables are now managed by a new type of registry called “reloadable registries”.

Item Components

We skip the general description of the item components system, which you can check in the slicedlime’s video: News in Data Pack Version 33 (24w09a): Item Components!.

Now, we begin the journey into the implementation of item components:

There are five main objects in the item components:

DataComponentType, a type of components, serving as keys;
Component classes (can be any object), serving as values;
ComponentMap, a read-only view of components;
ComponentMapImpl, which is a ComponentMap that can be modified, and internally a pair of unmodifiable base ComponentMap and the “overrides” that are modified; and
ComponentChanges, a map of component type to the changes for the value (either setting it to a specific value or removing it). This can be used as a diff applied to ItemStack; you apply an instance of ComponentChanges to ItemStack/ComponentMapImpl, so that the overrides part of the map reflects the changes. In other parts of the code, ComponentChanges is just used as ComponentMapImpl minus the base.

So, how does this work?

Each item has the base components. In addition to the base components common to all items, like having empty EnchantmentsComponent, some items provide additional base components. A notable example is DataComponentTypes#DAMAGE for armors, tools, and weapons. A component type that exists in the base has a corresponding default value; here the default damage is 0.

An ItemStack can either 1) add an additional component not present in the base; 2) change the components from the one in the base; or 3) remove a component that exists in the base. The final components of ItemStack, obtainable as ComponentMap from ItemStack#getComponents, reflects all three.

Using Item Components

Item components on item stacks have a similar API surface to a map. Here are some common operations that can be done, using the example of an item’s custom name (note that Text is directly used as the component value):

// Similar to Map#get
@Nullable Text name = stack.get(DataComponentTypes.CUSTOM_NAME);

// Similar to Map#put
// Returns the previous value, if any
@Nullable Text oldName = stack.set(DataComponentTypes.CUSTOM_NAME, Text.literal("Lorem ipsum"));

// Similar to Map#getOrDefault
name = stack.getOrDefault(DataComponentTypes.CUSTOM_NAME, Text.empty());

// Similar to Map#remove
@Nullable Text removedName = stack.remove(DataComponentTypes.CUSTOM_NAME);

// Similar to Map#compute
// In this example, we change the color of the item name
// (Note: stack#getName already checks for custom name, so in reality this does not need apply() call.)
stack.apply(DataComponentTypes.CUSTOM_NAME, stack.getName(), current -> current.copy().formatted(Formatting.RED))

Getting/setting the custom data (NBT). This is useful for datapack makers and server-side modders, because custom item components (see below) need to be synced to the clients, while custom data remains an unparsed NBT.

Unlike the previous example, this uses a component record NbtComponent.

Note: component values are supposed to be immutable - even if you can modify it, don’t. Always copy and set().

NbtCompound nbt = ...;
NbtComponent component = NbtComponent.of(nbt);
// Setting
stack.set(DataComponentTypes.CUSTOM_DATA, component);

// Getting a copy
@Nullable var data = stack.get(DataComponentTypes.CUSTOM_DATA);

if (data != null) {
    NbtCompound value = data.copyNbt();
}

// Using NbtComponent#apply, which copies automatically, to modify the NBT
// Note: you might want to use the static method NbtComponent#set instead,
// which makes this a bit shorter
stack.apply(DataComponentTypes.CUSTOM_DATA, NbtComponent.DEFAULT, comp -> comp.apply(currentNbt -> {
    currentNbt.putInt("key", 0);
}));

// Checking if a certain NBT is a subset of the stack NBT
// (also known as: "non-strict matching")
NbtCompound requiredNbt = ...;
boolean match = stack.getOrDefault(DataComponentTypes.CUSTOM_DATA, NbtComponent.DEFAULT).matches(requiredNbt);
// use createPredicate to make Predicate<ItemStack>

Using ComponentChanges to mass-modify the components of ItemStack:

// stack is a damageable item.
// Repair the item and remove custom name.
// Note that the resulting stack has no components because 0 damage is the default from the base components.
var changes = ComponentChanges.builder().add(DataComponentTypes.DAMAGE, 0).remove(DataComponentTypes.CUSTOM_NAME).build();
stack.applyChanges(changes);

Making an item with base components:

Item item = new Item(new Item.Settings().component(DataComponentTypes.CUSTOM_NAME, Text.literal("Hello")));
// Call #component multiple times for multiple base components.
// Note: calling maxDamage automatically adds DAMAGE component.

Making a custom component. Note that like many registered entries, these must be present in both the client and the server.

public static final DataComponentType<Integer> WEIRDNESS = DataComponentType.builder().codec(Codec.INT).packetCodec(PacketCodecs.VAR_INT).build();
// in the initializer
Registry.register(Registries.DATA_COMPONENT_TYPE, new Identifier("example", "weirdness"), WEIRDNESS);

Some caveats

Component values should not be modified directly. Using Record or other immutable object is highly recommended. Always copy, modify, then set.
Setting an invalid value for a component does not cause an error immediately, but will lead to a crash during save, and possible data corruption. A common example is NONNEGATIVE_INT being used for an incrementing value; when it overflows and the value is set to negatives, saving it would crash.

BlockEntity interaction with components

BlockEntity stores the components when placing a block item stack with components and when pick-blocking. Components are not currently used to serialize block entities themselves. A block entity that uses components, like custom containers, should override addComponents, readComponents, and removeFromCopiedStackNbt methods:

addComponents adds the block entity’s stored data to a component builder.
readComponents reads the block entity data from components.
removeFromCopiedStackNbt removes NBT keys which are now serialized using components when in item stacks. For example, a chest’s held stacks are stored under Items key when the block entity itself is serialized, and stored under a component when an item stack for the block entity is serialized. To prevent double serialization, this method removes Items from the item stack NBT.

Note that LootableContainerBlockEntity handles component changes themselves, so you do not have to reinvent the wheel if you use them.

allowNbtUpdateAnimations method of FabricItem was renamed to allowComponentsUpdateAnimations. FabricItem.getAttributeModifiers changes? isSuitableFor and getFoodComponents of FabricItemStack removed/replaced with vanilla components.

Recipe API

DefaultCustomIngredients#nbt and support for NBT ingredients were removed, as the game no longer uses NBT to store item stack-specific data.

To check for custom name, enchantments, etc that were previously kept inside the NBT but are now recorded in the components (see below for details), use the new components ingredient. To check for custom data component (a NBT data not used by the game but can be used by data packs or commands), use the customData ingredient.

Transfer API

TransferVariant (such as FluidVariant or ItemVariant) is now a pair of the object and the components, instead of the object and NBT. getNbt, hasNbt, and nbtMatches methods were replaced with getComponents, hasComponents, and componentsMatch methods. The following methods were removed: copyNbt, copyOrCreateNbt, toNbt, and toPacket.

FluidVariant#of and ItemVariant#of now takes ComponentChanges instead of @Nullable NbtCompound.

TransferVariant is now serialized using codecs and packet codecs. Therefore, fromNbt and fromPacket static methods were removed.

SingleVariantStorage#writeNbt instance method was removed; subclasses now provide separate methods named writeNbt. Both readNbt and writeNbt now require passing a RegistryWrapper.WrapperLookup instance; they should be available in the methods from which they are called (or you can use the world’s DynamicRegistryManager instance).

Other Item changes

As noted in the video, an empty item stack is now serialized as omitting the field or an empty object. ItemStack#fromNbt now returns Optional<ItemStack> while fromNbtOrEmpty supports empty NBT object. Both now require passing the registries. These methods log an error when an item with ID minecraft:air is encountered.
writeNbt method was renamed to encode. The one with NbtCompound argument allows adding to the existing compound, like writeNbt.
The methods in ItemStack that reference Nbt are generally renamed to reference Components instead.
Item#isNbtSynced was removed, specify custom packet codecs instead.
Item#getBreakSound was added.
Attack damage and mining speed of MiningToolItem and SwordItem are now specified in item settings via attributeModifiers setting.
Item tooltips are now given a “tooltip type”, and TooltipContext is now under Item. ItemTooltipCallback Fabric API event now passes the type as well. Note that hide_tooltip item component prevents the event from being invoked.

Item damages

When damaging an item stack held in the hands or in the armor slots, you now pass the EquipmentSlot instead of a callback:

- stack.damage(1, entity, p -> p.sendToolBreakStatus(Hand.MAIN_HAND));
+ stack.damage(1, entity, EquipmentSlot.MAINHAND);

When damaging an item stack held by non-entities (like shears in dispensers), the stack must be broken by the newly passed callback, not by checking the return value.

- if (stack.damage(1, random, null)) stack.setCount(0);
+ stack.damage(1, random, null, () -> stack.setCount(0));

In Fabric API, CustomDamageHandler callback’s signature was changed from ItemStack stack, int amount, LivingEntity entity, Consumer breakCallback to ItemStack stack, int amount, LivingEntity entity, EquipmentSlot slot, Runnable breakCallback. Additionally, calling breakCallback now ignores the return value and vanilla damage handler (as the item is already broken).

Networking

Previously, networking code was simple: reading from, and writing to, PacketByteBuf. Although this method still works, Mojang has added an abstraction layor: PacketCodec.

PacketCodec works like the DataFixerUpper codecs used in JSON/NBT serialization - although they are not compatible with each other. To keep it simple, PacketCodec is a pair of deserializers and serializers - or, decoders and encoders. This change reduces bugs related to wrong read/write order - which is one of the most difficult bugs to identify.

How to create a PacketCodec

Note: A new subclass of PacketByteBuf, RegistryByteBuf, is used for PLAY-phase networking (the one you’re probably using). For ConfigurationNetworking, use PacketByteBuf instead of RegistryByteBuf. PacketCodecs are usually stored in a public static final field.

Suppose we are serializing this record:

public record VirtualHugs(int count) {
    // Note: replaced PacketByteBuf with RegistryByteBuf
    public VirtualHugs(RegistryByteBuf buf) {
        this(buf.readVarInt());
    }

    // Instance method
    public void write(RegistryByteBuf buf) {
        buf.writeVarInt(count);
    }

    // Static method, buffer-first
    public static void write2(RegistryByteBuf buf, VirtualHugs hugs) {
        buf.writeVarInt(hugs.count())
    }
}

The easy method - adopting existing code

PacketCodec<RegistryByteBuf, VirtualHugs> PACKET_CODEC = PacketCodec.of(VirtualHugs::write, VirtualHugs::new);

// Or, using static method:
PACKET_CODEC = PacketCodec.ofStatic(VirtualHugs::write2, VirtualHugs::new);

The new method - building codecs from other codecs, like in DataFixerUpper

// "tuple" is an ordered, un-keyed set of stuff.
// Up to 3 fields can be serialized with vanilla method.
// The constructor always comes last.
CODEC = PacketCodec.tuple(PacketCodecs.VAR_INT, VirtualHugs::count, VirtualHugs::new);

// Or, since there is only one field in VirtualHugs, this works too.
CODEC = PacketCodecs.VAR_INT.xmap(VirtualHugs::new, VirtualHugs::count);

You might see some nasty casting errors in some cases. Call .cast() on the codec to make it go away; it’s generally safe to do so.

Advanced PacketCodecs examples

Here are some more examples:

// For a singleton (like an empty packet). Encoding something other than INSTANCE will error.
// It does not actually touch the buffer.
var singleton = PacketCodec.unit(INSTANCE);

// Using PacketCodec from classic API
Text text = TextCodecs.PACKET_CODEC.decode(buf);
TextCodecs.PACKET_CODEC.encode(buf, text);

// Codec for Optional<Text>
// Compatible with PacketByteBuf#readOptional
var optText = TextCodecs.PACKET_CODEC.collect(PacketCodecs::optional);

// Codec for List<String>
var strings = PacketCodecs.STRING.collect(PacketCodecs.toList());

// or Set<String>, each max 16 chars
// both work fine, compatible with PacketByteBuf#readCollection
var stringSet = PacketCodecs.string(16).collect(PacketCodecs.toCollection(HashSet::new));
stringSet = PacketCodecs.collection(HashSet::new, PacketCodecs.string(16));

// Map<String, BlockPos>
var positions = PacketCodecs.map(HashMap::new, PacketCodecs.STRING, BlockPos.PACKET_CODEC);

// What? DataFixerUpper codecs?
// Nah, these are just serialized as NBTs.
var advancement = PacketCodecs.codec(Advancement.CODEC);

// Serializing NbtCompound
var nbt = PacketCodecs.NBT_COMPOUND;

// Serializing a registry value (by raw ID)
// Note: these require RegistryByteBuf!
PacketCodec<RegistryByteBuf, Item> item = PacketCodecs.registryValue(RegistryKeys.ITEM);
// Or, RegistryEntry
PacketCodec<RegistryByteBuf, Biome> biome = PacketCodecs.registryEntry(RegistryKeys.BIOME);

// Serializing an Enum
var axis = PacketCodecs.indexed(i -> Direction.Axis.VALUES[i], Direction.Axis::ordinal);

Fabric Networking API

Networking API no longer directly uses PacketByteBuf, except in LoginNetworking. Instead, you need to subclass CustomPayload and register it. Note that CustomPayload is a vanilla interface. While this is similar to the packet object-based networking introduced recently, it is different in some ways. (PacketType and FabricPacket were, therefore, removed.)

Compare the following, pre-snapshot packet:

public record SlapPacket(UUID slapped) implements FabricPacket {
    public static final Identifier ID = new Identifier(...);
    public static final PacketType<SlapPacket> TYPE = PacketType.create(ID, SlapPacket::new);
    
    public SlapPacket(PacketByteBuf buf) {
        this(buf.readUuid());
    }
    
    @Override
    public void write(PacketByteBuf buf) {
        buf.writeUuid(slapped);
    }
}

And a new one:

public record SlapPacket(UUID slapped) implements CustomPayload {
    public static final CustomPayload.Id<SlapPacket> PACKET_ID = new CustomPayload.Id<>(new Identifier(...));
    public static final PacketCodec<RegistryByteBuf, SlapPacket> PACKET_CODEC = Uuids.PACKET_CODEC.xmap(SlapPacket::new, SlapPacket::slapped).cast();
}

There are three differences you will notice:

Instead of now-removed FabricPacket, we implement CustomPayload.
Each CustomPayload implementation has its own CustomPayload.Id. Unlike PacketType, it lacks reference to the decoder.
The latter does not have a write method or PacketByteBuf-taking constructor. Instead, PACKET_CODEC field was added. (Note, you can make your PacketCodec from the constructor and the write method, so don’t just remove those!)

But, you may ask, how do you get the decoder if it’s not in Id? Good question. The answer: you need to register it in ModInitializer on both ends (sender and receiver). In fact, Fabric API will happily crash if you don’t before calling registerGlobalReceiver.

// SlapPacket is sent during gameplay
// from the client to the server (serverbound; C2S)
PayloadTypeRegistry.playC2S().register(SlapPacket.PACKET_ID, SlapPacket.PACKET_CODEC);
// Replace with configurationS2C, playS2C, etc.

Then, you can change the receiver. Instead of long parameters, the event callback now gets only 2 parameters: the payload that was sent, and a context object. (Don’t worry, it won’t eat the RAM.)

- ServerPlayNetworking.registerGlobalReceiver(SlapPacket.TYPE, (packet, player, sender) -> {
-   var world = player.getServerWorld();
+ServerPlayNetworking.registerGlobalReceiver(SlapPacket.PACKET_ID, (payload, context) -> {
+   var world = context.player().getServerWorld();
    var entity = world.getEntity(packet.slapped());
});

Here are the available fields in the context object:

`PayloadTypeRegistry`	Class	Context Fields
`playC2S`	`ServerPlayNetworking`	`player`, `responseSender`
`playS2C`	`ClientPlayNetworking`	`client`, `player`, `responseSender`
`configurationC2S`	`ServerConfigurationNetworking`	`networkHandler`, `responseSender`
`configurationS2C`	`ClientConfigurationNetworking`	`responseSender`

Note that the field shortcuts might be added later.

Finally, sending the packet also uses CustomPayload. Remember to register the codec first!

ClientPlayNetworking.send(SlapPacket.PACKET_ID, new SlapPacket(...));

// for PacketSender:
sender.sendPacket(new SlapPacket(...));

Note: PacketSender no longer provides APIs that use PacketByteBuf. For login networking where custom payloads are not used yet, use the subinterface LoginPacketSender.

Some other Networking API related changes:

FutureListeners was removed.
GenericFutureListener-taking methods in PacketSender were removed. Use the one taking PacketCallbacks.
ServerPlayNetworking#getServer was removed. handler.player.server should work.

Networking-adjacent changes in Fabric API

Particles API

FabricParticleTypes#complex now requires you to pass both Codec and PacketCodec for serializing the particle type. The string-based parser, ParticleType.Factory, was removed.

Recipe API

CustomIngredientSerializer must now override getPacketCodec. The read and write methods were removed. Use Ingredient#PACKET_CODEC for representing another ingredient (which Fabric API patches up to also support ours).

Screen Handler API

ExtendedScreenHandlerType now uses a payload object instead of PacketByteBuf. In the type constructor, you now need to pass PacketCodec:

public static final ExtendedScreenHandlerType<OvenScreenHandler> OVEN = new ExtendedScreenHandlerType((syncId, inventory, data) -> ..., OvenData.PACKET_CODEC);

Notice that the callback got data instead of buf, as well. Note that the payload object can be of any type, whether it be Identifier or your custom record. (These don’t have to be registered in PayloadTypeRegistry.)

ExtendedScreenHandlerFactory#writeScreenOpeningData was replaced with getScreenOpeningData. It takes the player as the sole argument and returns the data class, in this case, OvenData.

Registries

RegistryWrapper & datagen

Many methods for serialization now require RegistryWrapper.WrapperLookup instance. This is used to query registries, and DynamicRegistryManager instance can be used for this purpose. This change is most prominent in text and data generation-related code. This registry is used to query data-driven values during serialization.

Data provider constructors in Fabric API now take RegistryWrapper.WrapperLookup as a parameter; modders should change their constructors to take the instance and pass to the super constructor. In addition, FabricAdvancementProvider#generateAdvancement now also passes the instance.

public class TestBlockLootTableProvider extends FabricBlockLootTableProvider {
-    private TestBlockLootTableProvider(FabricDataOutput output) {
-        super(output);
+    private TestBlockLootTableProvider(FabricDataOutput output, CompletableFuture<RegistryWrapper.WrapperLookup> registryLookup) {
+        super(output, registryLookup);
    }

Loot Registries

Loot tables (including loot-adjacent stuff, namely predicates and item modifiers) are now managed by a special type of registry, called “reloadable registries”. Unlike ordinary registries, they are reloaded during /reload.

LootDataLookup was removed; ReloadableRegistries.Lookup can be obtained from server.getReloadableRegistries(). From there, item modifiers and predicates can be looked up via getRegistryManager; a shortcut exists for loot tables via getLootTable.

Registry-ification of loot table also means that they are now identified with RegistryKey. Use RegistryKey.of(RegistryKeys.LOOT_TABLE, id) to get the registry key. In Fabric API, VillagerInteractionRegistries#registerGiftLootTable now takes the registry key, while the ID-taking method is deprecated.

Fabric API’s Loot API received breaking changes. For the arguments passed to events, ResourceMaanger and LootManager is gone. In the LOAD_ALL event, the loot manager was replaced with Registry<LootTable>. In all places, Identifier is replaced with RegistryKey as described above. In addition, because mutating registry is impossible now, the loot tables are modified before addition; this means that per-table events don’t get the table registry anymore.

Other changes

A new syncing protocol is in place for DynamicRegistryManager entries. Vanilla data packs provide knownPackInfo fields, which are sent by the server on joined clients. Clients then reply with the subset of the info they understand (i.e. loaded on their side). When a registry entry is loaded from a pack with knownPackInfo, and the client has acknowledged the info for the pack, the server tells the client to refer to its own copy of the data, skipping sending the serialized entry over the network. Most importantly, this is currently not used by mod-provided packs, so the registry entries from mods will be sent even if the client has the same mod.

SimpleRegistry no longer supports changing the registered value post-registration (such as by the set method). For this reason, the RegistryEntryRemovedCallback event and the registeyEntryRemoved shortcut in DynamicRegistryView were removed.

Finally, SculkSensorFrequencyRegistry.register now takes RegistryKey<GameEvent> instead of GameEvent.

Blocks

All AbstractBlock public methods to be overridden were made protected and no longer marked as @Deprecated.

- public ActionResult onUse(BlockState state, World world, BlockPos pos, PlayerEntity entity, BlockHitResult hit) {
+ protected ActionResult onUse(BlockState state, World world, BlockPos pos, PlayerEntity entity, BlockHitResult hit) {
}

Enchantments

Enchantment constructor now takes Enchantment.Properties, a record of enchantment properties. EnchantmentTarget enum was replaced with tags that specifies enchantment-supporting items.

Brewing

FabricBrewingRecipeRegistry was replaced with FabricBrewingRecipeRegistryBuilder. The new FabricBrewingRecipeRegistryBuilder.BUILD event can be used to add new recipes to the brewing stand.

Entities

SpawnRestriction.Location enum was replaced with an interface, SpawnLocation. SpawnLocationTypes provides predefined SpawnLocations.

Client

In GUI, setting the initial focus of a screen is now done by overriding setInitialFocus, rather than calling it in init. MatrixStack was replaced with the actual matrix in several rendering code.

Rendering

Some places that previously take rgb was updated to take argb instead. The new DyedColorComponent takes argb. Item color providers also take argb instead of rgb, so make sure to wrap your color with ColorHelper.Argb.fullAlpha() or else your item may appear transparent if it is registered to the translucent render layer. Block color providers also argb now, but passing rgb still works.

Other

DataFixerUpper was updated. This includes several breaking changes, such as MapCodec being used in places defining extra fields. Use RecordCodecBuilder#mapCodec instead of create in this case. Another significant change: optionalFieldOf is now strict by default. This means that a decoding error in the field value is now treated as an error, instead of being silently skipped. The lenientOptionalFieldOf method restores old behavior.

On the Minecraft game code side, Util#getResult was replaced with decode(...).getOrThrow() method. Several methods and fields in Codecs were moved to the DFU itself, such as either, xor, and withAlternative (formerly Codecs#alternatively).

Fabric for Minecraft 1.20.3 & 1.20.4

2023-11-30T00:00:00+00:00

It’s only been two months since we published the last article on Minecraft updates, but here we are. Minecraft 1.20.3 is to be released in the near future with some changes affecting mod makers.

As usual, we ask players to be patient, and give mod developers time to update to this new version. Given the rather short interval between updates, some authors may choose to have a rest and skip some versions; we ask everyone kindly not to pester them.

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

Fabric is about to celebrate its 5th birthday on December 10th! As we approach this milestone, we’re thrilled to share that our team is actively working on introducing exciting new features and enhancements. The following sections outline some of these advancements.

Developers should use Loom 1.4 (at the time of writing) to develop mods for Minecraft 1.20.3. Players should install the latest stable version of Fabric Loader (currently 0.14.25), or the 0.15 beta if feeling adventurous (see below).

Loader 0.15

Fabric Loader 0.15 has been released recently, which features built-in support for LlamaLad7’s MixinExtras library. This version is currently in beta. Should you discover compatibility issues with mods that already bundle MixinExtras, please file a bug report.

MixinExtras is a companion library to Mixin, providing new annotations to write your mixins in more expressive and compatible ways. It also features an easier way of specifying local captures. Due to its usefulness, MixinExtras is currently being Jar-in-Jar’d by a large amount of mods, increasing modpack sizes. With Fabric Loader bundling it now, all mods can use the library without needing to worry about distribution.

Please note that Fabric Loader 0.15 went through a number of internal changes, notably the transition from TMP to Mapping-IO and improvements to the lazy mapping loading, which reduce memory consumption. These changes do not affect most users, but mods that depend on unsupported, internal code might break with this update.

Loom 1.4

Loom 1.4 includes enhancement for decompilers, support for deprecated modules in fabricApi.module (which allows dependencies on individual Fabric API modules), and many more bug fixes and performance improvements. Loom 1.4 requires Gradle 8.3 or later.

Loom now includes built-in support for the Vineflower decompiler. It’s a fork of Fernflower, but with drastically improved output quality compared to the original. CFR remains the default decompiler for the time being. To decompile with Vineflower, use genSourcesWithVineflower instead of genSources.

A new DSL has been introduced to make configuring data generation with best practices easier. This DSL automatically creates a run configuration and optional source set for data generation while also excluding the cache from the built JAR:

fabricApi {
    configureDataGeneration()
}

New Fabric API changes

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

Data Generation: add a method to register custom keys with priorities (ErrorCraft)
Loot API: add LootTableEvents.LOADED (LLytho)

In addition to those new features, this update also contains performance improvements for PacketType-based networking. It now skips the serialization entirely in singleplayer, and the packet is now serialized on the network thread, not the main thread. Thanks to deirn for making these improvements!

Breaking changes in 1.20.3

BlockSetTypeRegistry and WoodTypeRegistry of the Object Builder API, previously deprecated, were removed. Please use the builders provided in the same API.

The following APIs in the Transfer API module, all previously deprecated, were removed.

ContainerItemContext#withInitial
Storage#simulateInsert, simulateExtract, exactView

Minecraft changes

Minecraft 1.20.3 introduces some breaking changes to major developer-facing APIs.

Block codecs

Mojang now uses codecs to serialize blocks - specifically, instances of a particular type of block. You might need to implement the getCodec method in your Blocks.

However, the block codecs are currently unused. This means that you can return null or throw UnsupportedOperationException in getCodec method.

That being said, it is still recommended to familiarize yourself with using codecs, to future-proof your code and prevent potential porting pains in the future.

Text

Text also got a codec, and now is serialized using it (including when interacting with Gson). Over the network the text is now sent as an NBT.

Important change: Text#translatable now expects all arguments to be numbers, boolean, strings, or other Texts. To pass things like BlockPos or Identifier, which were previously implicitly converted to strings, use stringifiedTranslatable.
For those who have previously used Codecs.TEXT or STRINGIFIED_TEXT, it’s time to switch to TextCodecs.CODEC or TextCodecs.STRINGIFIED_CODEC.
Text.Serializer inner class was split into Serializer (to use as a Gson adapter) and Serialization (contains static methods). The methods were also renamed; toJson is now toJsonString to clarify return value.
Style.Serializer is gone; it is now Style.Codecs and holds the codec only.
In related news, PacketByteBuf#readUnlimitedText was added; this reads an infinite amount of text with no size limit. Most S2C packets now use this.

Ticks

The /tick command from the Carpet mod arrived in the vanilla game. This change affects both the server and the client. To support this functionality in your mod:

Use getTickManager().shouldTick() to check if things should tick in your START_WORLD_TICK/END_WORLD_TICK/START_SERVER_TICK/END_SERVER_TICK event.
TickManager can be obtained from MinecraftServer#getTickManager or World#getTickManager (works with ClientWorld as well).
Use shouldSkipTick for checking if an entity should be ticked (beware, it is the inverse of shouldTick).
Note: You do not need to call these checks inside Entity/BlockEntity tick methods or events. Only call inside server/world tick events.

It is also now possible for the game to run faster or slower than 50 MSPT intentionally (as opposed to through lag). Call TickManager#getMillisPerTick() to determine the intended MSPT.

Blocks

AbstractBlock#randomTick no longer calls scheduledTick.
BlockSetType received new fields specifying pressure plate activation conditions and button interactions with projectiles/Breezes.
ColoredFallingBlock was added, replacing GravelBlock and SandBlock.
PowderSnowCauldronBlock was removed; LeveledCauldronBlock handles the logic now.
TransparentBlock was split into TranslucentBlock, which renders in a translucent way (like slime and ice blocks), and TransparentBlock, which extends TranslucentBlock and is used by grates and glass blocks. AbstractGlassBlock and GlassBlock were removed.
FernBlock is renamed to ShortPlantBlock.
SaplingGenerator is now in block package, and individual generator classes were removed and replaced with fields.
AbstractBlock#onStateReplaced implementations for block entities were consolidated to ItemScatterer#onStateReplaced. Make sure to call super AFTER calling ItemScatterer.
LootableContainerBlockEntity logics were split into LootableInventory. checkLootInteraction was renamed to generateLoot. LootableContainerBlockEntity still implements LootableInventory, but this allows other block entities like decorated pots to share the logic.

Entities

Boats, minecarts, and other player-constructed vehicles should now extend VehicleEntity. This provides the wobble effect seen when hitting that entity.
Various non-living entities (including projectiles and TNT) received copyFrom override to copy the owner.
PersistentProjectileEntity and its subclasses now take the ItemStack in the constructor, representing the item stack form that players can pick up. getItemStack returns the stack as-is, while asItemStack returns a copy (potentially reflecting the changes like potion override).
SpawnReason got two methods: isAnySpawner (spawner & trial spawner) and isTrialSpawner. canSpawn methods should check isAnySpawner, and make the entity exempt from biome/height requirements imposed for natural spawn.

Client

PopupScreen was added. This screen, unlike other screens, renders on top of an existing screen. The popup can include a message, an image, and buttons (such as “Open Link”). To create an instance, use Builder.
CheckboxWidget is now built using a builder.
EntryListWidget no longer takes the bottom coordinate in the constructor. It also actually became a Widget.
ClickableWidget#render was made final to prevent overrides of that method from not calling super.render and preventing the tooltip from rendering. Subclasses must override renderWidget instead.

Misc

CommandManager#execute methods no longer return an integer return value. To get the return value, use ServerCommandSource#withReturnValueConsumer.
RecipeProvider methods received some changes. Some JSON builders and generateCookingRecipes now require passing the constructor of recipe class, like CampfireCookingRecipe::new. Other builders no longer require the serializer.
EntityType#HEROBRINE was removed. (Wait, was this ever added in the first place?)