Fabric for Minecraft 26.1
A new version of Minecraft is coming soon with changes that will affect all mod makers. As always, we ask all players to be patient, and give mod developers time to update to this new version. We kindly ask everyone not to pester them. We also recommend all players make backups of their worlds, especially due to the major changes to world storage in this version.
Preparing Fabric to support and full embrace the changes in 26.1 has been a major focus for the last several months by many contributors. The changes in the tooling and API are the largest we have ever made for a single release. There are still some rough edges and missing features however the changes put us in a great position to continue to update and improve Fabric for the foreseeable future. We are excited to see what the community will create with the new possibilities that 26.1 opens up.
26.1 is the first version of Minecraft to not be obfuscated. Because of that, no mods from 1.21.11 or before will work without, at a minimum, recompilation. If you have not yet transitioned your mods to Mojang’s mappings, now is the time to do so, as Yarn is no longer officially supported by Fabric.
26.1 is also expected to be the last Minecraft release to solely support OpenGL, with 26.2 snapshots expected to allow for the backend to be changed between OpenGL and Vulkan, with OpenGL planned to be removed once the Vulkan backend is stable. Developers making use of raw OpenGL calls rather than going through the Blaze3D API will need to migrate for their mods to work.
Here is a list of several major modder-facing changes in this version. Note that all code references are using Mojang’s official names.
Fabric changes
Developers should use Loom 1.15 and Gradle 9.4.0 (at the time of writing) to develop mods for Minecraft 26.1. Players should install the latest stable version of Fabric Loader (currently 0.18.4).
Minecraft 26.1 requires Java 25 minimum for the Gradle JVM. You can configure this in your IDE’s Gradle Settings. Additionally, if you are using IntelliJ IDEA, version 2025.3 or above is required for mixins to work correctly.
Note: The Fabric Model Loading API and Renderer/Indigo modules may not be available for the inital release of 26.1, but we hope to have them updated as soon as they are ready. If you are interested in helping with the development of these modules, please reach out to us on our Discord server.
Deprecations and removals
Fabric API no longer provides the fabric mod ID, which was deprecated more than three years ago. If your mod’s fabric.mod.json depends on fabric and not fabric-api, you will need to fix that.
The following previously deprecated modules have been removed.
fabric-convention-tags-v1fabric-loot-api-v2
In addition, deprecated conventional tags labeled for removal in 1.22 have finally been removed (#5056), and the deprecated HudRenderCallback event has been removed in favour of HudElementRegistry. As always, other APIs have been changed in response to 26.1 refactors, see below for more information.
Unobfuscated Loom
As mappings are not provided for 26.1, developers should switch from the old net.fabricmc.fabric-loom-remap or fabric-loom plugins to the new net.fabric.fabric-loom plugin, which does not remap Minecraft or mods. Any use of modImplementation, modCompileOnly, or similar should be switched out for the standard implementation or compileOnly, and any use of remapJar should be switched out for jar.
For further details, see the buildscript changes on the Fabric Docs and the new Fabric example mod.
Fabric API renames
Previously, Fabric API was built with Yarn mappings in mind, but with the move to official mappings, API names have been updated to match the official names where applicable. These changes are not backwards compatible, so you will need to update your mod to use the new names. As an example, ItemGroupEvents became CreativeModeTabEvents.
For a full list of changes, as well as an IntelliJ IDEA migration map to automatically make these changes, please see the Fabric Docs.
New Fabric API changes
Dimension events
Rather than use the biome modification API to iterate through and modifying every individual biome within a dimension, Fabric now provides an event that directly interacts with a dimension’s attributes. Datapack and modpack creators still retain granular control, as dimension-level modifications are designed with lower priority than biome-specific definitions during attribute evaluation in vanilla.
DimensionEvents.MODIFY_ATTRIBUTES.register((dimension, attributes, registries) -> {
if (dimension.is(BuiltinDimensionTypes.OVERWORLD)) {
attributes.set(EnvironmentAttributes.CLOUD_COLOR, PURPLE);
}
});
Block/Item events
Fabric now provides 4 new events which allow for more precise modification of item/block use interactions.
Compared to the existing UseBlockCallback and UseItemCallback events, these new events run only in specific contexts and keep the rest of vanilla logic around the use method calls.
BlockEvents#USE_ITEM_ON- called beforeBlock#useItemOn, replacing it for non-null returns.BlockEvents#USE_WITHOUT_ITEM- called beforeBlock#useWithoutItem, replacing it for non-null returns.ItemEvents#USE_ON- called beforeItem#useOn, replacing it for non-null returns.ItemEvents#USE- called beforeItem#use, replacing it for non-null returns.
Block Color Registry
As ColorProviderRegistry has solely been used for blocks since 1.21.4, its implementation has been simplified in 26.1 to the new BlockColorRegistry.
Old code:
ColorProviderRegistry.BLOCK.register((state, level, pos, tintIndex) -> [...], ModBlocks.EXAMPLE_BLOCK)
New code:
BlockColorRegistry.register(List.of(new BlockTintSource() {
[...]
}), ModBlocks.EXAMPLE_BLOCK)
Minecraft changes
26.1 is a very large update with many changes, especially to the rendering engine. We have only listed a few of the major non-rendering changes here. For a more comprehensive list of changes we look forward to Neoforged’s upcoming porting “primer”.
ItemStackTemplate
An ItemStack can no longer be created until a world is loaded. As a replacement, the game provides a new class, ItemStackTemplate, an immutable class representing an non-empty Item, a count, and a DataComponentPatch. Many methods that used to return an ItemStack now return an ItemStackTemplate. Note that until the world is launched, components on an ItemStackTemplate are not bound and the game will throw if they are accessed too early.
Recipe serializers
Rather than having every recipe have an inner class than implements RecipeSerializer, recipe serializers have been simplified to just be a MapCodec and StreamCodec.
Registry.register(BuiltInRegistries.RECIPE_SERIALIZE, "mod_recipe", new RecipeSerializer<>(ModRecipe.CODEC, ModRecipe.STREAM_CODEC));
Automatically set render layers
ChunkSectionLayer is RenderType/RenderLayer’s replacement for terrain. Whereas before you had to manually register blocks to chunk layers like this…
// Before BlockRenderLayer (Yarn)
BlockRenderLayerMap.INSTANCE.putBlock(MyModBlocks.TATER_GLASS_BLOCK, RenderLayer.TRANSLUCENT);
// 1.21.6 (Yarn)
BlockRenderLayerMap.putBlock(MyModBlocks.TATER_GLASS_BLOCK, BlockRenderLayer.TRANSLUCENT);
…Minecraft now automatically sets the ChunkSectionLayer for each quad based on the assigned sprite’s properties which are as follows:
- Translucency: the sprite has translucent pixels
- Cutout: the sprite has only solid and transparent pixels
- Solid: the sprite has no transparency or translucency
This can be overridden with a block model or with MutableQuadView and Model Loading API.
Villager trading
Villager trading, including Wandering Traders, has been made data-driven in 26.1, removing the need for Fabric’s TradeOfferHelper API. A villager trade is stored in the new data/<namespace>/villager_trade directory, a set of trades is defined in the data/<namespace>/trade_set folder, which uses tags in the data/minecraft/tags/villager_trade/<profession> folders.
In general, to add your mod’s trade to an existing profession:
- Create a new villager trade in
data/<namespace>/villager_trade - Add it to the appropriate tag in
data/minecraft/tags/villager_trade/<profession>.
Fluid rendering
The new FluidModel replaces a lot of functionality previously provided by Fabric API’s FluidRenderHandler. You can register an unbaked fluid model by creating a FluidModel.Unbakedand registering it with FluidRenderingRegistry.register. In most cases there is no longer a need to create a FluidRenderHandler for your mod’s fluids.
mcsrc.dev
Over the last few months we have been developing mcsrc.dev, a new online tool to view the decompiled source code of Minecraft. It works by downloading the Minecraft jar directly from Mojang’s servers, decompiling it with Vineflower that has been compiled to WASM. mcsrc.dev also provides tools to aid with creating mixins and AccessWideners/ClassTweakers. We have plans to use this as the base for a javadoc editor that will allow users to provide documentation for Minecraft, this is still in the early stages of development.
Fabric