Mod support: info.json option for conflicting mods

[SirRichie]

Hi,

I think it would be great if mod developers could not only list dependencies, but also conflicts in the info.json.
Reasons for conflicts could be items named the same way, buggy versions of mods which cause the mod to break or incompatible behavior (control.lua).

If that option already exists, even better, but I could not find any reference.

[ssilk]

For the first: Such name conflicts don't exist in Factorio.
For the second: Why should another developer disallow to use any mod? You mix here in some responsibility, which is not given nor useful.

[SHiRKiT]

For the first: Such name conflicts don't exist in Factorio.
For the second: Why should another developer disallow to use any mod? You mix here in some responsibility, which is not given nor useful.

Totally agree that it should not be granted to the mod to block the gameplay experience. Let the user decide this.

[bobingabout]

Items with the same name? If anything, multiple mods using an item with the same name brings compatabillity closer together. If multiple mods implemented similar items with different names, this only means that you're forced to follow a specific mod's methods to get an end result. having multiple ways to create "Titanium Plate" is a good thing. Having 3 different types of titanium plate, that can only be used in the mod that makes it is a bad thing.

now, recipes, it would be more beneficial if a recipe was unique, or an entity was unique, but I believe items should be standardised.

[SirRichie]

My use case for incompatible mods may be a corner case, but I still want to share:
Say you have a mod like RSO. Now the developer of a new mod also wants to modify resource spawning behavior. The mod developer just knows that the behavior of RSO will compromise the way his mod works.
Another example can be say... the fat controller and a new wagon type that will cause the fat controller to crash.

Admittedly, the developer may as well mention this problem in the mod's description here in the forum. However, since mods are supposed to be supported a bit more from within the game, I was thinking such a flag could be helpful. Even if it only triggers a warning that unexpected results can occur. Very much along the thought "if the developer knows it, why not let the user know it as well?"

[ssilk]

My use case for incompatible mods may be a corner case, but I still want to share:
Say you have a mod like RSO. Now the developer of a new mod also wants to modify resource spawning behavior. The mod developer just knows that the behavior of RSO will compromise the way his mod works.
Another example can be say... the fat controller and a new wagon type that will cause the fat controller to crash.

Simply: Fix it or make a bug-ticket for the devs. If a mod is incompatible to another, then someone has not done his job correctly.
It is the same as (one more of my fatal comparisons) "If you use Linux you cannot connect with your Mac in the same network". Nobody would accept that as a solution to just disallow Mac in a Linux-based network (even if some purists would ). It is just a bug and it needs to be fixed ASAP.

Admittedly, the developer may as well mention this problem in the mod's description here in the forum.

Exactly.

However, since mods are supposed to be supported a bit more from within the game, I was thinking such a flag could be helpful.

My experience says: This will be never used and if then only for very stupid things. Maybe we have one good case. But for one good there are 10 other cases, that are then not so good.

Even if it only triggers a warning that unexpected results can occur. Very much along the thought "if the developer knows it, why not let the user know it as well?"

A modder is able to see, what other mods are installed (well, not nice ways yet). And that is the right way to check that internally and then you can warn the user.

But if a mod is able to see that, it can check that, then it quite logically can also create an exceptional code for that case.
It's just so, that all programmer I know are lazy and don't like to do such work.

[SirRichie]

Simply: Fix it or make a bug-ticket for the devs. If a mod is incompatible to another, then someone has not done his job correctly.
It is the same as (one more of my fatal comparisons) "If you use Linux you cannot connect with your Mac in the same network". Nobody would accept that as a solution to just disallow Mac in a Linux-based network (even if some purists would ). It is just a bug and it needs to be fixed ASAP.

I very much disagree. In systems where you have rapid development on a large number of modules, you will create incompatibilities. My intention never was to promote a "deal with it" behavior, but rather a way of making incompatibilities as explicit as possible. Yes, fixing things in the long run is the preferrable option. To stay with your example: say in your fictiuous situation you simply could not make it work. Then it is better to tell everyone it is not possible, than to let users find out themselves.

Admittedly, the developer may as well mention this problem in the mod's description here in the forum.

Exactly.

However, since mods are supposed to be supported a bit more from within the game, I was thinking such a flag could be helpful.

My experience says: This will be never used and if then only for very stupid things. Maybe we have one good case. But for one good there are 10 other cases, that are then not so good.

