Configuration and configuration file

[royfalk]

Moved from vegastrike/Assets-Production#135 (comment)

---

@evertvorster :
"Since this is a new venture in settings for Vega Strike, can we agree on a rough list of requirements for the configuration app?

Having the settings app separate from the main application is weird, and counter-intuitive.

Ideally, the game engine should call the settings app on startup.
The settings app should then check to see if there is a valid configuration file.
If there is, check to see that the requested resolution and screen in the configuration file is available.
If it is, and the settings app was just called to check that screen is available for the game to run on, pass that information back to the game engine, together with the requested screen information.

If the configuration file does not exist, or does not have a valid screen configuration anymore, give the user the choice of which screen and resolution to run on, and save that to the config file, then return that information back to the game engine.

Now, you should also be able to call the configuration app from the game menu. When you call it like this, then the configuration app should expose all the configuration options and at the end write that to the configuration file, and return back to the game.

It is my humble opinion that this should be in place before we start porting over each of the settings that is possible with the old settings app. We could then incrementally move over settings that makes sense. There are also quite a few settings in the original configuration file that is not settable in the app, and you needed to modify the configuration file directly. Stuff like assigning keys to buttons on the joystick, which axes does what and so on. That might be a good reach goal for sometime in the future."

[royfalk]

Having the settings app separate from the main application is weird, and counter-intuitive.

I debated this (with myself). Here are the main reasons why I chose to place it in assets:

1. I plan to implement it in python. The engine repo doesn't have a good place for it.
2. We may want different settings apps for different games. Different background, colors, fonts but most important, different settings. WC doesn't have ftl or SPEC. No need then for these to exist.

Ideally, the game engine should call the settings app on startup.
...

Not sure I agree. This complicates the current system a lot.
Right now the game relies on a configuration file to start.Without it, the game will crash with an error.
Ideally, the game should simply fall back to defaults for each setting instead.

Now, you should also be able to call the configuration app from the game menu.

I agree. But this is a lot more complicated for now because the game's GUI is pretty much hard coded. It also means changing the in-memory config as well as the file and handling any other edge cases. For example, changing resolution should change the game resolution in game.

It is my humble opinion that this should be in place before we start porting over each of the settings that is possible with the old settings app.

It wasn't my plan to touch the settings app at all. IIRC, I started with the support for selecting monitors. However, now that I did, I plan to quickly write a replacement and ditch it. The main reason is that the old app is horribly out of date and confusing:

1. Computer sets a whole bunch of other settings.
2. Geometry is probably obsolete and we could all play on 'Extreme Detail'.
3. Same for textures - unlimited.
4. Same for faction textures - "more vram".
5. Same for shaders.
6. Resolution field should be updated with modern resolutions and the minimum should be full-HD or so.
7. Color is always 32bit.
8. Accelerated visual - always on.

[BenjamenMeyer]

Keeping this part of the discussion here:

It is my humble opinion that this should be in place before we start porting over each of the settings that is possible with the old settings app.

It wasn't my plan to touch the settings app at all. IIRC, I started with the support for selecting monitors. However, now that I did, I plan to quickly write a replacement and ditch it. The main reason is that the old app is horribly out of date and confusing:

1. Computer sets a whole bunch of other settings.
2. Geometry is probably obsolete and we could all play on 'Extreme Detail'.
3. Same for textures - unlimited.
4. Same for faction textures - "more vram".
5. Same for shaders.
6. Accelerated visual - always on.

I've actually still found these useful on some of the systems I plan on; not all of them are able to go to the top for performance. That said, we could probably adjust how we do it and certainly adjust defaults. But we should also keep in mind that not everyone is playing on a brand new, always upgraded gaming rig.

6. Resolution field should be updated with modern resolutions and the minimum should be full-HD or so.

This should be informed by querying SDL2 instead of just some random set that is hard-coded.
Also, we should default to a Windows Display, especially as that's what is most useful for debugging. (And yes, I pretty much only play in a windowed display, not full screen.)

7. Color is always 32bit.

Agreed.

[evertvorster]

My reasoning for the game engine calling the settings app is a little along the following lines:

The settings app needs to have code that checks screen resolutions, and what is available. It also needs code to read the config file and hopefully do some error detection and so on.

Rather than implementing that in the engine again, just have the engine ask the settings app for a valid configuration to play from.

So, less duplicating of code. Maybe the vsettings app can have a --check mode that just returns true if the config file is good?
The reason for this is that as monitors are plugged in and out, the display might not be possible anymore, and rather than crashing the game can deal with this situation gracefully.

[BenjamenMeyer]

