mdcdi1315's Base Mods Library (BML)

IMPORTANT: For Fabric, you will also need the Fabric API installed!!.

This is the project that provides my Base Mods Library mod that my multi-platform mods from now on will heavily use.

It is inspired by other great mods providing mod-loader agnostic support (Such as Balm or Architectury API, also great libraries too), but containing useful utilities and being much more complete than those mods (providing support for custom registries, data pack registries and others as well!!).

Of course, by just installing this without any mod that depends on this makes this mod useless.

Supported Platforms

The library supports Fabric, Forge and NeoForge for 1.21.1+ (Which all the depending mods should all work the same).

Note that 1.20.1 will be supported and up to the end of 2025. After that, no more updates will be released for the library and 1.21.1 will become the new base version.

Technical details and background

This library, unlike other abstraction layer libraries, aims to get in the deepest of Minecraft to support as most mod-loader features as possible, while not breaking other mods in the process. Additionally, there is the need to indicate to the mod-loader what the mod itself does to load.

One additional point that makes Minecraft modding difficult in mod-loader agnostic cases is that the developer cannot modify the access to many Minecraft classes, as it is like modding in vanilla Minecraft. While the Mixin project covers some cases, it does not cover them all.

To solve these problems, the library provides thin wrappers (called Contracts) over mod-loader and Minecraft classes to achieve platform-agnosticness. These contracts are assigned a specific mod-loader implemented object during mod loading. Then, the contract is provided to the mod itself so that the mod can do whatever it needs to do with it.

Furthermore, the library treats mods as real entities in a Minecraft instance which do have a specified lifetime, that is, they do have features that does make development with them more natural. Additionally, helpers are defined around them for common tasks (i.e. retrieveing a known mod instance). As such, the library provides all those components to be even itself a very good mod-loader solution standing on its own (although it does not do that for pretty much obvious reasons).

Another problem that modern mods are being plagued with is configuration files. Over 5 libraries are currently existing only for this purpose (Let alone Forge and NeoForge that are also defining their own ones). As such, this library provides its own, very complete configuration system with a highly expected flexibility on what someone can do with it. On top of these, the library has built-in support for the well-known screen config library, the Cloth Config API. To even take it further, mod developers can also (why not?) register their own custom-made configuration screen. Finally, for the Fabric mod loader only, the library does also have built-in support for the ModMenu mod, so that mod developers can hook their configuration screens without taking any additional actions to their development environment.

Due to its nature, there is always the need in Minecraft to load or store data in a form or another, either if that is JSON or NBT or any other format that can be supported through the Mojang's serialization library. However, it utilizes adequate CPU and memory resources and it is not so easy to use, especially for mod developers that are now diving into the Minecraft's large complexity. For this reason, the library provides common and easy-to-use Codec implementations for many applications, with a look on performance.

While all these features are good, there is something that is missed out of the equation: The Java runtime itself. Java is being plagued by a LOT of issues, and mods do always write on-the-fly code which is itself very fragile and unsafe. While starting my modding experience, I noticed that many times mods do very fragile operations. Even Minecraft itself has this issue. As being a .NET developer as well, I quickly realized the importance of type safety. As such, the library provides a small subset of .NET API's which do embrace type safety and make the code more robust and less error-prone. Most of the library objects do embrace type safety and define exceptions for known code states through these API's.

All of these features, however, are not enough to make a library perfect. On the top of everything, the library tries to keep ABI compatibility with previous versions. If it is not possible, the component is appropriately deprecated or modified. For example one of the mods I do currently develop had been built against 1.0.11 of the library and as of 1.0.15, it still works the same!

Due to its broad support, however, the library is not error-free and bugs may be found while using it. Please report bugs as you find them!