Copy options.txt to user's preferences location about opentesarena HOT 14 CLOSED

A global user-editable config doesn't make sense, since users don't/shouldn't have permission to modify global files. If following the OpenMW style, the global config should just be the config defaults, and users would make user-specific config files to override the default settings.

In Windows terms, you'd install into C:\Program Files\OpenTESArena or something, which includes the executable, config-defaults.txt, and whatever other non-changing files are needed. If the user wants to change an option, they would create/edit something like C:\Users\<username>\Application Data\OpenTESArena\config.txt that has just the settings they want to change (these paths are the typical ones Windows uses; they may be different and there's WinAPI functions to get what they really are). When a user updates, they'd overwrite the files in Program Files (including the config-defaults.txt), leaving their custom settings in Application Data alone.

from opentesarena.

That's a good idea. I've had trouble editing a dosbox.conf before when it was somewhere in Program Files (because of admin privileges), so I know what you're talking about. The Game class should probably have an optionsPath member that points to SDL_GetPrefPath("OpenTESArena", "options") like you suggested.

I should also print the path out in the console since it can be hard to find those places on Windows sometimes (AppData/Local/VirtualStore/...).

Edit: Actually, turns out it's C:/Users/<username>/AppData/Roaming/OrganizationName/AppName/ on Windows.

from opentesarena.

Printing the path to the console is an excellent idea. Perhaps print either that we are copying it over or that it exists and we are reading from that location. In both cases, we would be saying the final location.

from opentesarena.

Looks like Linux might only include the application name in the path, so maybe I need to append "options" to the string returned by SDL_GetPrefPath("OpenTESArena", "OpenTESArena") instead.

Edit: Hmm, maybe the SDL2 documentation is just abbreviated there, so I'm not sure. I'll use it the intended way with arguments "OpenTESArena" and "options".

from opentesarena.

That behavior seems contrary to this patch, which seems to have been applied to the source code. I also found forum posts such as this one, which say that Linux was using both the organization and app name.

/home/bob/.local/share/My Company/My Program Name/

Are we both using the same version of SDL2? I'm using 2.0.5.

from opentesarena.

I'm using SDL 2.0.4, which is from Jan. 2016, so it has that patch in it. No worries then.

from opentesarena.

Hmm, so this is actually causing a problem for the development environment, since 1) Running in Visual Studio, 2) Running debug build, and 3) Running release build all reference the same options.txt, which I don't want.

How would it only look in the SDL_GetPrefPath() when it's running outside of Visual Studio? I'll need to look more into this tomorrow.

Maybe options.txt should be hardcoded in the executable first. It will look in basePath + "options/options.txt" first, and if it doesn't exist there, it looks in optionsPath + "options/options.txt", and if it doesn't exist there either, it's created in the latter directory. This would allow the user to have a local copy that overrides the one in their preferences folder if they want to use it for development purposes, etc..

from opentesarena.

Where would the original be located in this case? I assume we would need to have one in order to copy it somewhere else.

Personally, I like the idea of having my IDE, debug build, and release build all using the same options.txt, but to each their own. I do think that end users shouldn't have to think about where it's located unless they want to enable experimental options not otherwise available in the UI.

from opentesarena.

The original would be generated by the program if no others exist in either a local options folder or in the global options folder through SDL_GetPrefPath(). The program might do a check on the parsed options.txt to verify that it has all the relevant keys and values before the program continues.

One reason for having them separate would be if I want it to start in windowed mode while developing, and to start in fullscreen when running the release build without needing to fiddle with options.txt in between. I might also want the resolution scale lower in debug mode because the software renderer is pretty slow in that case.

People developing OpenTESArena would get their local copy of options/options.txt (that is, it comes with the repository and is copied by CMake), but the release build would not be shipped with one, instead having it be generated if it doesn't exist. This makes a slight dependency between the one generated by the program and the one stored in the repository, but they change infrequently enough that it's not a problem to maintain.

from opentesarena.

The original would be generated by the program if no others exist

We would need to write this code to generate an options file, correct? Right now, it looks like we are using the options.txt file that is distributed with the source, and initially I assumed we would just copy that "template" version to the location. That also saves a bit of awkwardness in that a first time user would have to run the app, let it generate the file, then copy the file where they want it to go.

A possible alternative to an override system would be to have different options.txt files, like options-debug.txt or something, all in the preferences location. That would mean we could check all in the same file location.

from opentesarena.

I've been looking around in OpenMW's code recently, and I'm more comfortable doing it their way now. I plan on changing how options.txt is handled soon.

What should we do in the case where the global options.txt exists but it is older than the one in a new release? Since OpenTESArena is still in early development, we should expect the key-value pairs listed in the file to change frequently, so it needs to be able to handle cases like this.

I'm not sure how OpenMW handles this because I don't see any version numbers in their settings.cfg.

Edit: Turns out OpenMW reads from settings-default.cfg and settings.cfg, the second of which being a global "delta" file where changes from the default are stored. I might consider doing what @kcat suggested and intentionally comment out everything in the options.txt shipped with OpenTESArena, stating at the top that if the user wants to change anything, then they need to uncomment it, and that their changes won't be seen if the global options file already exists.

from opentesarena.

That sounds reasonable. I guess there's no perfect solution to this problem, because it appears that there are trade-offs to each. If we go with your suggestion, then users will need to manually create an options.txt in their AppData/Roaming/OpenTESArena/options folder if they want changes to options before the first time they run the program. This seems a little inconvenient to me, especially for users not familiar with the Local/LocalLow/Roaming folders and things.

In any case, the program will always display the path to the options file(s) it is using, which should always be at least options-default.txt next to the executable, and <username>/AppData/Roaming/OpenTESArena/options/options.txt if there are changes (I'm assuming all users will have at least some changes).

from opentesarena.

If we go with your suggestion, then users will need to manually create an options.txt in their AppData/Roaming/OpenTESArena/options folder if they want changes to options before the first time they run the program.

This is where a GUI configuration app would be useful. They're not the easiest thing to make (I'd recommend trying Qt5 if you want to go for it), but will be greatly appreciated by users regardless of how the config file hierarchy is structured. OpenMW allows modifying some options in its launcher, with talk of adding most/all other settings to it, which needs to be run first anyway to deal with finding (or installing) the actual game's data.

from opentesarena.

This issue is mostly resolved for now with commit 820ea60. The automated creation of an options-changes.txt file before OpenTESArena is run will happen once a wizard is created for the project.

from opentesarena.