[2.0] Add support for mods to mark themselves as incompatible with specific feature flags

[Radjack]

TL;DR

Mods might wish to opt out of supporting certain feature flags, this would give them a method to do so.

What ?

It would be nice to be able to mark a mod as incompatible with a feature flag, automatically making it incompatible with mods that activate that feature flag. As an example a complicated overhaul mod might not wish to perform the balance work needed to support the quality feature, currently the only tool the mod developer has to prevent this is marking mods incompatible on a one by one basis.

While there are a limited number of feature flags currently, they represent a concice way of grouping features introduced to the engine and used by mods. I could envisage a future where more are introduced and with each introduced the complexity of their interactions with each other increases.

I believe it is currently possible to check during the control stage if a quality prototype other than "normal" exists, so it should be possible for mods to inform users of the incompatability without this new feature for the quality feature flag. I am unsure if current methods for safely checking the enablement of other feature flags exist when you desire to prevent their use. As such native support for this might be the only way to allow such checks.

Why ?

Factorio is a fantastic sandbox. It's current systems have allowed a plethora of complicated overhaul mods to flourish, with the increase in features available to modders the complexity of balancing these mods increases. As such I think the ability to both define which feature flags a mod enables and which mods it does not support will be a boon to the modding community.

[curiosity]

This is Space Exploration all over again. Balancing a modpack is the problem of the modpack author, not a mod author. Declaring incompatibility due to non-technical issues is harmful to the modding community, because it prevents other people from making compatibility mods. This request should not be implemented without proper justification.

[EustaceCS]

Balancing a modpack is the problem of the modpack author, not a mod author.

True. But not entirely.
It's end user's right to install everything.
It's modder's responsibility to inform about 100% faulty combinations involving his mod.

Declaring incompatibility due to non-technical issues is harmful to the modding community, because it prevents other people from making compatibility mods.

Not declaring these brings more harm than good. This stuff took its toll at Skyrim modding already. Maybe it's worth studying the question before making The Statement.
Let's say I'm considering some mod which may or may not be related to vehicles.
And I 100% don't want to waste my time for debugging my vehicle mod vs ALL other vehicles mods at once.
Why wouldn't I declare potential incompatibility in advance?

And now for something completely different.

I believe it is currently possible to check during the control stage if a quality prototype other than "normal" exists, so it should be possible for mods to inform users of the incompatability without this new feature for the quality feature flag. I am unsure if current methods for safely checking the enablement of other feature flags exist when you desire to prevent their use. As such native support for this might be the only way to allow such checks.

Quality framework is shipped as a mod.
Modders can declare incompatibility of mods with specific mods explicitly, no?
Ban it here and let it sink elsewhere.

[Ranakastrasz]

As long as the flags are warnings, which can be suppressed, instead of blocking.

[robot256]

Nothing is stopping you from declaring an incompatibility with the DLC Quality mod, for example. And nothing is stopping anyone else from making a different quality mod that might be more compatible with your mod than you could initially imagine. I don't see what else is needed besides some big red text in the mod description.

[curiosity]

True. But not entirely.
It's end user's right to install everything.
It's modder's responsibility to inform about 100% faulty combinations involving his mod.

"100% faulty" is a much narrower set than you think. If a third mod can change the outcome, then it's not 100% faulty. Normally a 100% faulty situation means a runtime error or a conflict between the two mods' runtimes.

Not declaring these brings more harm than good. This stuff took its toll at Skyrim modding already. Maybe it's worth studying the question before making The Statement.

From what I can tell, Skyrim modding is a free-for-all, much like the old Minecraft modding. So it's not applicable.

Let's say I'm considering some mod which may or may not be related to vehicles.
And I 100% don't want to waste my time for debugging my vehicle mod vs ALL other vehicles mods at once.
Why wouldn't I declare potential incompatibility in advance?

Because you don't know that it's incompatible. When you declare incompatibility, that's final. The player has no intended way to overcome it, even when it would make sense. They have to resort to editing your mod and putting up with consequences.

Quality framework is shipped as a mod.
Modders can declare incompatibility of mods with specific mods explicitly, no?
Ban it here and let it sink elsewhere.

They are asking to ban quality as a mechanic altogether.

[EustaceCS]

Let's say I'm considering some mod which may or may not be related to vehicles.
And I 100% don't want to waste my time for debugging my vehicle mod vs ALL other vehicles mods at once.
Why wouldn't I declare potential incompatibility in advance?

Because you don't know that it's incompatible. When you declare incompatibility, that's final. The player has no intended way to overcome it, even when it would make sense. They have to resort to editing your mod and putting up with consequences.

Goebbels, sir, remember that the player can always download a copy of a mod locally, remove incompatibility enforcing string from its manifest, and live with consequences without blaming modder.
As of "that's final" part... it looks like you're trying to say that mod portal bans mod makers from altering mod manifest in any form after upload. I have a feeling that it's not what you're trying to say.
Calm down.
You can live through three remaining days until Space Age release without making one more enemy for absolutely no reason.

[curiosity]

Goebbels, sir, remember that the player can always download a copy of a mod locally, remove incompatibility enforcing string from its manifest, and live with consequences without blaming modder.
As of "that's final" part... it looks like you're trying to say that mod portal bans mod makers from altering mod manifest in any form after upload. I have a feeling that it's not what you're trying to say.

I don't get the Goebbels reference. Godwin's law? Are you saying that you are out of arguments?
I call the declaration final because it can not be amended by other mods. Only by editing the mod in question. As to why the user shouldn't have to live with the consequences, maybe you have never tried locally modifying an actively developed software. Having to do it every time you update is annoying enough by itself, but in case of Factorio mods it will also cause problems when joining multiplayer games.
Also, I don't see why you are telling me about this. It's not like I'm unaware, I said the very same thing in the paragraph you quoted.

Calm down.
You can live through three remaining days until Space Age release without making one more enemy for absolutely no reason.

I am calm and not trying to make enemies, merely arguing for what I believe is right. But if you are going to consider me an enemy, be it your way, I am powerless to stop you.
This request is also not rendered obsolete by Space Age, it's about Space Age, so I don't see how its release is relevant here.

[EustaceCS]

Are you saying that you are out of arguments?
... maybe you have never tried locally modifying an actively developed software.

And, we can wrap this attempt at civilized dialogue up. This dialogue branch leads to nowhere. "Can you provide more specific examples of where it did more harm or more good?" would probably lead us anywhere.
I've placed my feedback in this theme. I'm OK with not encouraging flame. After all, "to implement or not to implement" is not our decision to make.