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

[TelepathicGrunt]

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.

[shartte]

That is fine with me as long as it's a conscious choice.

[Ezelsorix]

As a user myself I get the issue, but you're in essence saying with downloading anybodys mod you take ownership of their intellectual property, even if you only adjust in your opinion minor stuff. And how do you prevent redistribution of such packs?
I think you can call any big publisher/dev and they'll blow a gasket if you tell them you made some "minor" adjustments to their product to make it "compatible" XD .

Also imo this can be misused from both ends. If a moddev doesn't want to support version xyz, they are still in the right however, even if it is crap for users/pack creators.
You would take control out of their hands by force and in the end leave them with the shitstorm if anything goes wrong, while you have no control yourself over the potential proportions of the mess as a modloader. What responsibility do pack creators take in this if they mess up a million downloads mod and the original creator gets a full inbox with complaints?

What you say about forking is exactly what some moddevs complain about: Wanting a quick fix without any interest in putting in the effort to understand/support their changes.
If you could be sure this would only be used in a sensible fashion I'd be totally fine, but imo this will only tip the ballance towards insta gratification and the devs that are particular with their decisions will suffer. At the same time you proclaim in E1S1 that this feature can be used by people that have no idea what they are doing and consider it working if the game loads...

Maybe I imagine this bigger than it is, but as a user I'd rather not disgruntle devs of big mods in favor of fixing some small stuff that is dead anyway.

[TelepathicGrunt]

you take ownership of their intellectual property

So what do you think about datapacks and resourcepacks that can modify the mods even now? You are making changes against what the modder intended for their IP. Should we swing the other way and disable all resourcepacks and datapacks because modders should have complete control over their IP and tended behavior/looks?

IMO, no. Mojang pushes for configurability and modloaders pushes for compatibility. A dependency override option is both a configurability option and to be used for obtaining maximum compatibilities. IP really doesn't come into play here as only when you modify the actual jar, then IP comes into play which means your previous forking option is even worse if you care about IP due to jar modification.

A dependency override requires no jar modification. The logic would simply only exist in the modloader itself.

[Mari023]

I have a real life example where this was useful (on fabric):
old versions of my (addon) mod used to break a lot when the main mod updated, so I depended on a fixed version.
If a new version of the main mod gets released, which doesn't break the addon, pack makers could use dependency overrides to release a new pack version without having to wait on the addon dev uploading a version with a changed mods.toml

---

that said any dependency override should be clearly logged

[embeddedt]

With enough work, I suspect it's possible to achieve the functionality of a dependency override even without it (e.g. by attempting to modify the contents of other mods on disk at runtime), so I don't really know if avoiding it in FML is going to change what modders do.

I agree that using a dependency override should trigger a log message; this is also useful for players/modders providing support so they don't have to deal with extraneous crashes caused by players misusing the feature.

[TelepathicGrunt]

Note: the log message when a dependency override is on should be pretty detectable and findable for pack/modder support to be able to see

[marchermans]

Personal opinion: I would rather not see this in NeoForge or FML.
If I set it to incompatible, I do this with a reason. There is no way in hell a modpack maker or random user can always over see why I set an incompatibility flag.

Consider the following situation:
Modpack Maker overrides incompatible flag because it works for him. Player now installs the pack and it causes issues for him. Player complains to modder that he has issues (yes this happens). Now I have to deal with it, eventhough I followed all protocols correctly.