FancyModLoader icon indicating copy to clipboard operation
FancyModLoader copied to clipboard

Add dependency override for player/pack maker to bypass limits set in mod's mods.toml file

Open TelepathicGrunt opened this issue 6 months ago • 5 comments

With the upcoming incompatible and conflicts clauses being added to mods.toml, it reminded me of how Forge ecosystem has kinda a problem with the mods.toml file limits. Specifically around what user/pack makers can control.

I am in the camp that the user/pack maker should have final say on what MC version and what mods a mod can run with. So there should be a way to have users/pack makers be able to override version ranges, incompatible, and conflicts for any given mod in their pack. Fabric has dependency overrides for a long while and I have seen users/pack makers make use of it to keep their packs running and updated properly. There has been no influx of reports to modders when their mods are forced to load so any concerns about issue report influx is not really a thing. https://fabricmc.net/wiki/tutorial:dependency_overrides

Consider this, a modder does not maintain their mods forever and may not exist in modding scene forever. Uers and pack makers will continue to make packs and play on any Minecraft version. With the current system, if a mod does not load in a pack due to a mods.toml restriction, users/pack makers are stuck and cannot do anything forever.


Example 1:

Mod A and Mod B together will crash Mod A. Mod A as a result sets Mod B as incompatible to stop loading with it. Mod A's dev eventually leaves the modding scene. Mob B releases an update that fixes the crash. However, users and pack makers still cannot use the mods together because of the incompatible clause being unable to be overridden. This can happen with the version range too as mods can set "" as the range to not run with any version of another mod.

Solution 1: Fork the mod, change the mods.toml file, reupload it to CurseForge/Modrinth, and then add it to modpack to distribute. Problem of that? Ridiculously excessive, taking points and downloads away from original dev, requires mod to be open source and buildable, pack makers to know how to build project, and for CurseForge/Modrinth to allow a reuploaded clone to exist with only a mods.toml change. Awful in every sense of the word.

Solution 2: Allow pack makers to specify a dependency override for the mod in their modpack. Clean, simple, and works.


Example 2:

Mod A's dev is a jerk and decides to mark Mod B as incompatible or version range lock out Mod B in latest Minecraft version. Pack makers now have to either remove Mob B to update Mod A to fix crashes or whatever or remove Mod A. this is a blatant misuse of the mods.toml dependencies and users/pack makers have no way of bypassing it cleanly without yeeting mods or forking and reuploading. Dependency Overrides allow users/pack makers to say "no" and bypass the mods.toml misuse to keep the pack updated properly and running.

TelepathicGrunt avatar Dec 14 '23 13:12 TelepathicGrunt