Comments (14)
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.
Related Issues (20)
- Improving first-time contributor experience on Windows HOT 1
- Software renderer redesign for 0.15.0 HOT 7
- A Question about the capablities of OpenTESAreana HOT 1
- Is this still being worked on? HOT 2
- Fan translations support and improved .EXE unpacking HOT 11
- Hit Chance Calculation. Clarification/Verification requested for wiki HOT 1
- Is external MIDI supported? HOT 1
- Switch to GitHub Actions HOT 4
- C++20 HOT 3
- Change Travis CI badge in Readme to GitHub Actions HOT 2
- Locate player's Arena install in Steam HOT 9
- Mysterious performance hiccup every ~3 seconds HOT 1
- Job system HOT 1
- Very slow performance HOT 6
- -march=native not supported on Apple M1 HOT 3
- Game world palette documentation HOT 11
- Triangle clipping improvement HOT 1
- Revise Readme to prioritize obtaining game files from Steam HOT 4
- Couldn't find: options-default.txt if path contains accented characters HOT 2
- "couldn't init game distance. closing HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opentesarena.