Hotkeys in user.cfg will not set properly

[am2del]

Build: 27 Feb 2017 (18915P-release) installed on Linux, kernel: 4.10.5-1, x86_64 architecture.

When setting hotkeys from within the user.cfg, default hotkeys are overridden properly according to log - however, defined hotkeys are unset in-game.

I.e.: In user.cfg: hotkey.selection.group.select.0 = 0 ...will show properly in log, but in-game "0" will no longer select a group. hotkey.selection.group.select.0 = "A" ...will show properly in log, but neither "A" nor "0" will select no group.

Issue seems to affect ALL hotkeys if set through the user.cfg. Using individual or group paths makes no difference either; i.e.: [hotkey.selection.group.select] 0 = 0 ...will yield same as above examples.

Copy-pasting full set of hotkeys from default.cfg to user.cfg will disable ALL keyboard hotkeys. (Issue does not seem to affect mousebuttons.)

NOTE: Hotkey settings aside, everything seems to work fine through the user.cfg, and since it shows properly in log the issue is likely in the "set clause". I.e. set "A" as hotkey for "hotkey.selection.group.select.0" and log will inform "A" is the hotkey read from user.cfg and properly set, but won't select the group and default key (in this case "0") stops working as well, so it clearly overrides the default without setting new key - or setting "NONE".

EDIT Made ticket easier to read, also posted additional details & information as comment, see: ​#3

[elexis]

Not sure what's wrong with hotkeys in the user.cfg in particular, compared to all other settings. But typically they should go into the local.cfg afaik

[Lionkanzen]

​http://trac.wildfiregames.com/wiki/Manual_Settings

[am2del]

Sorry for not being clear enough in the main ticket section. As the game is in Alpha-stage, I took the liberty of testing "stupid things" users may do in order to see how things are handled. Editing config files, even generated ones, is a fairly common "stupid thing". Making the code capable of handling cases where user added illegal entries, or things which doesn't belong, is a good thing which saves many questions later on.

While a local.cfg exists with hotkeys defined, adding them in user.cfg will do nothing - however for cases where a local.cfg does not exist, or does not contain the specific line in question, adding user.cfg will disable the hotkey dispite logging the hotkey as properly set.

In other words:

1. user.cfg does override default.cfg as it should (if it didn't the file would be pointless).
2. Hotkeys defined in user.cfg will disable default.cfg ones, or define them as NONE/NULL, which it shouldn't - should either ignore them or set them. (Log falsely report them as properly set.)
3. Hotkeys defined in local.cfg will override default.cfg and user.cfg as it should.
4. Game options stored in user.cfg will take priority over local.cfg, which makes sence as user.cfg is generated as user change these in-game.

Ticket issue lies within above "2.", why the hotkeys are disabled if added in user.cfg while same hotkey isn't present in a local.cfg.

Suggested solutions:

• Add "ignore clause" for any settings which shouldn't be present in user.cfg while reading it. (Probably preferred to prevent similar issues occouring due to user intervention, especially as file is overwritten upon changing options in-game.)
• Extend "report clause" to log a warning for the user-defined options which should not be in generated files like user.cfg. (NOTED: Defining illegit keys in config files does report a warning, on-screen and in log, that the key is not recognized - good job!)
• Add, or fix, support for hotkeys in the "set clause" related to reading user.cfg. (Will require an extra "keep-user-defined-items clause" while saving in-game options.)

PS. Side note for anyone reading this who messed with user.cfg: Removing user-defined lines from file, or within game options click "save", will make the hotkeys from default.cfg functional again. (Worst case, restart of the game may be required.)