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

[aubergine18]

Sprite settings would be nice - rather than needing text captions all the time, sprites can sometimes make UI much more intelligible. Would work similar way to sprite button so easy to use sprites for existing item, resource, entity, tech, etc., but also allow custom sprites from within mod etc.

Example of sprite-ified game setting screen posted by someone over in Ideas & Suggestions forum:

[aubergine18]

Tabs (glorified radio buttons): used to both set and describe options

For example, I want to implement tech eras, and I want the player to have choice of which tech era to start at.

Each tab = tech era, depicted as label, sprite, or sprite + label

Tab content = table of non-input elements (label, sprite)

Note: If too much of a PITA to implement, I can revert to radio buttons or drop down. But from player perspective, it would be nice to provide some "more than just tooltip" elaboration for certain settings. Open to other suggestions on how option elaboration could be implemented.

Also: Tooltips, preferably via auto-generated locale keys based on option ids. And localisation is also needed for all options in general. I assume you already plan localisation/tooltips, but didn't see it mentioned so far in this topic.

[bobingabout]

Well, I've just found this and read the first post.

As mentioned in a couple of posts I skimmed, how to present the information could be a useful option. Or it could be automatic, such as radio buttons, or checkboxes for booleon, sliders, small text boxes and/or up/down arrows for numbers... and obviously a large text box for strings.

I think pretty much all my settings are either Boolean or a number, I can't recall ever having used strings yet.

My input for changes/additions would be a minimum/maximum range, and increment step set of values for those int and float variables.

For example... as a float, you might want only 0 to 1 as an option, or for an int 0 to 100.
The reason to restrict the range could be something like... it's known that if you set a value over nine thousand that things start to break.

Another tag could be increment steps.
You could be editing module stat multipliers as an example, if you set a value of 0.01, as in 1%, that is viable. if you set it to 0.0001, well, not much happens. So good values could be 0, 0.01, 0.02 ... 1.99, 2.0.
If it's a slider, that's 201 steps, unless you have a bar over 200 pixels wide, you're not going to get that sort of precision over the range, but you could be allowed to type the value in manually too... so entering 0.325... well, that's 32.5%, and not a valid increment step(in this example), so the game could round it to 0.33 for you, or 33%.

[aubergine18]

Why not provide a feature where mod can show it's own settings UI, which is enabled if the mod contains a `mod-settings.lua` file within it?

In the game Cities Skylines, most mods were fine with basic settings options like checkboxes, radio buttons, color pickers and sliders. Occasionally a text input. The game-provided UI was fine for them, they didn't need custom UI.

But some mods needed more, particularly if they had settings that depended on other settings, or needed to show additional infos or images to more clearly illustrate the effect of settings. So Colossal Order (who make C:S) added a feature that allowed mods to have their own custom options (in the case of C:S, that meant overriding the default Options button for the mod to trigger custom UI).

For Factorio, it could simply be presence of that `mod-settings.lua` file, when user goes to config the mod it would trigger an event in it. The only thing it would really need within that scope is a list of what mods are currently active (possibly with access to their settings?) and another event should that list of mods change (so the mod can adapt even its settings to presence of other mods, prior to game creation).

The custom settings screen from the mod would still utilise vanilla setting types defined in it's settings.json. The primary purpose of the UI is to provide more custom interface for changing settings, not to store settings in some weird format.

Aside: there should be general rule that all mod settings should have reasonable defaults, in other words don't force players to have to wade through the settings of every enabled mod prior to starting a game - they can just go in and change stuff it they want, but aren't forced to change stuff.

[Rseding91]

Why not provide a feature where mod can show it's own settings UI, which is enabled if the mod contains a `mod-settings.lua` file within it?

In the game Cities Skylines, most mods were fine with basic settings options like checkboxes, radio buttons, color pickers and sliders. Occasionally a text input. The game-provided UI was fine for them, they didn't need custom UI.

But some mods needed more, particularly if they had settings that depended on other settings, or needed to show additional infos or images to more clearly illustrate the effect of settings. So Colossal Order (who make C:S) added a feature that allowed mods to have their own custom options (in the case of C:S, that meant overriding the default Options button for the mod to trigger custom UI).

For Factorio, it could simply be presence of that `mod-settings.lua` file, when user goes to config the mod it would trigger an event in it. The only thing it would really need within that scope is a list of what mods are currently active (possibly with access to their settings?) and another event should that list of mods change (so the mod can adapt even its settings to presence of other mods, prior to game creation).

The custom settings screen from the mod would still utilise vanilla setting types defined in it's settings.json. The primary purpose of the UI is to provide more custom interface for changing settings, not to store settings in some weird format.

Aside: there should be general rule that all mod settings should have reasonable defaults, in other words don't force players to have to wade through the settings of every enabled mod prior to starting a game - they can just go in and change stuff it they want, but aren't forced to change stuff.

I'm not looking to implement anything like that. Most likely there will be just the options I listed on the first post: bool, numbers, strings. The lua GUI system is not designed to work outside of a running game and as such wouldn't work for something like the options menu.

[DedlySpyder]

I don't think it's been brought up yet, but support for optional settings would be good too. Plenty of mods have optional dependencies and may have different settings in different situations.

Oh, and can we somehow have an array as a setting? Like a multiple selection box (I guess it could be done with checkboxes, but having a check box for each entity would be clunkier than a list).


