Factorio Forums

The idea that certain engine capabilities are locked behind feature flags is a great idea and I support their use. Where the current implementation falls down is an inability to interrogate their presence.

The current implementation of feature flags does not indicate weather or not a feature exists in the binary, it indicates weather or not a mod has enabled the flag. The mechanism to enable a flag is specifying that a flag is required in the mods info.json. Thus, presently it is not possible to create a single mod that can be used by both players that have the DLC binary and players that do not if the mod will optionally be able to interact with DLC only capabilities like spoilage, or stacking.

While it should be possible for a mod to indicate that it REQUIRES a feature flag, and prevent loading if it does not. The flag should not be false until a mod requires it. If the binary supports a capability the flag should be true. If the binary does not support the capability, it should be false. This allows a single mod to take advantage of a capability when it is present, and change behavior if it is not.

As noted just above one possible path would be to have the feature_flag always true if the binary supports it, and not depend on a mod to enable the flag. This way the info.json requires statement becomes a dependency, not switch that only has one option - "on".
Another option is to make the info.json a multi-state. "space_travel": [ "Required" | "Optional" ], where Required acts as a dependency and will not allow the mod to load on a binary that doesn't have / can't turn on the flag. Optional acts as a request. If the binary has the capability, turn the flag on. Then the mod can check the truthiness of of the flag in settings / prototype / and runtime stages later to adjust its behavior.

As it stands now we either need to make separate mods for the DLC binary, or the non-DLC binary. Or have the functionality split between separate mods. Or a mod that does nothing but enable feature flags in the event that a user decided to play without space-age, quality, or elevated-rails mods. Enable all Feature Flags.

The reason it doesn't work like this is for the case when two players join a multiplayer session, one with the SA binary and one without. Their modlists are the same, and in there is a mod that has the optional SA features enabled, but just for the player with the SA binary. Then when they both join, the mod tries to load different things for both of them, and desyncs ensue. The only way to fix this is to use a mod like Enable all Feature Flags that can only be used with the SA binary, in which case the modlists of the two players will be different and they cannot join each other. It's not the prettiest solution but it's the best option around, and the Enable all Feature Flags mod has already become a standard optional dependency for mods that have optional SA content.

Exactly. If there are only non-SA mods enabled, SA binary will behave exactly the same as non SA binary to make it possible for MP games to be possible between SA and non-SA binaries. As such there is nothing to change here. If all features would be enabled by default in SA binary then cross binary MP would not be possible at all and we would not even try adding those feature flags.

boskid wrote: Sun Dec 29, 2024 9:17 am Exactly. If there are only non-SA mods enabled, SA binary will behave exactly the same as non SA binary to make it possible for MP games to be possible between SA and non-SA binaries. As such there is nothing to change here. If all features would be enabled by default in SA binary then cross binary MP would not be possible at all and we would not even try adding those feature flags.

