Factorio Forums

Currently mod settings are read only. I am about to change the way a number setting in my mod works by a factor of 10. I need a way so that when a game using my mod gets loaded that was previously using on older version, I can /=10 that setting for that save.

You can change the valid range for your settings in the prototype which will force the loaded values to conform.

As for changing values: the values can only be changed by the player because if mods could change them then what the player picks doesn't really mean much because it doesn't stick with it.

In this case, the valid range didn't change enough to enforce a new value. And even if it did, I needed the new value to be 10x the old value.

To be specific, the value in question is a threshold amount of fluids. You guys 10x'd all the fluid amounts, so I needed to 10x the thresholds.

I agree that letting mods change settings all the time isn't great, but maybe it should be valid in migrations or init event handlers or somewhere?

sparr wrote:In this case, the valid range didn't change enough to enforce a new value. And even if it did, I needed the new value to be 10x the old value.

To be specific, the value in question is a threshold amount of fluids. You guys 10x'd all the fluid amounts, so I needed to 10x the thresholds.

I agree that letting mods change settings all the time isn't great, but maybe it should be valid in migrations or init event handlers or somewhere?

I think you mean migration script for settings?

I can do that: allow scripts to change settings through migration scripts.

Excellent!

Now I just need to figure out how real migration scripts work. My mods all use the global.mod_version global.data_version paradigm currently.

Migration scripts are

migration_0.0.0.json Runs once and marked as ran in the map so it will not run again.
for stuff like entity - to - entity migration, recipe to recipe etc
This runs before the map loads so you can replace any entity that doesn't exist because you removed it to something else.

migration_0.0.0.lua Runs once and marked as ran in the map so it will not run again.
Has access to .game but not global
Commonly used for enabling/disabling recipes depending on research.

http://lua-api.factorio.com/latest/Migrations.html

The on_configuration_changed event is what you use to migrate stuff in your global variable
i.e you replace they way your script works
global.old_var = nil
global.new_var = {}
for mycode do populate new_var end

Rseding91 wrote:I can do that: allow scripts to change settings through migration scripts.

Thanks, it's really needed.
I spent a good chunk of today hunting down errors due to invalid mod settings after changing the setting type or removing some options from a dropdown.

Optera wrote:

Rseding91 wrote:I can do that: allow scripts to change settings through migration scripts.

Thanks, it's really needed.
I spent a good chunk of today hunting down errors due to invalid mod settings after changing the setting type or removing some options from a dropdown.

That's just an error with the settings. It should force the value within the allowed range + allowed values when they change but it's not right now.

Rseding91 wrote: ↑

Thu Apr 27, 2017 9:45 pm

You can change the valid range for your settings in the prototype which will force the loaded values to conform.

As for changing values: the values can only be changed by the player because if mods could change them then what the player picks doesn't really mean much because it doesn't stick with it.

On the other hand, refusing write access prohibits hotkeys for toggling settings. I toggle recipe groups/subgroups with a mod setting and also a hotkey, because for e.g. heavy signal work confining the display to the signal group is best but ordinarily I just want the whole lot, so control-g toggles that. But without mod access to update the setting, the two can get out of step. You have a setting for minimap display and allow mods to change that by hotkey or howsomever, why should mods be prevented from offering hotkeys to change their own settings?

quyxkh wrote: ↑

Sat Feb 09, 2019 7:23 pm

Rseding91 wrote: ↑

Thu Apr 27, 2017 9:45 pm

You can change the valid range for your settings in the prototype which will force the loaded values to conform.

As for changing values: the values can only be changed by the player because if mods could change them then what the player picks doesn't really mean much because it doesn't stick with it.

On the other hand, refusing write access prohibits hotkeys for toggling settings. I toggle recipe groups/subgroups with a mod setting and also a hotkey, because for e.g. heavy signal work confining the display to the signal group is best but ordinarily I just want the whole lot, so control-g toggles that. But without mod access to update the setting, the two can get out of step. You have a setting for minimap display and allow mods to change that by hotkey or howsomever, why should mods be prevented from offering hotkeys to change their own settings?

A hotkey is its own type of setting.

Yes, and a mod cannot implement code to make the mod's own hotkeys update any of the mod's own settings. At all. They can't synchronize the state of their own settings with anything players are allowed to change by any other means, hotkey, gui, nothing.

Does this really seem right to you, that a keystroke and at least seven clicks in various places on the screen are required to change mod behavior by updating a per-player runtime setting, and if the player goes through all that everything stays in sync, but the mod cannot offer a hotkey that works as well?

Was this implemented in a 0.17 version? I think I remember people talking about it in the mod-making channel of the discord, but I might be wrong, and I can’t check right now because I’m away from home, on mobile.

It's fixed, I missed it in the changelog (it's there) but I saw a comment about it as well and just today got around to tryng it, I don't know whether this method's best, replacing the setting with a whole table as you do with fluid box contents, but it works: and the settings update redrives on_runtime_mod_setting_changed so all the behavior update code's in one place now, much cleaner.