Page 2 of 2
Re: Feature flags improvement
Posted: Sat Jan 04, 2025 12:56 am
by protocol_1903
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.
This is much better said than what I was trying to say. I like observation 2, and i think it should be the norm.
My issue with observation 1 is the case of Mod C enabling the feature flag for some benign purpose, forcing Mod A to run "spoil mode" even if the user does not want spoil mode enabled. Which I believe is why Observation 2 is the better of the 2.
Additionally, on the note about mod portal clutter, I think it would be better for end users to have an official set of "feature flags mods" for each feature flag so that they can be enabled by the user per-save with no doubt on which one(s) are enabled, and so observation 1 is never crossed and mods can instead check for the official feature flag mod(s)
Re: Feature flags improvement
Posted: Sat Jan 04, 2025 1:45 am
by curiosity
protocol_1903 wrote: Sat Jan 04, 2025 12:56 am
...and so observation 1 is never crossed and mods can instead check for the official feature flag mod(s)
Why?!
Feature flags are already checkable by themselves. Why add a pointless indirection? Why is it so important to you which mod enables which flag?
Re: Feature flags improvement
Posted: Sat Jan 04, 2025 2:15 am
by protocol_1903
curiosity wrote: Sat Jan 04, 2025 1:45 am
Why is it so important to you which mod enables which flag?
I find it important for cases when a user wishes to play a Mod A in "vanilla" mode, but Mod B enables feature flags for some extraneous use, forcing Mod A to run in "DLC" mode whether or not the user wants it.
Re: Feature flags improvement
Posted: Sat Jan 04, 2025 3:10 am
by curiosity
protocol_1903 wrote: Sat Jan 04, 2025 2:15 am
I find it important for cases when a user wishes to play a Mod A in "vanilla" mode, but Mod B enables feature flags for some extraneous use, forcing Mod A to run in "DLC" mode whether or not the user wants it.
That's solved by Mod A creating a setting if it so desires, we've been over this already. You even agreed.
Re: Feature flags improvement
Posted: Sat Jan 04, 2025 3:16 am
by robot256
protocol_1903 wrote: Sat Jan 04, 2025 12:56 am
This is much better said than what I was trying to say. I like observation 2, and i think it should be the norm.
My issue with observation 1 is the case of Mod C enabling the feature flag for some benign purpose, forcing Mod A to run "spoil mode" even if the user does not want spoil mode enabled. Which I believe is why Observation 2 is the better of the 2.
Additionally, on the note about mod portal clutter, I think it would be better for end users to have an official set of "feature flags mods" for each feature flag so that they can be enabled by the user per-save with no doubt on which one(s) are enabled, and so observation 1 is never crossed and mods can instead check for the official feature flag mod(s)
Thank you for the kind words. What I called "Observation 1" and "Observation 2" are simply two factual sets of cause and effect that both happen in the current system. Not competing proposals for which is better. Blindly enabling features based on flags is still technically an option, that's all I was saying. It can be used for mods that don't actually add content but need to enable compatibility for other mods that might.
protocol_1903 wrote: Sat Jan 04, 2025 2:15 am
curiosity wrote: Sat Jan 04, 2025 1:45 am
Why is it so important to you which mod enables which flag?
I find it important for cases when a user wishes to play a Mod A in "vanilla" mode, but Mod B enables feature flags for some extraneous use, forcing Mod A to run in "DLC" mode whether or not the user wants it.
Like curiosity said, if your goal is for the Mod A author to know the intention of the user and configure the mod accordingly, the ONLY way to know for sure is to
add a mod setting in Mod A that the user can control. The mod can read the state of the flags during the settings phase--no matter what other mod may have set them--and present the user with only the option(s) that are available for the current state of the flags.
This has zero downsides: In particular, it completely solves the case of Mod A changing behavior unintentionally when Mod C is installed because the setting value will still explicitly be "vanilla" in that save file, even though "spoil" is now a valid option for the user to select.
Edit: Also this conversion should really move to Modding help etc.