Factorio Forums

• 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.

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

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

sparr wrote: ↑Tue Sep 01, 2020 3:19 pm 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 wrote: ↑Tue Sep 01, 2020 3:26 pm 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.

eradicator wrote: ↑Tue Sep 01, 2020 4:01 pm

lovely_santa wrote: ↑Tue Sep 01, 2020 3:26 pm 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.

eradicator wrote: ↑Tue Sep 01, 2020 4:01 pm 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.

sparr wrote: ↑Tue Sep 01, 2020 8:08 pm 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 wrote: ↑Tue Sep 01, 2020 8:29 pm

sparr wrote: ↑Tue Sep 01, 2020 8:08 pm 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.