I respect you very much ssilk for what you do to the Factorio community. But I would challenge you to report from your experience. Name your 10 other cases, I named 2 good cases. What experience do you have that allows for making the judgement about how this will be used in the future?
Do not get me wrong. I am not all set on this idea, it is open for discussion and I have no problem to be convinced that it is not a good idea. But when someone arguments with experience, they should be able to prove it.

Even if it only triggers a warning that unexpected results can occur. Very much along the thought "if the developer knows it, why not let the user know it as well?"

A modder is able to see, what other mods are installed (well, not nice ways yet). And that is the right way to check that internally and then you can warn the user.

As you said, it is not a nice way. Mostly a workaround. Clearly there is a need for support.

But if a mod is able to see that, it can check that, then it quite logically can also create an exceptional code for that case.
It's just so, that all programmer I know are lazy and don't like to do such work.

I recommend being very cautious with that. This may very well lead to exception-wars, depending on how aggressive a certain exception-handling routine is.

Oh and I am a computer scientist, I am not lazy. Thank you.

[ssilk]

My experience says: This will be never used and if then only for very stupid things. Maybe we have one good case. But for one good there are 10 other cases, that are then not so good.

I respect you very much ssilk for what you do to the Factorio community. But I would challenge you to report from your experience. Name your 10 other cases, I named 2 good cases. What experience do you have that allows for making the judgement about how this will be used in the future?
Do not get me wrong. I am not all set on this idea, it is open for discussion and I have no problem to be convinced that it is not a good idea. But when someone arguments with experience, they should be able to prove it.

Good point.
My reasons here are also non-technical. We are in a community an things can and will happen here and one I've seen with such mechanisms is, that someone who dislikes someone else just puts such a rule into the code. Just to take the most stupid case. The more stupid case is, that we have one modder, that has a different opinion about something, which is controversial to the others and the other modders decide to boycott his mod. And there are many more possible constellations, which end in using a mechanism for social censorship, which was thought in the beginning to be only for very special technical usages. An humans a very clever in finding usages for mechanisms, that weren't thought for that. That's one of the things, where most humans are really, really good, so that it makes no sense to think about it: It will be misused, there is no second to doubt it.

And even for technical reasons the things are more complex.
Assumed there is a rule in the code, that says "A does not work with B". But the rule does not tell why! It's just a rule, if you put it into the info.json.
Maybe there is a comment somewhere in the thread. Maybe the comment is anywhere else in the code. Maybe a comment on the favored MOD-DB website, which might come at some time. Who knows? This game will rise, the communities will rise and split, the information behind something dissolves into space, because it's not written into code, it's written into the community; the modder thinks everyone will read it. Which is of course not the case, or who reads this forum AND reddit forum regularly? That is just not possible, cause it's just too much.

And even a comment in the code (here above the line in the info.json, that tells us, why it is forbidden) is not the correct way to do this: Comments are lying. They are just text. Things change. Live happens.
What really matters here is the code, which never lies. (I mean for example http://blog.ircmaxell.com/2012/06/to-co ... le-of.html ).

Even if it only triggers a warning that unexpected results can occur. Very much along the thought "if the developer knows it, why not let the user know it as well?"

A modder is able to see, what other mods are installed (well, not nice ways yet). And that is the right way to check that internally and then you can warn the user.

As you said, it is not a nice way. Mostly a workaround.

Because that is a workaround and a workaround behaves like a workaround. There is nothing "right" about it. It's just a technical debt ( https://en.wikipedia.org/wiki/Technical_debt ).

Clearly there is a need for support.

In a way that it is more clear, to find out for a mod, what other mods are installed? Of course. Because this mechanism is often used to turn on/off configuration options. Which makes much sense. As side effect is of course to be able to check that things easier/more clear. A programmer can easier tell the rules, under which something cannot work, if there is a such an interface.

But if a mod is able to see that, it can check that, then it quite logically can also create an exceptional code for that case.
It's just so, that all programmer I know are lazy and don't like to do such work.

I recommend being very cautious with that. This may very well lead to exception-wars, depending on how aggressive a certain exception-handling routine is.

See above: There are non-technical reasons, social stuff, which leads to misuse of mechanisms, that where formerly thought for completely different things.
In the same way you can argue: Let's put in a button for each mod into Factorio. If too many people press this button, then the mod is automatically turned off.
It's the same as if too many people press the abuse button for this thread, then it will be automatically deleted. (Which is of course not the case. Because it doesn't make sense just because of that.)

