Config options naming

For what's not in 'Top Priority Game Design'. Post your ideas, visions, suggestions for the game, rules, modifications, etc.

Moderator: Oberlus

Post Reply
Message
Author
dbenage-cx
Programmer
Posts: 389
Joined: Sun Feb 14, 2016 12:08 am

Config options naming

#1 Post by dbenage-cx »

Working on changing config options to a common naming scheme.
(TLDR; rework config option names to a consistent style that supports procedural layout, see example at end of post)

Currently the style is all lower case with few underscores and no dashes.

Many of the flags which are not stored in config, were left untouched, such as render-simple.


During initial review, Marcel mentioned naming wrt the Option window.

I've tried to group the options under common parent nodes (delineated by a dot), based on their scope (e.g if it falls under the map window, it becomes a subset of ui.window.map).

Such groups do not align with their containing tab on the Options window (if they are present).

In the majority of cases the options end with a suffix to match the value type (.width / .shown / .path) to assist any potential transition to a procedurally generated options tabs.


Related to such a naming scheme is the --help output. Currently the output needs to be piped to another utility or file to be usable.

I've had a rough idea of allowing a description for a subset of an options nodes. (I've not looked into this idea in detail)

e.g. a stringtable description could be defined for both ui.window.production and ui.window (and then not defined for ui.window.production.fullscreen)

An option of ui.window.production.fullscreen.left_edge would fall under ui.window.production, which in turn falls under ui.window wrt --help

The help output would be changed to show the smallest set of groups requested, a simple --help might be:

Code: Select all

Usage: --help group
setup  -  Options related to game setup values
ui.window  -  Options related to UI windows
misc  -  Miscellaneous ungrouped options
--help ui.window

Code: Select all

ui.window.production  -  Production window settings
ui.window.research  -  Research window settings

A complaint raised by Geoff is many of the option names are difficult to remember.

Some rework is required to shorten the names while retaining common groupings, suggestions on scheme layout is appreciated.

e.g. possibly dropping the ui prefix, and switching to start with the config name:
ui.window.production.fullscreen.width -> production.window.fullscreen.width
ui.window.map.fleet.eta.shown -> map.fleet.eta.shown (note this is not fleet.eta.shown, as the setting is for displaying eta on the map)


Currently the top level nodes are:
audio
content
effects
logging
network
save
setup
ui
version
video

The ui children:
control
description
font
hotkeys
input
name
tooltip
window

(An outdated example config, which I will try to update later)
Any content posted should be considered licensed GNU GPL 2.0 and/or CC-BY-SA 3.0 as appropriate.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Config options naming

#2 Post by Geoff the Medio »

dbenage-cx wrote:A complaint raised by Geoff is many of the option names are difficult to remember.
The "complaint" was just that I'd have to remember something different from what I do now, eg. "--network.server.external.force" instead of "--force-external-server". It's a minor and personal (so not important) issue.
e.g. possibly dropping the ui prefix, and switching to start with the config name:
ui.window.production.fullscreen.width -> production.window.fullscreen.width
ui.window.map.fleet.eta.shown -> map.fleet.eta.shown (note this is not fleet.eta.shown, as the setting is for displaying eta on the map)
I'd drop the window but keep the ui. so
ui.production.fullscreen.width and ui.map.fleet.eta.shown

ui.description.effects.shown -> ui.effects.descriptions.shown

For things like ui.window.map.system.selection_indicator.rpm, why do you still use _ as a separator instead of switching to . consistently? I find the _ more logical in many cases, but having to remember in each case whether a _ or a . is used is problematic, so standardizing on _ everywhere is probably better... But you've kept the _ in seemingly random places, somewhat defeating the purpose...

dbenage-cx
Programmer
Posts: 389
Joined: Sun Feb 14, 2016 12:08 am

Re: Config options naming

#3 Post by dbenage-cx »

I updated the example config with recent changes (branch is not updated), I'll see if I can figure out incorporating a stylesheet for config.xml if readability is a concern.

The recent change removes window from ui.window.*, think a general "ui.windows" could cover the settings not specific to one window.

Incorporated hotkeys into name change, so the hotkey groups any related options (e.g. video.fullscreen.hotkey).
A side effect, the options tab for hotkeys was changed a bit to support any stringtable defined sections.

All of the underscored names were converted, with exception of the logging option for combat_log (logging macro would not currently support combat.log)
Some of these are not ideal, the worst case being the option to hide most of the map window panels/child windows, when displaying production window
ui.production.other_panels.removed -> ui.production.mappanels.removed

dbenage-cx
Programmer
Posts: 389
Joined: Sun Feb 14, 2016 12:08 am

Re: Config options naming

#4 Post by dbenage-cx »

Comparison of most options, should be easier to read (or import into spreadsheet).
This is based on options present in config.xml after brief play and then manually added old options.
Some options may be omitted, and old options could have typos.

User avatar
The Silent One
Graphics
Posts: 1129
Joined: Tue Jul 01, 2003 8:27 pm

Re: Config options naming

#5 Post by The Silent One »

That looks a lot cleaner. Nice work.
If I provided any images, code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0.

dbenage-cx
Programmer
Posts: 389
Joined: Sun Feb 14, 2016 12:08 am

Re: Config options naming

#6 Post by dbenage-cx »

In hindsight, I should have just deleted the stringtables and matched the results from --help ... would have saved a bit of time and less error-prone.

Post Reply