- Mod settings tend to look like a solid wall of text, which makes them harder to understand.
- Some settings only make sense with other settings or with specific values of other settings (e.g. a feature selector and fine tuning of that feature), but there is no way to show this relation.
- Settings that affect multiple mods are listed under one specific mod, which is confusing.
- Giving control of setting visibility: a way to define an expression based on values of other settings to determine visibility of a given setting.
- Grouping settings together in a mod-independent way. Nested tabs, collapsible lists (like in controls settings) or something else you may come up with. There were multiple (not mutually exclusive) suggestions as to how this information can be conveyed to the game:
- Setting groups: define a setting group that lists which settings it contains. A setting may be in multiple groups.
- Setting categories: define a setting category and each setting may specify which category it is from.
- Setting hierarchy: each setting may specify a parent setting. An invisible parent will also hide its children.
- Making settings disable-able: the setting's entry will become grayed out and non-interactable based on another setting's value (or an expression, like for visibility).
- Attaching a boolean setting to a non-boolean setting. If collapsible lists are a thing, attaching a boolean setting to such a list.
- Multiple columns. This wasn't really discussed in the aforementioned talk, but it occured to me as I was writing this request. Most of the time the settings window is pretty narrow. Arrange settings in multiple columns to better use screen space. The arrangement will have to consider setting groups (even as they are, by mod) so they don't get split between columns.
- Scripted settings GUI: ultimate customizability. Mods can have a separate file, e.g. settings-control.lua, which runs while the mod settings window is open. It reuses the runtime GUI API to let mods decide how they want their settings to look. __core__ can produce the present layout, so by default mod settings function just like before. This will require a lot of consideration for what game data and interfaces to expose to mods. It may or may not be a lot of work to actually implement, depending on how exactly the game is coded. The "nuclear" option.