Also, to build on that, the way that it currently reads we wouldn't be able to have a dynamic list of entities, since the settings are loaded before the data stage. I think I saw someone bring up an item/recipe/entity selection option for a setting, and I think we'd need something like that (or somehow to load them during the data stages?)

[bobingabout]

He has a point. that's something I use often myself...
if bobplates then gold-ore = true
else gold-ore = false
as a default. the config mod overrides both.


Actually, more accurately...
bobores defaults it to false
bobplates overides that default and sets it to true
bobconfig allows the user to edit the option
bobores then does a check in to see what the config mod is set to, and sets it if not nil.

If I keep it all in the config mod, then nothing has to change.
To be honest, even if it's not just in the config mod, nothing has to change, I can write it in such a way that the ores mod on it's own, defaults to off... but certain mods like the bobplates mod can turn override the config option. so in the case of Ores it becomes... If bobplates or config option == true then true else false.

[Rseding91]

Ok, I spent some time doing some initial implementations on this and came to the following conclusion: mod setting names need to be unique globally.

Other than that, it's going quite well. If anyone has GUI designs for how they think each of the different setting types would be shown I wouldn't mind seeing them. I'm a programmer - not an artists - I don't really have any good ideas when it comes to how GUIs should look

The setting types I'm currently planning on supporting:

• Boolean
• int
• floating point
• string
• item/entity/fluid/signal

Obviously some of them are super simple but as I said: I'm not an artists

[Rseding91]

Sprite settings would be nice - rather than needing text captions all the time, sprites can sometimes make UI much more intelligible. Would work similar way to sprite button so easy to use sprites for existing item, resource, entity, tech, etc., but also allow custom sprites from within mod etc.

Example of sprite-ified game setting screen posted by someone over in Ideas & Suggestions forum:

That's a nice image - I like it over what we have now.

But, the main problem comes when you translate that text to other languages and now "Copper ore" becomes "Mina de cobre" (Spanish) and the alignment goes all wrong causing something to take up too much space.

[golfmiketango]

This is a great idea in general. One thing to think about that has not yet been mentioned: folks will need some kind of change management for these settings when mods are upgraded.

[DaCyclops]

This is looking just like what I hoped for, except for one usecase example...

Can I suggest a type of config called "storage" (alongside "startup" and "runtime"), that can only be per_user=true. Specifically designed for storing per-user install-wide information (for example, a players list of favourite blueprints, or their personal EvoGUI settings). Can be read as part of a player.read_mod_storage() type command (as opposed to a global) and the only type that can be written to (by a similar player.write_mod_storage). Basically to give mods a way to write/read data per-user that's not tied to a save specifically.

[orzelek]

One more idea:
Allow mod settings to be divided into basic ones (always visible) and advanced ones (hidden by default - expandable with a click).
This would allow to publish basic settings of a mod easily and leave advanced ones to play with for people that want go into details without overwhelming others with lots of settings.

[aubergine18]

That's a nice image - I like it over what we have now.

But, the main problem comes when you translate that text to other languages and now "Copper ore" becomes "Mina de cobre" (Spanish) and the alignment goes all wrong causing something to take up too much space.

An alternative would be to put the captions in tooltips rather than next to the images. This way, it doesn't matter how long the caption text is, it wont' affect the layout.

Ok, I spent some time doing some initial implementations on this and came to the following conclusion: mod setting names need to be unique globally.

Could the settings be automatically namespaced based on mod name?

For example, a mod named "MyMod" has a setting "Wibble" so the unique name for that setting is "MyMod.wibble".

[Nikey646]

What are the plans for allowing servers to apply settings on world generation?

Servers running RSO might run into trouble if a headless server generates the world, since well... It requires a GUI to configure? I see no mention of how the settings are saved, and how headless servers will react to them.

[Rseding91]

What are the plans for allowing servers to apply settings on world generation?

Servers running RSO might run into trouble if a headless server generates the world, since well... It requires a GUI to configure? I see no mention of how the settings are saved, and how headless servers will react to them.

You'll simply need to copy a mod-settings.dat file to the server and it will use that for settings on startup.

[Zeblote]

What are the plans for allowing servers to apply settings on world generation?

Servers running RSO might run into trouble if a headless server generates the world, since well... It requires a GUI to configure? I see no mention of how the settings are saved, and how headless servers will react to them.

You'll simply need to copy a mod-settings.dat file to the server and it will use that for settings on startup.

Can this be a mod-settings.json/ini instead? It'd be very useful to be able to edit it without starting the game.

[aubergine18]

Can this be a mod-settings.json/ini instead? It'd be very useful to be able to edit it without starting the game.

+1

[Rseding91]

Can this be a mod-settings.json/ini instead? It'd be very useful to be able to edit it without starting the game.

+1

Probably not. Manually editing doesn't allow for any verification of the settings and you're not going to be changing them and regenerating maps frequently on a server. If you want to "change it and see how it looks" that's something you'll do on your end with the game running and not on the server.

[aubergine18]

I assume we'll have some other method to output the settings then, for example via `log()`?

[ssilk]

A little bit late. I want to mention
viewtopic.php?f=80&t=16592 Game Setup, Game Configuration, Init Screen, Mod-Config
which includes eventually some good ideas.