Allow hidden setting to always use the default_value

[lovely_santa]

Back in 2019 I made an initial mod request (69300) which has been closed since in 0.18 this is interpreted wrongly. Bilka suggested me to make another attempt

Since 0.18.20 the game allows you to hide settings. My request is to force these hidden (start-up) settings to always use the default_value of the mod. Currently a player can circumvent this as follows:

• Assume mod X want a setting from mod Y to be set at option A, so what this mod does, it set the default_value to option A, and hides the setting such that the player cannot change this setting. Of course other mods could still change this during the settings loading phase.
• Prior to loading the modpack, The player first load mod Y, which will have the setting exposed (because mod X is not present to hide it). The player manually set the setting to option B.
• When the player will close factorio, the setting in question will have option B saved into the mod-settings.dat file.
• The player now loads the modpack with mod X and Y present. Mod X will change the default value and hide the setting. Because the setting was stored in the mod-settings.dat file, option B will be used to load the game, independent if the setting is hidden or not.

In a more lua syntaxic way described, the used_value can be written as:

Code: Select all

used_value = get_value_from_file("mod-settings.dat") or default_value

The expected behaviour that I would want to request would behave as follows:

Code: Select all

if setting_is_hidden then
    used_value = default_value
else
    used_value = get_value_from_file("mod-settings.dat") or default_value
end

If the devs do not want to change the behaviour of this hidden property, I propose adding another property force_default_value (default set to false) which would have to be set to false when hidden is set to false.

Kind regards
lovely_santa

[sparr]

What are you going to do with a default value if it has been changed and isn't being used by the other mod? This sounds like a recipe for disaster and mis-compatibility between mods.

[lovely_santa]

What are you going to do with a default value if it has been changed and isn't being used by the other mod? This sounds like a recipe for disaster and mis-compatibility between mods.

A simple example for this is the interaction between the (many) bobs mods and angels mods.

In bobs mods there is a whole list of "Enable gold ore" and that for any ore present in the mod. When angels refining is present, all of bobs ore won't spawn, as angels refining adds an extra step to this process. So instead, angels refining hides these settings, as they are of no use. Angels mods also force the default_value to be set to false, which actually speeds up the loading process for both bobs mods AND angels mods, as bobs mods will not create all the ores, and angels mods won't have to disable them all again. As of now, we can try to set these default_settings, but we still have to account for when the actual value of the mod is not set to false, for example when someone has bobs mods loaded first and decided to add some angels mods into the mix, and hence use the settings present inside mod-settings.dat file for the bobs mods in question.

If a mod adds a setting with different possible values, all those possible values should be supported by that mod. Forcing a mod to have one particular setting, for the reason of mod compatibility should not have any effect on the mod that created the setting in the first place.

Due note that I am here only refering to changing settings during the data stage (so during settings, settings-updates and settings-final-fixes). In this particular case I am also talking about startup settings, which cannot be changed during runtime (control stage) anyway.

[eradicator]

If a mod adds a setting with different possible values, all those possible values should be supported by that mod. Forcing a mod to have one particular setting, for the reason of mod compatibility should not have any effect on the mod that created the setting in the first place.

Now i'm utterly confused. You're not saying that you want the value of a setting to depend on which mod is reading the setting, right? Because that would be lovecraftian insanity.

I thought the whole idea was to allow modA to enforce the value modB's settingB for compatibility (i.e. because for some reason modA is unable to support all possible values of setttingB). And i seem to remember that this was possible via manipuation of allowed_values except for booleans which don't have allowed_values. So why are you not simply requestion allowed_values for boolean? Unless you're concerned about preserving the original user value of settingB after uninstallation of modA.

[lovely_santa]

If a mod adds a setting with different possible values, all those possible values should be supported by that mod. Forcing a mod to have one particular setting, for the reason of mod compatibility should not have any effect on the mod that created the setting in the first place.

Now i'm utterly confused. You're not saying that you want the value of a setting to depend on which mod is reading the setting, right? Because that would be lovecraftian insanity.

"If a mod adds a setting with different possible values, all those possible values should be supported by that mod"
=> That mod should provide implementation support for all possible values of the setting that mod has provided

"Forcing a mod to have one particular setting"
=> When another mod could force the setting, if that forced sitting is a 'valid' setting, the mod should not crash. By valid I mean a possible value that the first mod intended to be possible to be used.

I thought the whole idea was to allow modA to enforce the value modB's settingB for compatibility (i.e. because for some reason modA is unable to support all possible values of setttingB). And i seem to remember that this was possible via manipuation of allowed_values except for booleans which don't have allowed_values. So why are you not simply requestion allowed_values for boolean? Unless you're concerned about preserving the original user value of settingB after uninstallation of modA.

That's indeed a great idea, and also the correct functionallity I tried to describe.

[sparr]

I still don't understand. Could you finish out a hypothetical example, based on Angel's and Bob's ores? What would your third party mod be doing with Bob's ore settings?

[orzelek]

I still don't understand. Could you finish out a hypothetical example, based on Angel's and Bob's ores? What would your third party mod be doing with Bob's ore settings?

He wants his mod to overwrite Bob's mods setting to value he wants for Angel's mods to work nicely.
I'm not sure if thats possible or not but I think Angel's mod should be able to just edit the setting value.
It seems that that doesn't work because if player has changed this setting then player set value takes precedence. And at that point there is no way for mod to change that value which leads to a setting that is not optimal for Angel's mods to be applied at startup phase I guess.

Giving mods ability to revert setting to default or just overwrite it's value would allow Angel's mod to adjust settings to required values.

[KiwiHawk]

Yes please! This is exactly what I need for Sea Block. Currently we've got a separate mod (A Sea Block Config) to do just this.

It's only an issue for bool-settings. The others I can force using allowed_values.

[Rseding91]

Ok, I added "forced_value" to the bool setting type. When "hidden" is true it will be read in and force the bool setting to always be what ever value it is. When hidden isn't true it's ignored completely.

That in combination with "allowed_values" for the other setting types should let you do what you're trying to do.

[emp_zealoth]

I still don't understand. Could you finish out a hypothetical example, based on Angel's and Bob's ores? What would your third party mod be doing with Bob's ore settings?

He wants his mod to overwrite Bob's mods setting to value he wants for Angel's mods to work nicely.
I'm not sure if thats possible or not but I think Angel's mod should be able to just edit the setting value.
It seems that that doesn't work because if player has changed this setting then player set value takes precedence. And at that point there is no way for mod to change that value which leads to a setting that is not optimal for Angel's mods to be applied at startup phase I guess.

Giving mods ability to revert setting to default or just overwrite it's value would allow Angel's mod to adjust settings to required values.

But let's say I want to enable some particular Bob's ore in Angel's + Bob's? Could I do it after the change? Or will the option just get completely locked away?
(It's just a handly example, but i like doing some weird ass game settings usually)