Config/Launcher discussion (or: One guy wants some things)
Posted: 06 Sep 2016, 03:29
There are a few things that I think need discussing about the launcher and config files before 1.0 happens and we have to worry about 'breaking changes'. Some are some worries I have, while others are probably legitimate bugs, and some more things are feature requests. Some or all of this might already be on the issue tracker (if not as an issue, instead as a couple of comments on a tangentially related issue), but things here will interact with each other, so should probably be discussed in the same place.
- Escape characters
A couple of months ago, I did some investigation related to two issues both marked as bugs. I learned some things, and made some changes meaning OpenMW now behaves as follows:- Boost, when loading directory paths, uses '&' as an escape character. This allows paths to contain '"' (the double quotes character, in case that hasn't come out clearly). As an example, to add the directory , one would add
Code: Select all
~/morrowind/mods/The "To be or not to be" mod/DataFiles
with ampersands preceeding the double quotes, and, sticking with the shakesperian theme,Code: Select all
data="~/morrowind/mods/The &"To be or not to be&" mod/DataFiles"
would requireCode: Select all
~/morrowind/mods/Romeo&Juliet/DataFiles
, with ampersands preceeding any ampersands. Currently, this is somewhat weird, (especially for Windows users, as the double quotes charactr is illegal in NTFS, FAT, and anything else Windows properly supports), and isn't documented anywhere.Code: Select all
data="~/morrowind/mods/Romeo&&Juliet/DataFiles"
- Initially, the launcher only counted '#', the hash character, as starting a comment if it was the first non-whitespace character on the line, whereas Boost's Program Options module allowed it to start a comment anywhere, causing issues when loading anything with a '#' in it, such as esp files, data directories, or potentially any string. I 'fixed' this by sneaking and '#' characters which didn't start a line through Boost as an escape sequence. This works fine, but may not serve us perfectly in the future. Also I just realised I never checked if I needed to apply this change to the CS, so that's something I should look at.
Ideally, I think we should decide upon an escape character that can be used anywhere in our config files to trigger the next character to be interpreted as plain text (or the numbers after the escape character to be interpreted as a unicode code point, but I'm not the greatest fan of this, as it makes a lot of things a pain). This should really be decided on before 1.0 hits, as changing the config files to potentially be not backwards or forwards compatible sounds like asking for trouble. We could then use it for file paths so no one has to be confused by an ampersand, to allow a hash to be put in anywhere it's needed, and for any other character which comes along (or that some cautious user decides might break stuff, so they escape it just to be on the safe side). This actually wouldn't be too hard or tedious to get working using the code I added as a base. However, we'd need a little bit of (probably, but not definitely, minor) tweaking to the launcher.
However, it's also possible that I've missed something obvious and everything is fine with the current system after all. I just can't convince myself that this is the case on my own, though. - Boost, when loading directory paths, uses '&' as an escape character. This allows paths to contain '"' (the double quotes character, in case that hasn't come out clearly). As an example, to add the directory
- Adding data directories and BSA archives
Currently, for a user to add these to their game, they have to edit the config files, but to enable or disable plugins, there's a nice GUI that handles it for them. This isn't the most convenient thing in the world, and is worsened by caveats like having to remember to escape ampersands (or potentially do something else if my proposed escape character system is implemented). In my opinion, it would add a lot to the usability of OpenMW (especially while there's no feature-complete mod manager) if a GUI for this was implemented as part of the launcher. As user-facing jobs go, this could be pretty simple and could be attempted by someone who wanted a simple task instead of tackling a long-standing bug or engine feature - they'd essentially be copying the plugin tab as a new data directory tab.
Another possibility to making things simpler for modders would be if someone were to write a plugin for Mod Organizer to make it work with OpenMW. MO already has fancy features like a virtual file system, and has the advantage of allowing traditional tools, like Wrye Mash to be used within the VFS. If it just wrote its data file directory, plugin and archive selection to OpenMW's config file, then everything could 'just work'. - Order of deactivated mods
Quite a number of mod managers I've used (well really just NMM, Wrye *ash and MO) keep track of the position of deativated mods in the mod list, which is really helpful when trying to group optional esps with the non-optional ones from the same mod, or when testing different mods which do the same thing. It probably also has other uses which I can't think of.
This could be added by adding "data-deactivated", "content-deactivated" and "archive-deativated" keys to the config, which the engine would safely ignore, but which the launcher could use to keep track of relative positions. This might be a thing only I want, though. - Probably an actual bug
Finally, I've also noticed that sometimes, when activating esps or adding data directories, comments which I've added in between "data=" and/or "content=" are removed when the launcher loads and resaves the config file. This should probably go on the issue tracker, and I'll try to get around to that once I've remembered exactly what I was doing, and therefore exactly how to reproduce it, but I'm putting it here just on the off-chance that someone will be inspired by this post to do everything it says, as they'll be working on that part of the code anyway.