I’ve been developing some Minecraft mods for the Fabric modloader lately (link). They are all small mods, but I have discovered some challenges to working in this new environment.
- Perhaps the most consequential: Fabric has no real concept of load order. This is strange to me for a couple reasons:
- Every other game I’ve played with proper mod support implements load order.
- I’m used to Forge which has always had load order, as far as I know.
- There are, obviously, going to be race conditions that have to be worked around when developing mods. For instance, I wanted to create a local variable that was a dummy ItemStack of another mod’s item, but half the time I ran the game, the mod’s items didn’t exist yet, so when it got to my code, it crashed. I solved this by only creating the variable where I needed it (which would only be able to run once the player is in a world). Implementing load order can’t make all race conditions vanish, but it can simplify the mod development process.
- Forge has an NBT crafting ingredient type (among some other useful ingredient types). There’s a Fabric mod that implements this, but as of writing it’s outdated. I feel like something like this should go into the Fabric API.
- This isn’t an issue with Fabric, but the MinecraftDev IntelliJ plugin has acted in ways I didn’t expect – regarding Fabric’s mixins, and regarding not always matching my mappings (I use Mojang mappings + Parchment since I’m used to Forge). The plugin is more useful than annoying, but it has to be learned, just like so many different aspects of Minecraft modding.
Fabric isn’t bad – in fact, I quite like it – it’s just different from what I’m used to. I will probably continue to use both Fabric and NeoForge, and possibly both using multi-loader technology such as Architectury, both as a player and as a modder. It just depends on what I want to make as a developer, modpack maker, and Minecraft player.