* Squashed the commits on GitHub into a single commit
on a new branch.
* The binary config file SDLPoP.cfg is now also ignored if the CRC-32 of the prince executable changes (ensuring that we don't ever need to worry about the danger of the config file being exchanged between different versions of SDLPoP).
* Menu can now also be navigated using the left analog stick on a controller (instead of only the D-pad).
* Changed Ctrl+M keystroke for opening the menu to Backspace (because that is already usable for closing the menu, I thought this made sense?)
* Suppressed repeated keystrokes for Escape/Backspace when entering or exiting the menu (which would cause rapid pausing and unpausing of the game)
* Updated ChangeLog.txt
* Updated Readme.txt with some very minimal mention of the menu (the keybindings, and how to enable/disable bug fixes). Maybe more explanation is needed, I don't know.
* Refactor: added a macro NAMES_LIST() for declaring and initializing name_list_type structs.
* Other minor stuff (some cleanup and refactoring).
I'll post a test build so people can try it out.
Should the menu be enabled or disabled by default?
If it's enabled by default, people will be able to discover/stumble upon it by pressing escape. That may encourage people to try out the various possibilities that SDLPoP has to offer, even those people who wouldn't normally touch the configuration file (e.g., because they just want to play the game, or because they are playing on a console platform).
I expect there will still be bugs or unexpected behavior with mods, and replays to a lesser extent. I haven't done enough testing to know for sure.
In particular, it's probably necessary to make sure that mod-specific customizations will not interfere with settings changed by the user, and vice versa.
Right now, if you load a mod that has custom options in a mod.ini file, I think the menu system would (blindly) follow whatever was configured in mod.ini. Then, if you change any setting and close the menu again, SDLPoP.cfg would get saved with those modified settings applied. Then, if you switch to another mod that doesn't override any settings using mod.ini, those settings from the other mod will still linger.
(Hey, come to think of it, actually that is not a problem as long as you cannot switch between mods using the menu. Right now, you can only switch to another mod by editing SDLPoP.ini, which would reset all in-game settings anyway.)
(Follow-up thought: wait, actually, you can switch to another mod without editing SDLPoP.ini, by passing the mod as a command-line parameter. So it would be possible for the problem described above to occur.)
Maybe settings should have a variable attached to them that tracks whether they are managed/owned by the mod, or by the global configuration. And then that variable would determine whether the setting gets saved in SDLPoP.cfg, or not.
Need to think about it some more.
I'd say the menu is now ready as a 'beta' feature, but maybe not ready for merging into the main branch, mainly because of the issues described above.
My own thoughts on the possibility of including it in v1.18:
* Maybe David will want to reject the menu proposal, or maybe he will require large revisions before he will accept it. If so, it should of course not be included.
* If David wants to accept the menu proposal (or with minor revisions), but also wants to release quickly, then it's maybe best to defer the menu until the next version.
* If David wants to try to include the menu in v1.18, and if a delay of the release is acceptable, then I could try my best to quickly address the mod.ini problem described above, as well as any other issues that may still be discovered. Depending on how that works out, David could then decide whether to merge or not before releasing the new version.
Attached test build.