Porting a Fabric mod to Minecraft 26.3

In September 2026 I ported Araz, my Fabric horror mod, from Minecraft 26.1.2 to 26.3 in one afternoon. The first build gave me 56 errors. After fixing a few, it became clear that most were repeats of the same changes. None of them required a gameplay redesign.

This is basically the list I wish I had before starting the port. It covers the renamed APIs, moved classes and the build-tool versions required by the new Loom. The gameplay did not change; Araz 1.0.0-beta.2 plays the same on 26.3 and 26.1.2.

Everything below came from that actual port. I checked the changes against the working source instead of relying on a changelog. If your mod uses a different part of the API, check the examples against your own build before copying them.

What changed between Minecraft 26.1.2 and 26.3 for Fabric mods?

Most of the problems were in four areas: entity type constants, sign text, coloured blocks and loot tables. Some of those changes arrived in 26.2, which I skipped, so moving straight from 26.1.2 to 26.3 meant dealing with two versions of changes at once.

Two changes caused more confusion than the others. Removing hurtMarked is fine for mobs because the entity tracker already sends velocity, but players need the packet sent manually or their movement does not update. The colour collection is nicer once you get past the rename: choosing a carpet can use Blocks.CARPET.white() or Blocks.CARPET.lightGray() instead of a big switch over block constants.

Which Gradle and Loom versions does Minecraft 26.3 need?

Minecraft 26.3 uses Fabric Loom 1.18-SNAPSHOT, which needs Gradle 9.7 or newer. I spent more time on this than on some of the API renames. The error looks like a wrapper problem at first, but it is actually about the plugin variants.

The 1.21.10 backport is a different build entirely. It uses the net.fabricmc.fabric-loom-remap plugin with loom.officialMojangMappings(), every mod dependency declared as modImplementation, and Gradle run on JDK 21. If you keep several branches alive, keep the build files separate rather than trying to make one script cover all of them.

How I ported the mod in an afternoon

1. Copy the project, then bump the build

   I copied the 26.1.2 folder to a new one and left the old folder untouched as a working fallback. Then I set minecraft_version, loader_version, loom_version and fabric_api_version in gradle.properties and pointed the Gradle wrapper at 9.7.1.

2. Compile once and read the whole error list

   Do not fix the first error. Run the build, let it fail, and read all 56 lines. Almost every error repeats, so the list tells you how many distinct patterns you are really dealing with before you touch anything.

3. Fix by category, not by file

   I handled one pattern at a time across the whole source tree: every EntityType. constant, then every blocksMotion() call, then sign text, then carpets. One find and replace per pattern is faster and far less error prone than walking the file list.

4. Check what the compiler cannot see

   A change the compiler accepts can still be wrong at runtime. I checked loot table building, the mixin targets and the GeckoLib asset paths by hand, because a broken resource path stays quiet until the game actually loads it.

5. Run the client, then diff the data

   I launched the dev client, walked to a rebuilt abandoned camp to confirm sign text still renders on all four lines, and compared the generated loot against the 26.1.2 build. That last step is the only thing that catches a wrong Holder in the loot number providers.

What did not change in 26.3

There are many more things that did not change than things that did. That is a big reason the port took an afternoon instead of a weekend. If your mod mostly uses these APIs, there may not be much extra work.

• ValueInput and ValueOutput for reading and writing NBT
• Custom network payloads and StreamCodec
• SavedDataType with an Identifier, so persistent world data kept working untouched
• The entity render state architecture, GuiGraphicsExtractor and HudElementRegistry
• CreativeModeTabEvents for adding items to creative tabs
• Mixins targeting Java 25

How do you check a port did not quietly break something?

A clean compile is not enough. Resources and runtime behaviour can still be broken. There are three things in Araz that can get past the compiler and fail in game, so I check them manually after every port.

• Signs. SignText now wants two lists of four lines. A wrong list length shows up as blank lines on the record signs the creature plants near your bed, not as a compile error.
• Loot. The number providers moved package and take a Holder, so I compare what actually drops against the 26.1.2 build instead of trusting that it compiled.
• Client-only code. Item activation moved from the game renderer onto the player, and with split source sets a client mixin has to be declared as {"config": ..., "environment": "client"} in fabric.mod.json or a dev server crashes on startup.

Which Minecraft versions does Araz support?

As of September 2026, Araz 1.0.0-beta.2 is available for Minecraft 26.3, 26.1.2, 1.21.10 and 1.20.1. They are all Fabric builds; there is no Forge or NeoForge version. Fabric API and GeckoLib are required, while Simple Voice Chat, Mod Menu and Cloth Config are optional. The mod page is at spicesfire.com/araz.

Keeping all four branches around is manageable because the gameplay code is shared. The one user-facing fix listed for 26.3 was a missing spawn egg texture; the other changes were internal. The builds are on Modrinth and CurseForge, and I also answer porting questions on Discord.

What this port does not tell you

These notes come from one Araz port in September 2026. The mod uses a custom entity, block entities, items, loot, mixins and a GeckoLib renderer, so it touches quite a few parts of the API. It does not touch world generation: the abandoned camp and portal ruin are built when the player gets close, not while chunks are generated. If your mod generates terrain, biomes or structures, some of this will not apply.