emanuele3d
commented
7 years ago New version of the description - this and other comments on the description iteself will eventually be deleted, to leave the issue clean for further discussions on the subject matter.
With PR #2757 almost being ready to merge, it's time we look at the future of FlexibleConfig.
The currently open PR only deals with the actual implementation of FC, and not the front-end that will be used to display the settings to the user. This will have to be done via NUI, with the correct kind of widget (slider, drop-down list or something else) being displayed based on the characteristics of a particular setting in the FC.
Notice that according to what is specified in #2893 the front-end will have to deal with three types of FCs: one or more engine FCs, storing global settings for Terasology as a whole, any number of module-based FCs, storing global module settings, and saved-games FCs, overriding global engine/module settings in the context of a single saved game.
This aspect also implies a number of visual challenges for the UI, in order to keep the UX as clear as possible. I.e. let's describe a number of scenarios:
Given an engine/module color setting S with a default value "red", the user could:
- leave S set to its global default value "red"
- change S to a global non-default value "blue"
In the context of a saved-game, the user could: A. given scenario 1 set S to a per-saved-game non-default value, say "yellow" B. given scenario 2 restore S to its default global value "red" or set it to an entirely new per-saved-game value, say "green".
The scenarios above suggest that:
- while working on engine/module global settings, the user should be informed if the value of a setting matches an hardcoded default or not and should have an easy way to reset a setting to the hardcoded defaults.
- while working on engine/module per-saved-game settings, the user should be informed if the value of a setting matches an hardcoded default, a different global default or entirely new value. Again we'd need functionality to easily reset the value of the setting to the hardcoded or global defaults. (Potentially we could simplify this second aspect by ignoring hardcoded values and only considering existing global one as a base).
The functionality described above, in its simplest incarnation, could be achieved by providing a checkbox beside each setting with a label "use default" and perhaps a slightly more explanatory tooltip, say: "use hardcoded default (3.14)" in the former case and "use global default (2.71)" in the latter case. When the checkbox is ticked the input widget for a setting (i.e. a slider or a text field) is disabled and assumes the hardcoded or global default value. When the checkbox is not ticked the input widget is enabled and is free to be set by the user.
A more complicated setup, i.e. a pull-down menu, could be required if, in the context of per-saved-game setting, we wish to give the user the choice between an hardcoded default, a global default different from the hardcoded one or the chance to set a new value - perhaps an overkill level of flexibility.
Pinging @eviltak @rzats @emanuele3d @Cervator for feedback and suggestions.
vampcat
With PR #2757 almost being ready to merge, it's time we look at the future of FlexibleConfig.
The currently open PR only deals with the actual implementation of FC, and not the front-end that will be used to display the settings to the user. This will have to be done via NUI, with the correct kind of widget (slider, drop-down list or something else) being displayed based on the characteristics of a particular setting in the FC.
Notice that according to what is specified in #2893 the front-end will have to deal with three types of FCs: one or more engine FCs, storing global settings for Terasology as a whole, any number of module-based FCs, storing global module settings, and saved-games FCs, overriding global engine/module settings in the context of a single saved game.
This aspect also implies a number of visual challenges for the UI, in order to keep the UX as clear as possible. I.e. let's describe a number of scenarios:
A SnowWhite module might allow you to customize the color of the poisoned apple. By default the module developer might have set it to red, but the user could:
In the context of a saved-game, the user could:
The scenarios above suggest that:
The functionality described above, in its simplest incarnation, could be achieved by providing a checkbox beside each setting with a label "use default" and perhaps a slightly more explanatory tooltip, say: "use hardcoded default (3.14)" in the former case and "use global default (2.71)" in the latter case. When the checkbox is ticked the input widget for a setting (i.e. a slider or a text field) is disabled and assumes the hardcoded or global default value. When the checkbox is not ticked the input widget is enabled and is free to be set by the user.
A more complicated setup, i.e. a pull-down menu, could be required if, in the context of per-saved-game setting, we wish to give the user the choice between an hardcoded default, a global default different from the hardcoded one or the chance to set a new value - perhaps an overkill level of flexibility, but it's debatable. The drop-down menu will have the options "Use Factory Default" and "Custom" for global settings, "Use Factory Default", "Use Default" and "Custom" for per-module settings and so on, since it lets the user stop at any given level of the hierachy.
Pinging @eviltak @rzats @emanuele3d @Cervator for feedback and suggestions.