Updates & Info for FTB mods for Minecraft 26.1+

A fair warning, this blog post is going to be very wordy and contain a bunch of technical information. The goal with this post is to inform any mod developers + modpack developers of our changes. We invite everyone to have a read of the post but just know what you're getting into :D

As Minecraft evolves and upgrades, our mods tend to follow the same trends, and we use these key updates to take a long look at our mods and see what we can improve for future versions.

With the introduction of Minecraft's new versioning scheme and all the under-the-hood changes coming in 26.1+. We thought this would be a great time to shake things up and introduce some breaking changes to our mods. 

Firstly! We have some great news: we're already in the process of porting our mods to 26.1+. We have FTB Library, FTB Ranks and FTB Essentials up and running. It's all looking stable enough that we've already pushed Beta builds out to CurseForge.

An overview (The tl;dr)

• FTB mods no longer rely on Architectury, but we are preserving cross-platform compatibility for the mods we've already released Fabric versions.
• Goodbye SNBT and hello JSON5! Going forwards, all of our configs + quests data will be in the format JSON5 instead of our internal, proprietary, and non-compliant flavour of Minecraft's stringified NBT data
• With the move away from Architectury, all of our external events are now fired in different ways. For some this is a weclome change but for others, it might be a bit of a pain point if you depend on our mods events. 

SNBT to JSON5

After a lot of internal discussion and planning, we've found that JSON5 fits out use case really well: it's easy enough for users to edit (for configs), and similar enough to our old SNBT format that it's a perfect middle ground.

The history

The topic of "user configs" is complex: there is no "right" way, everyone wants different things... This is exemplified really clearly with Fabric's lack of a config system, which is essentially a direct result of too many wanted & unwanted features working against each other.

For FTB mods, we historically opted for what we initial thought was a nice compromise. JSON is, although readable, too restrictive in what it allows users to do: you can't have trailing commas (a common issue for users when changing lists), there is no way to nicely add comments to the files, and an array of other minor annoyances. So with this in mind, we instinctively thought: "Well, users know what NBT is, and users work with SNBT due to it being used in commands", "what if we extended that to work for configs" and thus SNBT was born.

Sadly, this came with a bunch of negatives that we didn't consider. Most importantly, it's non-standard, IDE's (VSCode, WebStorm) don't support it, it lacks real documentation, it comes with the overhead of our own file specification, and a bunch of other more technical issues that we finally hit a wall with in 26.1+. 

The resolve

At this point, the solution was clear. We had already discussed internally the idea of moving over to JSON5 but were concerned about causing a large breaking change to all of our mods. Sadly, this is going to be a reality of the technical wall we've hit.

Events

Previously if you wanted to listen to one of our mod's events (say when a user is added to a team), you would have had to load our mod into your development environment, bring in our dependencies add a "soft" dependency on Architectury. With our move away from Architectury, this has brought on an added benefit: our mods can now post native NeoForge or Fabric events, as appropriate.

So, for our mods post 26.1, you will still need to include our mod as a "compileOnly" dependency, but there is no need to bring in anything else. This will give you access to our event classes that you can then listen for in the normal ways, either via Fabrics Event system, or NeoForges event system.

Architectury

Firstly, I want to say a massive thank you to the Architectury team! They have done an absolutely amazing job providing a platform that allows mod developers to create cross-platform mods. We'd also like to make it clear we have nothing against mods using Architectury and we would continue to recommend mod developers utilise this fantastic set of tooling and modding API's.

"So why did you stop using it?"!? 

That's a great question, the answer is actually rather simple. As Minecraft has evolved and the Mod Loaders around Minecraft have matured, we've found the two platforms more and more similar. This has made our own first-party "shim" a fairly easy decision.

Architectury is a great "general use" solution for most modders; but as our use case for our core suite of mods always been fairly limited, we simply didn't need many of the features provided by Architectury. For the most part we almost never actually call into features from Fabric or NeoForge, Our core suite of mods is fairly 'Utility' based and with that, although not short on complexity, does simplify how much we actually need from the mod loaders and in turn directly translates into how much we need from Architectury.

During the earlier days of true cross platform mod development, Architectury was an invaluable tool that we couldn't have done without, but now, as the loaders are becoming more similar in functionality, the tooling becoming more stable and unified, as well as a noticeable lowered activity on the Architectury project and less systems being unified,  and our continued limited use of features from the modloaders + Architectury. This feels like the natural progression of our mods.

Fabric

If you watch our mods closely, and if you've read this far down, you likely do, you'll have noticed that our latest mods, outside of 'suite' mods (Library, Teams, Chunks, Quests, Filter System, Ultimine, Essentials, XMod Compat, Promoter, Ranks, Materials, Backups 3, Pause Menu API) no longer have contained Fabric versions. 

We are committed to continuing to support our 'suite' mods on Fabric for the foreseeable future.

That being said, going forwards, our new mods will not be built for Fabric. There have already been a few of these released in the past few months 'FTB Team Bases' for 1.21.1, 'FTB Pack Companion', 'FTB Obsidian', etc. There is a meaningful cost to developing new mods for both platforms and from our research, our mods that sit outside our core suite, do not tend to be well utilised on Fabric. Given the lack of interest in our Fabric versions and the development costs associated with them, we don't think it makes much sense to build new mods out for Fabric.

If we notice this change in the future and more requests for our mods to be made for Fabric as well, we'll review this decision.