What about allowing a mod to load another mod that has a feature flag enabled, but then deleting everything from the other mod that requires the feature, and then disabling the feature flag? (So for example, you can have a mod that converts a space-age mod to non-space age, without duplicating the original mod).
(It'd also be helpful for my mod that tries to remove quality from space age)

Bassically, if you set a feature flag to false in your Json, it would cancel out a true value of any mods loaded before it.

IsaacOscar wrote: Mon Dec 30, 2024 2:59 pm What about allowing a mod to load another mod that has a feature flag enabled, but then deleting everything from the other mod that requires the feature

No.

boskid wrote: Sun Dec 29, 2024 9:17 am Exactly. If there are only non-SA mods enabled, SA binary will behave exactly the same as non SA binary to make it possible for MP games to be possible between SA and non-SA binaries. As such there is nothing to change here. If all features would be enabled by default in SA binary then cross binary MP would not be possible at all and we would not even try adding those feature flags.

This makes perfect sense, and something I hadn't even considered. It makes unconditionally enabling the feature_flag a non-solution. The state resolution still feels a bit cumbersome and potentially confusing for a player that hasn't delved into the feature_flag mechanics. I do think the user experience could still benefit from improvement where a single mod could be written to both work with the non-DLC binary, yet still enable and take advantage of DLC features if the player chooses without being optionally dependent on another mod to turn on the feature.

Would it be a reasonable improvement for a mods startup setting (or similar) to be able to enable (require) a feature flag. It still requires a restart to the game when changed, could be sync-able in a game save (requiring restart).
Additionally, add a way for a mod to know which binary it is running on so it can hide this setting if on non-DLC binary.

Mods could still unconditionally require (and turn on the features). Other mod would benefit with flexibility without depending on "enabler" mods and needing to document the need for such an enabler.

kryojenik wrote: Mon Dec 30, 2024 4:04 pm Additionally, add a way for a mod to know which binary it is running on so it can hide this setting if on non-DLC binary.

If a mod would know if its running on non-SA or SA binary, by using this information it would become a desync. This information is intentionally not provided.

Perhaps it might be better to officially support/push/recommend an "empty" DLC mod (like Enable all Feature Flags) so that mods can optionally require that mod specifically, and then players can choose to use that mod with other mods to enable DLC locked features. This way everyone knows and understands what mod should be used to use DLC features (quality, spoilage, elevated rails, etc) without explicitly enabling SA.

protocol_1903 wrote: Tue Dec 31, 2024 3:23 am Perhaps it might be better to officially support/push/recommend an "empty" DLC mod (like Enable all Feature Flags) so that mods can optionally require that mod specifically, and then players can choose to use that mod with other mods to enable DLC locked features. This way everyone knows and understands what mod should be used to use DLC features (quality, spoilage, elevated rails, etc) without explicitly enabling SA.

How does your idea differ from the already existing "Enable all Feature Flags"? Do you just want it to be "official"?

boskid wrote: Mon Dec 30, 2024 4:22 pm If a mod would know if its running on non-SA or SA binary, by using this information it would become a desync. This information is intentionally not provided.

Perhaps you could have it so the field tells you whether the *host* has the DLC, not the player that is executing the LUA code, alternatively, you could add a field to LuaPlayer, so you can check each player individual?

There is no point knowing the feature flags during runtime (besides, you can deduce them). All meaningful difference is in the prototype stage. So don't make it a setting, just make it readable.

edit: and it is.

And boskid wasn't saying "no" to a feature-enabling setting, only to knowing the executable type.

curiosity wrote: Tue Dec 31, 2024 12:00 pm There is no point knowing the feature flags during runtime (besides, you can deduce them). All meaningful difference is in the prototype stage. So don't make it a setting, just make it readable.

Oh yeah you're right, my idea won't be useful at all. Players won't exist until after the data stage, and you won't know the host either.

Perhaps singleplayer only mods should be a thing, and those mods can use advanced dsyncy features, e.g. file reqding.

IsaacOscar wrote: Tue Dec 31, 2024 3:28 am How does your idea differ from the already existing "Enable all Feature Flags"? Do you just want it to be "official"?

It doesn't need to be official, but more just officially recommended as the one and only "enable feature flags" mod so there's only one mod that other mods need to check for and there aren't fifty different mods for the same thing

protocol_1903 wrote: Thu Jan 02, 2025 1:30 am It doesn't need to be official, but more just officially recommended as the one and only "enable feature flags" mod so there's only one mod that other mods need to check for and there aren't fifty different mods for the same thing

Why would the other mods be checking for a mod when they should be checking for flags?

And there will always be fifty different mods doing the same thing, that's just the nature of an uncurated mod portal.

I believe it would be better for end users to have a mod to enable feature flags, instead of just having a random mod that uses spoilage to change every other mod to use spoilage as well. Like you have an overhaul mod that has optional spoilage, based on if the feature flag is enabled (not checking for a specific mod) then if the user installs any other mod that uses spoilage, even something small just for fun, the overhaul is forced into spoilage mode. I also think it's just easier for one mod than 50.

protocol_1903 wrote: Thu Jan 02, 2025 3:21 am I believe it would be better for end users to have a mod to enable feature flags, instead of just having a random mod that uses spoilage to change every other mod to use spoilage as well. Like you have an overhaul mod that has optional spoilage, based on if the feature flag is enabled (not checking for a specific mod) then if the user installs any other mod that uses spoilage, even something small just for fun, the overhaul is forced into spoilage mode. I also think it's just easier for one mod than 50.

The overhaul can have a setting then, like any overhaul from before 2.0. That's what settings are for.

curiosity wrote: Thu Jan 02, 2025 3:05 am

protocol_1903 wrote: Thu Jan 02, 2025 1:30 am It doesn't need to be official, but more just officially recommended as the one and only "enable feature flags" mod so there's only one mod that other mods need to check for and there aren't fifty different mods for the same thing

Why would the other mods be checking for a mod when they should be checking for flags?

And there will always be fifty different mods doing the same thing, that's just the nature of an uncurated mod portal.

I think you are missing the ask here. It isn't that mods check for the existence of a mod, they can (and some do) absolutely check for the flag. The problem is that there is no conditional way to "choose" to enable a feature flag. A mod must specify in its info.json that it requires the flag. Now the mod is restricted to the DLC binary, AND the flag will unconditionally be on. Thus if a mod wants to both work with non-DLC binaries, and offer a setting to enable or not-enable spoilage the mod MUST NOT require the flag in the info.json. And then 2nd mod is needed that has the flag enabled in its info.json to turn the flag on so that the 1st mod can now look for the flag and make a decision.

Your comment about the overhaul 'having a setting' is irrelevant since it would have to enable the flag in its info.json making unavailable for non-DLC and unconditionally having the flag enabled. Thus making the whole point of the setting moot.

I read this thread and think I can summarize the scenario in question:

- Mod A has "vanilla mode" and "spoil mode".
- Mod A developer does not want to release two mods on the portal, so writes one mod that includes both.
- Mod A cannot enable the spoilage feature flag itself, or vanilla mode would be unavailable to non-DLC players.
- When Mod A is loaded without the feature flag enabled, it uses "vanilla mode" exclusively.
- Mod B does nothing except enable the spoilage feature flag.
- When Mod A and Mod B are loaded together, Mod A will detect the enabled feature flag and use "spoil mode". This allows the use of "spoil mode" without having to enable Space Age itself.

Observation 1: It does not matter to either the user or the Mod A developer which mod enables the spoilage feature flag. There is no technical reason to avoid having 50 different feature flag mods. You could even enable all of them on the same save at once. It just makes mod portal clutter.

Observation 2: Mod A can create a *hidden* setting with its value set based on the feature flag that can easily be read in runtime. Additionally, it can unhide the setting when the feature flag is detected (thanks to Mod B being enabled) and give the user the option to disable spoil mode for that mod even when the flag is enabled. I think this is what curiosity is advocating for.

kryojenik wrote: Thu Jan 02, 2025 4:54 am I think you are missing the ask here. It isn't that mods check for the existence of a mod, they can (and some do) absolutely check for the flag. The problem is that there is no conditional way to "choose" to enable a feature flag. A mod must specify in its info.json that it requires the flag. Now the mod is restricted to the DLC binary, AND the flag will unconditionally be on. Thus if a mod wants to both work with non-DLC binaries, and offer a setting to enable or not-enable spoilage the mod MUST NOT require the flag in the info.json. And then 2nd mod is needed that has the flag enabled in its info.json to turn the flag on so that the 1st mod can now look for the flag and make a decision.

Your comment about the overhaul 'having a setting' is irrelevant since it would have to enable the flag in its info.json making unavailable for non-DLC and unconditionally having the flag enabled. Thus making the whole point of the setting moot.

That's not what protocol is saying.

robot256 wrote: Thu Jan 02, 2025 5:57 am I read this thread and think I can summarize the scenario in question:

- Mod A has "vanilla mode" and "spoil mode".
- Mod A developer does not want to release two mods on the portal, so writes one mod that includes both.
- Mod A cannot enable the spoilage feature flag itself, or vanilla mode would be unavailable to non-DLC players.
- When Mod A is loaded without the feature flag enabled, it uses "vanilla mode" exclusively.
- Mod B does nothing except enable the spoilage feature flag.
- When Mod A and Mod B are loaded together, Mod A will detect the enabled feature flag and use "spoil mode". This allows the use of "spoil mode" without having to enable Space Age itself.

Observation 1: It does not matter to either the user or the Mod A developer which mod enables the spoilage feature flag. There is no technical reason to avoid having 50 different feature flag mods. You could even enable all of them on the same save at once. It just makes mod portal clutter.

Observation 2: Mod A can create a *hidden* setting with its value set based on the feature flag that can easily be read in runtime. Additionally, it can unhide the setting when the feature flag is detected (thanks to Mod B being enabled) and give the user the option to disable spoil mode for that mod even when the flag is enabled. I think this is what curiosity is advocating for.

Well put. Though the setting value doesn't need to be based on the feature flag nor does the setting have to be hidden (it might, depending on which case looks less confusing).

I'm thinking specifically of a string setting where the list of available options would have two options when the flag is detected, and only one option when the flag is not detected. In the latter case the value would be forced to equal "vanilla". You are correct that the setting could be visible in both cases for transparency.