[0.15] Mod setting/config interface - give your input

[justarandomgeek]

Prototype picker (any prototype type) - which will simply give the string prototype name but the GUI will have a drop-down of all options

How about a signal picker?

The way I read it it sounds like it's a prototype picker for which we can tell it a particular type of prototype we want (item, entity, recipe, virtualsignal, technology...) I suppose "signal" is special though, since it would take item/fluid/virtual....

[folk]

I'm definitely going to be adding more mod setting types once this initial wave of 0.15 bugs is taken care of. Probably another 2 weeks and then I'll start on stuff like this.

Right now setting types I'm going to add are:

• Prototype picker (any prototype type) - which will simply give the string prototype name but the GUI will have a drop-down of all options
• Color picker (similar to the train one but with alpha as well)

That sounds excellent, but I will reiterate the need for a validate/allowed_patterns/exclude_patterns properties.
For example on the property picker, if I wanted to only allow entity prototypes of type "radar" and only include radards where the name ended in "-folk", I could add the property
allowed_patterns = {"%-folk$"}

And the settings would hide any prototype that doesn't match. And opposite with exclude_patterns. Or, alternatively, simply give us the ability to have a validate=function(input) return true/false end

Also, another thing that would be helpful (I've had a need for it twice now) is the ability to have lists of any setting type. So you could add a meta-setting like type="array-setting", name="foo", array="other-setting-name", maximum_entries=5, minimum_entries=1.

other-setting-name could then be any other setting type, and the two entries would work in tandem to allow the player to pick an array of items.

I'm sure you can think of a better way of doing it.

[Optera]

Startup settings allow for configurable recipes, however factorio doesn't automatically call reset recipes.
What's the best way for a script to reset recipes in case a certain startup setting changed?

Most modder friendly would be if we could have a flag at startup settings "requires_recipe_reset" which urged factorio to do a proper recipe reset each time it restarts after such a setting was changed.

[Nexela]

Startup settings allow for configurable recipes, however factorio doesn't automatically call reset recipes.
What's the best way for a script to reset recipes in case a certain startup setting changed?

Most modder friendly would be if we could have a flag at startup settings "requires_recipe_reset" which urged factorio to do a proper recipe reset each time it restarts after such a setting was changed.

on_init global.my_recipe = settings.startup["name"].value

on_configuration_changed(function() if global.my_recipe ~= settings.startup["name"].value then --update the global, reset the recipes end end)

[Optera]

Startup settings allow for configurable recipes, however factorio doesn't automatically call reset recipes.
What's the best way for a script to reset recipes in case a certain startup setting changed?

Most modder friendly would be if we could have a flag at startup settings "requires_recipe_reset" which urged factorio to do a proper recipe reset each time it restarts after such a setting was changed.

on_init global.my_recipe = settings.startup["name"].value

on_configuration_changed(function() if global.my_recipe ~= settings.startup["name"].value then --update the global, reset the recipes end end)

Changing startup settings triggers on_configuration_changed?
I can't get that to trigger when only startup settings change.

Currently I'm using an on_tick which unregisteres itself after one tick. Mods with normal on_tick handlers will have to register their normal on_tick in this run_once.

Code: Select all

local function run_once()
  for i, force in pairs(game.forces) do
    force.reset_recipes()
  end
  script.on_event(defines.events.on_tick, nil)
end

script.on_load(function()
  script.on_event(defines.events.on_tick, run_once)
end)

[Rseding91]

Currently I'm using an on_tick which unregisteres itself after one tick. Mods with normal on_tick handlers will have to register their normal on_tick in this run_once.

Code: Select all

local function run_once()
  for i, force in pairs(game.forces) do
    force.reset_recipes()
  end
  script.on_event(defines.events.on_tick, nil)
end

script.on_load(function()
  script.on_event(defines.events.on_tick, run_once)
end)

FYI: that mod will never run in MP as that would desync everyone the first time it ran.

[Optera]

FYI: that mod will never run in MP as that would desync everyone the first time it ran.

I know it's a hack only working for SP.

[Rseding91]

For now, the best you can do is tell the player they have to start a new map or call reset recipes/technologies themselves if they change values.

I'll think about a way to make it work automatically.

[folk]

This whole time, since settings.lua was introduced, I've (wrongly, I see now) assumed that startup settings applied during game creation were persisted throughout the lifetime of the game - and that if I changed them, the settings as they were during initial game creation would simply be used and my changes ignored.

If that is not the case - and you don't want to simply make it so - my guess is that the "best" way to handle it would actually be to have a specific event called on_startup_setting_changed that you invoked at some point in the loading process. Or, alternatively, trigger a specific named migration script that might force a restart of the game (to reprocess data) depending on state/return value.

Or simply make my initial assumption true; that whenever you load a game, the startup settings that were in effect at game creation are reapplied and the game restarted after a notification.

I mean, I've assumed this the whole time. This is how I expected startup settings to work all along; that you can't change them and that doing so will force a game restart if I tried to load a save with different settings. I've just never tried to change them during a running game.

[Optera]

I can thing of several ways to make it work.

• Make on_configuration_change trigger on changed prototypes.
• A new event on_run_once firing every time a map loads with full access to game and global in which we could perform such operations.
• Add a flag "requires_recipe/technology_reset" to startup settings so the game knows when to reset.

I'm very much in favor of the 2nd option as it's the simplest to add and offers the most flexibility to modders.

[Rseding91]

I can thing of several ways to make it work.

• Make on_configuration_change trigger on changed prototypes.
• A new event on_run_once firing every time a map loads with full access to game and global in which we could perform such operations.
• Add a flag "requires_recipe/technology_reset" to startup settings so the game knows when to reset.

I'm very much in favor of the 2nd option as it's the simplest to add and offers the most flexibility to modders.

The 2nd thing you listed is never going to happen. Loading the game should never result in the game changing unless the prototype values have changed. If it did, then multiplayer would never work.

[Rseding91]

This whole time, since settings.lua was introduced, I've (wrongly, I see now) assumed that startup settings applied during game creation were persisted throughout the lifetime of the game - and that if I changed them, the settings as they were during initial game creation would simply be used and my changes ignored.

If that is not the case - and you don't want to simply make it so - my guess is that the "best" way to handle it would actually be to have a specific event called on_startup_setting_changed that you invoked at some point in the loading process. Or, alternatively, trigger a specific named migration script that might force a restart of the game (to reprocess data) depending on state/return value.

Or simply make my initial assumption true; that whenever you load a game, the startup settings that were in effect at game creation are reapplied and the game restarted after a notification.

I mean, I've assumed this the whole time. This is how I expected startup settings to work all along; that you can't change them and that doing so will force a game restart if I tried to load a save with different settings. I've just never tried to change them during a running game.

Startup settings don't work like that. They're simply a built-in way to change prototype properties without actually editing the mod(s) directly. Just like how changing mods still lets you load any save file changing startup mod settings lets you load any save you want.

If it didn't work this way nobody would ever be able to play a save they created beyond the immediate game version they created it in since every new game version/mod version would change the prototypes in some way.

[Rseding91]

I've changed it for the next version of 0.15 so when mod startup settings are changed it fires the on_configuration_changed event.

That also means that in the next version of 0.15: recipes and technologies are automatically reset any time prototype values, startup settings, mod versions, or the game version changes.

[Optera]

I've changed it for the next version of 0.15 so when mod startup settings are changed it fires the on_configuration_changed event.

That also means that in the next version of 0.15: recipes and technologies are automatically reset any time prototype values, startup settings, mod versions, or the game version changes.

Thanks for this fix.

Just for clarification.
Do mods have to include reset_recipes in on_configuration_changed or does factorio call it automatically like it does when changing versions?

[Rseding91]

I've changed it for the next version of 0.15 so when mod startup settings are changed it fires the on_configuration_changed event.

That also means that in the next version of 0.15: recipes and technologies are automatically reset any time prototype values, startup settings, mod versions, or the game version changes.

Thanks for this fix.

Just for clarification.
Do mods have to include reset_recipes in on_configuration_changed or does factorio call it automatically like it does when changing versions?

It does it automatically.

[bobingabout]

I don't know if this has been mentioned before or not, but I've noticed that since I heavily make use of "startup" options to edit the data table from the mod options, Recipes and Technologies are NOT changed to match what you change the settings to when loading a savegame.

I feel the need to force a reset_recipes() and reset_technologies() event, as well as actually trigger a "on_startup_mod_settings_changed" event to run the equivalent of a migration script.

EG, if a mod update adds a new entity to the game, and adds that unlock to an existing technology, then you'd have a migration script run like this:

Code: Select all

for index, force in pairs(game.forces) do
  force.reset_recipes()
  force.reset_technologies()

  if force.recipes["bob-distillery"] and force.technologies["electrolysis-1"].researched then
    force.recipes["bob-distillery"].enabled = true
  end
end

What I feel we need is the ability to add something like that in control.lua to be triggered when startup settings have changed.

Basically, this but for startup settings http://lua-api.factorio.com/latest/even ... ng_changed

[Optera]

I don't know if this has been mentioned before or not, but I've noticed that since I heavily make use of "startup" options to edit the data table from the mod options, Recipes and Technologies are NOT changed to match what you change the settings to when loading a savegame.

I feel the need to force a reset_recipes() and reset_technologies() event, as well as actually trigger a "on_startup_mod_settings_changed" event to run the equivalent of a migration script.

EG, if a mod update adds a new entity to the game, and adds that unlock to an existing technology, then you'd have a migration script run like this:

Code: Select all

for index, force in pairs(game.forces) do
  force.reset_recipes()
  force.reset_technologies()

  if force.recipes["bob-distillery"] and force.technologies["electrolysis-1"].researched then
    force.recipes["bob-distillery"].enabled = true
  end
end

What I feel we need is the ability to add something like that in control.lua to be triggered when startup settings have changed.

Basically, this but for startup settings http://lua-api.factorio.com/latest/even ... ng_changed

That's what the 11 posts right before yours where all about.

[mickael9]

Any news on the localised combobox entries?

[Rseding91]

Any news on the localised combobox entries?

I'll do it in 0.16. I don't want to break something this close to a 0.15 stable version.

I'm planning on doing several changes to mod settings for 0.16.

[moon69]

Mod settings display order:

• Mod settings are shown in the settings GUI first sorted by mod sort order then sorted by the setting "order" string and then finally by the setting name.

What exactly is the "mod sort order" and how do I change it !?
Thanks.