My option is: The software is not made for the software. It's made for the people. Either the community works, either there is some trust in the people and so, or not. You cannot create trust by making more technical stuff around it.
A working community will fix something like you describe very, very fast. Or not (if you're right).

The difference is: I give trust into it, that it will.

Oh and I am a computer scientist, I am not lazy. Thank you.

O. K., then it's only true, cause I don't know you.

[SHiRKiT]

I very much agree with ssilk. If you want to state an incompatibility, state it out clearly on your mod topic. If users don't read, they prolly wouldn't care if they can't place those 2 mods together, they would rant that the game does not allow the 2 mods combined. See my topic of Personal Roboport Fix, I could swear nobody would ever read the full instructions, like (in the past), not storing more than 10 robots per Personal Roboport equipped. But people actually read it, and it surprised me. Throw in a spoiler with RED BOLD CAPS stating INCOMPATIBILITY and you should be good to go.

But I'm totally against things that has happened in Minecraft Modding Community in the past. Let us learn with the other people's mistakes, and not to think that our community is strictly better than MC was, because it MAY not be true. When this grows (and we all know Factorio will explode in a few months, prolly 500.000 to 1.000.000 sales), the community may have really, really conflicting interests, like MC had.

[vzybilly]

I have afew reasons for wanting this.

The main one of why I want this is a group of mods that all add the same thing, almost the exact same thing, but ONLY one should be used. the thing that they add is colourable tiles. the idea was a core adds the machines and paints/dyes then another adds the actual tiles and colouring abilities, which allows different versions from light to heavy (1bit per colour to the full 8bits.) the lightest will use colour-tiles-X where X is 0 to 7, inclusive, where 7 is WHITE. the next lightest version (2bit) will use 0 to 63, inclusive, where 63 is WHITE and 7 is the colour value 0055FF (#) (if it was lightest and heaviest, White = #!). Now, having those two mods conflict make things easier and it's obvious why, they both do the same thing in different ways that conflict. but right now, if they had both active and place colour-tiles-7, do they get white or that other colour? disabling one in the code gets into issues as well, which one is already active in the save but we can't wait for there because the recipes would overwrite each other, so one has to be disabled but which one should we disable? was one too intensive for their computer and they went for a lighter? did they want more colour choices and went for a heavier? if we have to disable one, neither is the better option.
if I had to do make the mods now, I would purposefully write code that caused the game to crash if more than one was active, because I can not be the one to make the choice for them, they have to choose.

The other reason of mine, I had a mod in my rotation that caused accumulators not to recharge. one of my mods was powered by a custom accumulator. I added their mod because I wanted to move off of coal and in my world, I did an overhaul and switched all my trains over to electric trains which use those custom accumulators. when I was finally able to place their item and get it all working, I noticed that I no longer had resources because all my trains had stopped, after abit of looking around I found that no accumulators were charging and after abit of help, found out it was their mod. I snooped their code abit and didn't really find anything that would cause that. (upgraded pump + abit of code that drained its power to do things.).

Yet another reason, all made up but could actually happen, Mod A needs an API from Mod Q. Q does an update which breaks A, Q updates and fix it. people don't want to update Q because of reason Y but A gets updated. A can't fix the issue without re-implementing the same thing. A simply adds a conflict with that specific version of Q, problem fixed and everyone is happy after reverting or updating. another answer, A simply says the newer version is needed, people still refuse to update because of Y, the people stop using A.
A good example of Mod Q with reason Y, RSO. people refuse to use the newer versions because they don't like the way it works.

The more stupid case is, that we have one modder, that has a different opinion about something, which is controversial to the others and the other modders decide to boycott his mod.

If I wanted to boycott their mod, even without this feature, all I have to do is add their mod as an optional dependency, in the data-final-fixes, set an icon from their mod to "". Their mod item errors the game, they get bug reports, people can't use their mod. They have no way to fix it other than adding another mod that depends on my mod and fixes it, but then I could do the same, moving important stuff to the second so people have to get my second one as well. If enough people do this, their mod will die unless each user goes in and removes the code from all the boycotting mods.

[ssilk]

The main one of why I want this is a group of mods that all add the same thing, almost the exact same thing, but ONLY one should be used. the thing that they add is colourable tiles.

Interesting.
Well. There are some right and wrong ways to do it. But for that case it is clear, that all those mods cannot exist in parallel. One right way to do it, is that you have a mod, that controls all the others.
It will look like so:

Code: Select all

                 ColorControlMod

  Color1     Color2      Color3 .... Color7

The Color1-7 mods depend on having the ColorControlMod loaded. That way you can force this dependency.
The ControlMod can provide methods for Color1-7 to be called before initialization, that guarantees, that only one of those mods is running.
Well, I'm not sure if this is already possible, but see post before: Factorio should provide functions to make that.

That is one possible way,. One that is "right", because it is solved with architectural methods: You need to go into the house through the door, and not through the balcony in the 1st floor.
But there are many other solutions possible, to do this in the right way.

all my trains had stopped, after abit of looking around I found that no accumulators were charging and after abit of help, found out it was their mod. I snooped their code abit and didn't really find anything that would cause that.

Hum. That looks for me as an programming failure. Like the charge priorities of the devices has been changed.
And also: That problem is only yours (sorry for being so harsh, but it is true).

Mod A needs an API from Mod Q. Q does an update which breaks A, Q updates and fix it. people don't want to update Q because of reason Y but A gets updated. A can't fix the issue without re-implementing the same thing.

Where is the problem? Seriously: Who has a problem here? Mooder Q, Modder A or the users, that use both?

A simply adds a conflict with that specific version of Q, problem fixed and everyone is happy after reverting or updating. another answer, A simply says the newer version is needed, people still refuse to update because of Y, the people stop using A.

Again: Why do you need such a mechanism? You can do it in your code. You explained it below.

A good example of Mod Q with reason Y, RSO. people refuse to use the newer versions because they don't like the way it works.

If people don't like to use Q they don't use it. Or they fix Q. There is always more than one way.

all I have to do is add their mod as an optional dependency, in the data-final-fixes, set an icon from their mod to "".

Right. That's all. So why do you need a special mechanism, that has no possibility to add special logic, makes it impossible to understand, why something is like it is.

[vzybilly]

The main one of why I want this is a group of mods that all add the same thing, almost the exact same thing, but ONLY one should be used. the thing that they add is colourable tiles.

Interesting.
Well. There are some right and wrong ways to do it. But for that case it is clear, that all those mods cannot exist in parallel. One right way to do it, is that you have a mod, that controls all the others.
It will look like so:

Code: Select all

                 ColorControlMod

  Color1     Color2      Color3 .... Color7

The Color1-7 mods depend on having the ColorControlMod loaded. That way you can force this dependency.
The ControlMod can provide methods for Color1-7 to be called before initialization, that guarantees, that only one of those mods is running.
Well, I'm not sure if this is already possible, but see post before: Factorio should provide functions to make that.

That is one possible way,. One that is "right", because it is solved with architectural methods: You need to go into the house through the door, and not through the balcony in the 1st floor.
But there are many other solutions possible, to do this in the right way.

I would have a mod that all of them want, but again, I would feel very wrong deciding which they have use, the best way would be to have a popup asking them which they wanted but I don't think that's possible at the data step.

all my trains had stopped, after abit of looking around I found that no accumulators were charging and after abit of help, found out it was their mod. I snooped their code abit and didn't really find anything that would cause that.

Hum. That looks for me as an programming failure. Like the charge priorities of the devices has been changed.
And also: That problem is only yours (sorry for being so harsh, but it is true).

neither of our mods touched the basic accumulator entity. their mod was pretty much a stronger pump with 3rd level usage (tri-whatever). I'm not sure how to look to see which of our mods was at fault but I know, once I removed theirs, everything worked. but enough about this, it was just one example of a conflict.

Mod A needs an API from Mod Q. Q does an update which breaks A, Q updates and fix it. people don't want to update Q because of reason Y but A gets updated. A can't fix the issue without re-implementing the same thing.

Where is the problem? Seriously: Who has a problem here? Mooder Q, Modder A or the users, that use both?

A simply adds a conflict with that specific version of Q, problem fixed and everyone is happy after reverting or updating. another answer, A simply says the newer version is needed, people still refuse to update because of Y, the people stop using A.

Again: Why do you need such a mechanism? You can do it in your code. You explained it below.

A good example of Mod Q with reason Y, RSO. people refuse to use the newer versions because they don't like the way it works.

If people don't like to use Q they don't use it. Or they fix Q. There is always more than one way.

all I have to do is add their mod as an optional dependency, in the data-final-fixes, set an icon from their mod to "".

Right. That's all. So why do you need a special mechanism, that has no possibility to add special logic, makes it impossible to understand, why something is like it is.

because the game telling the user, "hey, this mod doesn't like this other one" is allot better than the game just crashing.
If I didn't have all the output of factorio copied to a file, it would take me abit of testing to see why it "just closes".
Plus, it's allot easier to remove the conflict in info.json than to search through all the data time scripts to see where the mod was being aggressive.
Also, getting/giving help for conflicts that are meaningless are allot easier, "just copy this info.json into the mod zip and you'll be good to go" verses "in the zip, go to thisFolder/thatFolder/thisExtraFolder and open file someFile.lua and remove line 387."

Also, using that dirty hack for aggressive conflicts,

Code: Select all

17.001 Error Util.cpp:46: Path  not matching the resource path pattern: __source__/path

since it doesn't even tell what item (Mod), people will spam the GAME bug reports forum with that error, meaning the people handling the bug report forum will have to know about any mod boycotting!



EDIT: debian relationships between packages, conflicts, both debian and fedora say not to use conflicts unless you have to, but there is also breaks. but breaks is not in the options either. I could see adding breaks/broken-by being used instead of conflicts.

[ssilk]

Plus, it's allot easier to remove the conflict in info.json than to search through all the data time scripts to see where the mod was being aggressive.
Also, getting/giving help for conflicts that are meaningless are allot easier, "just copy this info.json into the mod zip and you'll be good to go" verses "in the zip, go to thisFolder/thatFolder/thisExtraFolder and open file someFile.lua and remove line 387."

When done right is is something like:
"Replace the config.lua with this version".

For example something like

Code: Select all

if (is_mod_enabled('Q')) then
     display_message('Please turn off Q mod')
     exit
end

Or something like this if you created a workaround for the Q-mod between version 0.0.1 and 0.0.2.:

Code: Select all

if (is_mod_enabled('Q') && is_mod_version_between('Q', '0.0.1', '0.0.2') then
   config.q_workaround = true
end

(everything of course in pseudocode, not really working)

The config.lua is called directly in the startup of your mod. There where I would look for it.

Also, using that dirty hack for aggressive conflicts,

Code: Select all

17.001 Error Util.cpp:46: Path  not matching the resource path pattern: __source__/path

since it doesn't even tell what item (Mod), people will spam the GAME bug reports forum with that error, meaning the people handling the bug report forum will have to know about any mod boycotting!

But that is for me just a bug. I already was so close to report it, cause the information, what item, where, would be so extremely useful.

And so it is for all other examples: In most cases they are bugs, which aren't revealed yet and needs to be fixed. Just disabling them: No bugfix.

[vzybilly]

Also, using that dirty hack for aggressive conflicts,

Code: Select all

17.001 Error Util.cpp:46: Path  not matching the resource path pattern: __source__/path

since it doesn't even tell what item (Mod), people will spam the GAME bug reports forum with that error, meaning the people handling the bug report forum will have to know about any mod boycotting!

But that is for me just a bug. I already was so close to report it, cause the information, what item, where, would be so extremely useful.

And so it is for all other examples: In most cases they are bugs, which aren't revealed yet and needs to be fixed. Just disabling them: No bugfix.

but it's not a bug, it's an aggressive conflict. that's the issue, it looks like a real bug. people will report it, others will have to look through the mods and find out that a mod was aggressively conflicting another.

I made that bug by aggressively conflicting base, just wrap this with a "if it exists, then":

Code: Select all

data.raw.pump["small-pump"].icon = ""

Also, I added a link to the bottom of my last with debian packages, which use dependencies.

[ssilk]

Sorry, I pressed the submit button too early and edited the above post a bit more.

[vzybilly]

Plus, it's allot easier to remove the conflict in info.json than to search through all the data time scripts to see where the mod was being aggressive.
Also, getting/giving help for conflicts that are meaningless are allot easier, "just copy this info.json into the mod zip and you'll be good to go" verses "in the zip, go to thisFolder/thatFolder/thisExtraFolder and open file someFile.lua and remove line 387."

When done right is is something like:
"Replace the config.lua with this version".

For example something like

Code: Select all

if (is_mod_enabled('Q')) then
     display_message('Please turn off Q mod')
     exit
end

Or something like this if you created a workaround for the Q-mod between version 0.0.1 and 0.0.2.:

Code: Select all

if (is_mod_enabled('Q') && is_mod_version_between('Q', '0.0.1', '0.0.2') then
   config.q_workaround = true
end

(everything of course in pseudocode, not really working)

The config.lua is called directly in the startup of your mod. There where I would look for it.

this does look nice, and certainly solves most of the issues, but wouldn't that pretty much be the same thing that would happen by the game if you put conflicts? not the workaround part but the first one. it's exactly how I would picture conflicts working, and it tells the same amount of reasoning as well...

also, I do believe we don't have most of those methods yet.

[SirRichie]

Okay, I decided to rest my case especially since this thread became side-tracked, but I have to respond to one comment though:

My option is: The software is not made for the software. It's made for the people. Either the community works, either there is some trust in the people and so, or not. You cannot create trust by making more technical stuff around it.
A working community will fix something like you describe very, very fast. Or not (if you're right).

So at first you say: do not implement my suggestion, because people will misuse it.
Now here you say: put trust in the people, they will make it work.

I understand and share your general concern about social censorship (which by the way can also happen with "reacting" to the presence of a mod). But it is my suggestion that requires trust in the community

[vzybilly]

Okay, I decided to rest my case especially since this thread became side-tracked, but I have to respond to one comment though:

My option is: The software is not made for the software. It's made for the people. Either the community works, either there is some trust in the people and so, or not. You cannot create trust by making more technical stuff around it.
A working community will fix something like you describe very, very fast. Or not (if you're right).

So at first you say: do not implement my suggestion, because people will misuse it.
Now here you say: put trust in the people, they will make it work.

I understand and share your general concern about social censorship (which by the way can also happen with "reacting" to the presence of a mod). But it is my suggestion that requires trust in the community

Sorry for filling up the thread but I also don't really see where it's too much side-tracked...

Hi,

I think it would be great if mod developers could not only list dependencies, but also conflicts in the info.json.
Reasons for conflicts could be items named the same way, buggy versions of mods which cause the mod to break or incompatible behavior (control.lua).

If that option already exists, even better, but I could not find any reference.

My first case was for items named the same way, with the same type of behaviour but in different ways behind the scenes, 7 = white for A but for B, 7 = black.
My Second case was for a mod that broke ALL accumulators, atleast when my mod was present (haven't seen any bug reports from others...)

infact, those are the reasons that package managers have conflicts and breaks. Items named the same but have different functionality and both devs refuse to change the name is one of the few times that fedora allows the conflicts tag. debian also gives us breaks which takes most of the other use cases of conflicts away, but even then, there are still times when conflicts is used and valid!

[vzybilly]

This quote was originally was posted in https://forums.factorio.com/forum/vie ... =6&t=16567 ; moved here

Ah, you begin to understand, what I mean?

To your example with the package managers. Yes and no. For Linux package managers it is important. The field where the debian or any other package manager works is so gigantic, that such things make sense.
Think for example also to some big risks: They are responsible to keep any Linux system in a stable state. Security issues can happen in such cases. You get an instable system. The damage can be really big.

What's indeed needed for Factorio is some kind of interface-extension to find out such dependencies, like you described above. To enable the modder (which is in my opinion responsible for that (even if he hasn't cause it)) to fix such issues in clever ways.

And maybe, at some time into the future, we need an packet-manager.
Maybe.
But I doubt it, because it's a game and programming games with Lua is also a lot of fun. If you make it more complex, if you say "you need to think to the factorio-packet-manager" it will make things ugly. The cases you describe are so seldom and have such a low risk in operation (ugliest thing that can happen: you need uninstall mods), I don't see the need now - even if it is for the person, which is hit by such an issue is a big deal.

But at this point I think: Therefore is the community. I'm sure, if you post your issues with some mods in this forum in a way, that pays attention, there will be some people, which are willing to help to fix it and make it playable again.

The issue, Mods are packages. don't think of it has the big scary "Factorio Package Manager Of DOOM~!" think of it as, "Factorio Mod Manager of Amazingness", which it is.
Mods have dependencies and I brought in packages that also have dependencies but the two are really the same, even more so when a user goes, "I WANT ALL MODS!".
There is probably afew thousand different mods, will they all work nice together?
There WILL be more in the future, isn't now the time to think about better ways?
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...

[ssilk]

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.

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.