Mod support: info.json option for conflicting mods

[vzybilly]

Even more so when there's talk of getting Factorio to be able to download and install mods in itself, allowing for people to just browse a list and say, "this one, this one, and this one", just like a package manager...

Well, that is a very, very far target. 1 year or so, I guess here of course, but well.

This doesn't have to be so far off. Website with mods, run by factorio or gives factorio an API till they get there own/eat the other site. once that is done, refactor abit of loading so the process goes more like: Factorio starts > Factorio checks for updates, show user update > checks mod infos to make sure all are valid > check mod site with mods, show user updates > load mods.

That gives factorio abit better self updating and also allows people to update mods without even looking online.
Inside factorio at the mod screen, it could be replaced with something more like synaptic (a linux package manager, still running with "mods==packages" idea)

img of synaptic

Green boxes = installed, white isn't. just the way they have their system UIs set up.

There WILL be more in the future, isn't now the time to think about better ways?

Well, yes, of course now is the right time. That's why we are discussing it.
Everything is currently quite hypothetical.

What we can take out till here is: The idea with more functions to see in which context the own mod is running is very useful. I'll point the devs to this thread. We will see, what comes out from here.

My techy talk about how debian handles package dependencies

My main sources if you want to read the full indepth pages Source A, Source B

Quick Dirty list (with my ideas of how to tell them apart in the config.):

• depends (already used: "someMod")
• recommends (already used: "?someMod")
• suggests (already used: "?someMod")
• enhances (already used: "?someMod")
• conflicts (this thread. "!someMod")
• replaces ("-someMod")
• breaks (what most uses of conflicts should be. "!someMod")
• provides (pretty nifty one, can be very helpful in certain mods. "+someMod")

Source A takes you to a section that tells about each of those

• Mod A depends on Mod B if B absolutely must be installed in order to run A. In some cases, A depends not only on B, but on a version of B. In this case, the version dependency is usually a lower limit, in the sense that A depends on any version of B more recent than some specified version.
• Mod A recommends Mod B, if the Mod maintainer judges that most users would not want A without also having the functionality provided by B.
• Mod A suggests Mod B if B contains files that are related to (and usually enhance) the functionality of A.
• Mod A conflicts with Mod B when A will not operate if B is installed on the system. Most often, conflicts are cases where A contains files which are an improvement over those in B. "Conflicts" are often combined with "replaces".
• Mod A replaces Mod B when files installed by B are removed and (in some cases) over-written by files in A.
• Mod A breaks Mod B when both Mod cannot be simultaneously configured in a system. The Mod management system will refuse to install one if the other one is already installed and configured in the system.
• Mod A provides Mod B (Source A had a bad example here, using my own words.) If Mod C depends on Mod B, Mod A can be used to fulfill the dependency of Mod C. If Mod A is here, Mod B is also here.

Conflicts and Breaks are what this whole thread has been about. when the code of two mods don't like each other.
One of the few cases that Conflicts is used is when two mod devs have a entity with the same name but acts differently and neither of them are willing to change the name.
Breaks should be a more common goto when there is an issue between mods. When both mods are present, things most likely will not work.

The one I want most: Provides. I have a good example of this.
my mod, ColouredTiles depends on ColouredTilesColouringFunctions.
I have other mods ColouredTiles1BitColouringFunction ... ColouredTiles8BitColouringFunction, all provide ColouredTilesColouringFunctions and all conflict ColouredTilesColouringFunctions.

ColouredTiles has all the logic and everything for the mod to work, but it doesn't know how to turn a value X into colour Y.
All the bitColouringFunction mods provide that function. but there can only be one. thus, they conflict with the others.
It's the user's choice of which they want, but there can only be one since value 7 for 1Bit is WHITE while for 8 bit it is almost BLACK, 3 Bit makes it BLUE. All tell ColouredTiles to gen different recipes for coloured tiles. All have different effects at control.lua.



Side note: I am also almost done with this ColouredTiles Mod, I hope it will be nifty.

1AM sleepy posting again, yay!