Overwrite dependency incompatibility

[wanne]

I like to play with a lot of mods and so I do a lot of fixes for other mods and try to do changes to get them interacting better with each other. But there is a limit: When mods recognized their incompatibility. While it is possible to unpack the mod and just modify the info.json this prevents you from playing online and since the most popular mod Authors (Erendel/Bob) are also those few who do not set their mods under free licenses it is also forbidden.

So please: Add the possibility to overwrite dependencies for other mods you depend on!

[Osmo]

Most (if not all) licenses mods use allow you to edit files locally. But also, you can ask the author to remove the incompatibility, and often they'll change it. An incompatibility can be replaced with a custom error message at data or settings stage that other mods could disable.

[protocol_1903]

Knowing that you're trying to use SE+bobs, you'll likely have to do a lot of local edits anyway. At which point there's no difference to editing info.json yourself.

[wanne]

But also, you can ask the author to remove the incompatibility

But there is a reason why they have these.
Originally I wanted also ask for proper boolean expressions in dependencies.
Here is a nice example:
For example aai-containers and 5dim-core won't even load together.
So I'm pretty sure Erendel would declare incompatibility if he would know about it. (I hope Erendel is not reading this.) Because he hates if things do not work perfect. (Even if there are workarounds). And rightfully so: In the end tat was the intention, why incompatibilities where introduced. You do not want do play through the 65550 options of your 16 mod to test which combinations are working.
But 5dim already fixed that problem with 5dim_compatibility everything works fine. Now the second option would be that Erendel adds 5dim_compatibility to its dependency. But this is even more ridiculous. Because that would mean that the little aai-containers mod that more or less everybody is using would indirectly depend on the complete overhaul mod 5dim-core which most users do not like...
So the right dependency would be more something like that:
!5dim-core OR ( 5dim_compatibility AND aai-industry )
But being able to declare something like that would not only require a change in the info.json format but also a sat solver for factorio to solve dependency problems. And one that not only one that finds a solution. But one that is searching for the one that seems to be the nearest to the users intentions. And I'm a 100% sure that tis is not going to happen at this stage of development.
It also requires a great deal of cooperation between mod developers.

So I was asking for the simple but less elegant solution: Let me change dependencies afterwards.

you'll likely have to do a lot of local edits anyway

Nope. Sadly SE does a lot in final-fixes. But so can you. And so you can overwrite everything.– except for the things in info.json...
I recently moved all the edits I did out of Krastorio2 witch I edited quite heavily into my own mod and played it on a bigger lan party. It worked fine and wasn't even much work. The factorio modding system is really good.

[wanne]

Bump...

[Rseding91]

This conceptually sounds simple but runs into a bunch of issues around multiplayer and installing required mods automatically. When the game is told to install a mod it iterates the dependencies of that mod in isolation and installs required ones according to the dependency. The same happens when updating a mod and it gains a new dependency. The game also tries to validate the active mod set on the manage-mods GUI - and if enabling or disabling a given mod *changed* other dependencies it further complicates any attempt to do that validation.

The entire dependency system is just not setup to handle them ever changing in this way.

[wanne]

if enabling or disabling a given mod

Dependency management doesn't work in this case anyway. If you disable a dependency the interface won't complain or mark your dependencies as red until you press commit. So "tries to" is a nice description. Citing the change in a feature that that isn't implemented seems really bogus to me.

For the validate on commit/install/load. This was the reason why I was not asking for full blown boolean expressions. Yes: This would be complicated.

But for the overwrite: I can see that you never read these zip/info.json-files again and long before the game complains about dependencies. So all you have to do is modify the structure that is already in memory when you read a compatibility dependency. Worst Case set the incompatibility-string to NULL if it is whatsoever not extendable data structure. (What I really doubt.)
Alternatively you add additional loop in front of the validation.
This change is 4 short lines of code at most. Even if your codebase is horrible and you have 20 different validation functions.

But we had that a few times. Useless to talk to you about those things there parts of you code that are holy and never to be touched.

[protocol_1903]

if enabling or disabling a given mod

Dependency management doesn't work in this case anyway. If you disable a dependency the interface won't complain or mark your dependencies as red until you press commit. So "tries to" is a nice description. Citing the change in a feature that that isn't implemented seems really bogus to me.

What change? It's just mentioning the rather annoying issues that need to be worked around for it to be implemented.

For the validate on commit/install/load. This was the reason why I was not asking for full blown boolean expressions. Yes: This would be complicated.

Beyond complicated. You'd need something akin to a simplex solver just to figure out what mods it needs to download, and any OR based conditionals needs extra overhead to figure out what individual branches could be used.

But for the overwrite: I can see that you never read these zip/info.json-files again and long before the game complains about dependencies. So all you have to do is modify the structure that is already in memory when you read a compatibility dependency. Worst Case set the incompatibility-string to NULL if it is whatsoever not extendable data structure. (What I really doubt.)
Alternatively you add additional loop in front of the validation.

Exactly where can you 'see that'?

And yes, you'd need a loop for the entire thing anyway. Regardless of when the dependency data is stored or read or interpreted.

This change is 4 short lines of code at most. Even if your codebase is horrible and you have 20 different validation functions.

I dont think anyone but them are qualified to say that. Baseless assumptions like that should not be used to attempt to prove your point.

[Rseding91]

if enabling or disabling a given mod

Dependency management doesn't work in this case anyway. If you disable a dependency the interface won't complain or mark your dependencies as red until you press commit. So "tries to" is a nice description. Citing the change in a feature that that isn't implemented seems really bogus to me.

This was fixed for 2.1 Nov 19, 2025 and has been pending 2.1s release since then.

[wanne]

Exactly where can you 'see that'?

inotifywait, your favourite malware scanner or just: Delete the file after the game says: Loading mod.... Won't make a difference.

I dont think anyone but them are qualified to say that. Baseless assumptions like that should not be used to attempt to prove your point.

This is the problem with proprietary content. Doing it after reading the zip-files is that easy that I am pretty sure that I could even patch that change into the binary without having the source code. But showing how easy it is to fix that issue is illegal.

This was fixed for 2.1 Nov 19, 2025 and has been pending 2.1s release since then.

Uff. OK. Sounds like I am a few months to late to get that change.

[Rseding91]

To reiterate - the main issue is:

When installing or updating a mod off the mod portal it automatically installs the dependencies for that mod using the dependency list the mod provides - recursively. Currently that's it - that's the entire set of logic.

But now how would overwrite dependencies interact with that? Half way through installing requirements it *may* find another mod that changes the dependencies to no longer require installing the mod that changes the dependencies.

The same issue may happen when enabling required dependencies when enabling a mod.

[Stargateur]

I think incompatible mod list is a bad idea overall, it's nice to indicate user that a mod will not work with another mod but it's flawed in several way:

- A mod author can prevent you from using a mod because he want. I saw some case of this and honestly, that annoying.
- Most incompatibility is fixable. Sure I would be the author of a big overall mod I would dismiss most request to be compatible, but I would be happy if someone want to do that, thus I would clearly state that I don't care if one of my change break his compatibility mod.
- The UI is sometime unclear, you select mod but you don't understand why game didn't load all your mod, cause you missed a red line
- The game decide arbitrary to load one mod and not the other (guess it's load order)
- less and less mod are incompatible, except big overall mods, every small mod try to be as flexible as possible.

I suggest incompatible list become soft restriction, just indicate user two mods may be incompatible in UI like currently, then, either by having an option "ignore incompatible mods list" in the game or by changing the current behavior to soft restriction. That should be way more simple and fast to implement than overwrite dependency incompatibility and let more control to user.