so I don't think it needs to call the settings app; but it does need to validate the settings are valid in some form.
This might be through an option related to the settings app; but it could easily be done outside of the settings app too.

So ultimately:

• yes, the engine should validate the settings on start-up
• this involves settings that are both related to the engine and a secondary set of settings specific to the game assets.
• if the settings are invalid, then the game should default to some settings (e.g resolution) to get a working UI and then automatically load the settings configuration, ideally highlighting the invalid settings.

[evertvorster]

There are a lot of obsolete options in the settings app, I agree.
Also, the ability to set font size would have been really nice.
In most of the game setting a larger font pitch in vegastrike.config works really well. It is only in the initial menus that seem to have a fixed vertical spacing in pixels and so a larger font overlaps the text on the next line.

[BenjamenMeyer]

Font size will likely need to wait until we can handle that better in the code; but yes we should plan for it. We could put something in now we a value to show it's coming and then just disable it until we can actually do something about it.

[evertvorster]

As per your request, the config.json file needs to be in a place where the user can modify it without system privileges.
In a similar idea to how the vegastrike.config file is treated, the vegastrike.config file that is distributed with Assets is seen as a default configuration file, and if no other copy of this file exists it is used as the game configuration.
The vsettings app has a similar mechanism, where it looks for a user-modified vegastrike.config file. If it fails to find that, it uses the default configuration, and then when the user saves the configuration it is saved in ~/.vegastrike on Linux.

Something similar should exist for config.json to enable changes made to the default configuration to survive when the Assets are refreshed with an upgrade.

[BenjamenMeyer]

So a good pattern for configuration is:

• defaults (typically stored with the game installation)
• system config (e.g /etc, %ProgramDataDir%)
• user config (${HOME}, user profile)

The system should start by loading game defaults, then override with system values, then override again with user values.

Now, for VS the system values are probably not very important so possible we could skip that step; but we should have at least the two steps with the game defaults being something reasonable.

[BenjamenMeyer]

Having the settings app separate from the main application is weird, and counter-intuitive.

I debated this (with myself). Here are the main reasons why I chose to place it in assets:

1. I plan to implement it in python. The engine repo doesn't have a good place for it.
2. We may want different settings apps for different games. Different background, colors, fonts but most important, different settings. WC doesn't have ftl or SPEC. No need then for these to exist.

There should be settings exposed from the game engine, and then contributed to by the game assets.

For the engine itself, we should have a configuration object - libconfig - that deals with all the universal game engine configuration values. This would get exposed to the Python side so that the Game Assets can provide a UI for viewing and setting them. Some can be allowed to be read-only if we don't want them to be set but the game assets need to use them.

I do agree that the Game Assets should own the Settings interface so that it can be skinned to match the game.

[BenjamenMeyer]

Now, you should also be able to call the configuration app from the game menu.

I agree. But this is a lot more complicated for now because the game's GUI is pretty much hard coded. It also means changing the in-memory config as well as the file and handling any other edge cases. For example, changing resolution should change the game resolution in game.

So the game should be able to present the access to the settings menu from the different points:

• main menu
• Base Computer (when landed)
• Ship Computer (when in flight)

Granted the UI stuff is pretty hard-coded right now so let's focus on just getting it to the main menu first with the idea that it'll show up other places in the future, and we can work towards making things more flexible in the process as a long term goal.

[stephengtuggy]

@royfalk have you seen https://github.com/protocolbuffers/protobuf ? It looks like it's written to solve largely the same problem set that you're looking to solve here.

Conceivably, we could write our settings spec in .proto files, then generate code to work with it in C++, Python, and other languages.

[stephengtuggy]

Then there is the hierarchy of which directory locations to look in for the settings files, mission files, etc. That is a complicated tangle that probably deserves a discussion of its own.

[BenjamenMeyer]

So I really don't like protobuf. Too much autogenerated code among other things. it's not something we need and would overly complicate the code to support it

[royfalk]

I think you missed something about my goals. I wanted to only edit the JSON file and have the C++ be auto-generated. Creating a protobuf schema and JSON file is twice the work. vegastrike.config is 1500 lines.

I am aware that by not including a schema (JSON or protobuf), we are losing the ability to enforce correctness. However, my solution isn't the best. It's merely good enough.

As for the order of operations and directory locations, I've been moving away from it and using standard boost and C++ file operations. Assuming root folder is Asset-Production, that should be good enough.

[BenjamenMeyer]

@royfalk I'm generally good with the direction you've been going. Just noting my objection to protobuf.

[stephengtuggy]

OK. protobuf was just an idea. We don't have to go that route.