Project

General

Profile

Feature #4054

[Launcher] Create menu for settings.cfg options

Added by Will Herrmann 6 months ago. Updated 19 days ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Launcher
Target version:
Start date:
08/31/2017
% Done:

100%

Severity:
Normal

Description

Per this forum thread, create a menu much like the Morrowind Code Project's optional settings menu. This would allow fixes and other settings not otherwise accessible in the game's GUI to be enabled without modifying the settings.cfg file manually.

History

#1 Updated by Randy Davin 6 months ago

Amazing idea, would be very neat and nice.

#2 Updated by scrawl . 6 months ago

  • Subject changed from [Launcher] Create MCP-like menu for settings.cfg options to [Launcher] Create menu for settings.cfg options
  • Target version deleted (openmw-1.0)

Going off the comments in the forum thread:

the next step would be to determine what specifically would be in this menu

Any approach of 'let's add this setting and that setting' is going to result in a lot of work as users request more and more of the existing settings to be added. Why not add everything?

I think that it is best to only have the settings here that cannot be controlled in game.

Not sure about this. Going with the idea of completeness above, we should add all settings (ignoring those that already have a dedicated tab in the launcher). We can add a color-coding or checkbox or something to hide 'non-advanced' settings.

Why in the launcher and not in game menu?

Why the launcher? Because it can be implemented sooner and more easily, I should say.

Agreed. Some settings are difficult to apply without a restart, and some might result in inconsistent game-state if you change them mid-play. Also using QT will be easier than using Morrowind UI.

Due to the large number of settings we should really have some way to auto-generate the settings UI from its documentation (or vice-versa, or use some shared definition that generates both). A simple auto-generated UI won't be much better than a glorified text editor, though, so we'll also need some code to make it more usable (grouping settings, editors for different value types, communicating settings that depend upon another, etc.)

One thing I was wondering: should we rename this section "Experimental"? That would make it clear that these are settings that are not fully supported or available in-game.

A disclaimer text is definitely needed. Labeling them 'experimental' is a good start. Another problem is that using bad values can completely break the game and/or severely degrade performance. It would be nice if the GUI protects you against setting 'bad values', but that's not always possible (or only possible by using arbitrary limits, which are also bad). We should ask people to revert settings to the defaults before reporting a bug, to see if it's the result of some bad (or untested) configuration; similar to how we ask to test without mods to see if it's a mod issue.

#3 Updated by Will Herrmann 6 months ago

You know, you could always join us mere mortals in the forum to discuss the topics too ;)

the next step would be to determine what specifically would be in this menu

Any approach of 'let's add this setting and that setting' is going to result in a lot of work as users request more and more of the existing settings to be added. Why not add everything?

I have two concerns. First, I think it's a waste of time and space to add options that are already in the game. For instance, do we really need a checkbox in the Launcher to enabled "Always Use Best Attack"? I envision this as being a temporary measure that will eventually be replaced when we add this stuff in the game (once we solve the localization problem).

Second, there are some options that are just plain useless. Does anybody really want to have settings in the Launcher to manipulate the X and Y coordinates of the inventory menu? I guess technically, those are modifiable in the game as well.

By listing them out, I was hoping to indicate what I thought were the settings that didn't fall into either of those two concerns. Perhaps I should have been more clear of that up front. I fully expect new features that are added to the settings.cfg file to be added to the Launcher, so long as they don't fall into these concerns.

I think that it is best to only have the settings here that cannot be controlled in game.

Not sure about this. Going with the idea of completeness above, we should add all settings (ignoring those that already have a dedicated tab in the launcher). We can add a color-coding or checkbox or something to hide 'non-advanced' settings.

Again, not sure that "Always Use Best Attack" is really worth having in the launcher. I didn't envision dividing things into advanced or non-advanced, but that would be a possibility.

A disclaimer text is definitely needed. Labeling them 'experimental' is a good start.

Some of the settings are more experimental than others though. I think that toggling Always Sneak is pretty safe. […] We should ask people to revert settings to the defaults before reporting a bug, to see if it's the result of some bad (or untested) configuration; similar to how we ask to test without mods to see if it's a mod issue.

How about this: We group the settings into regular ones and "Experimental" ones, Distant Terrain being an example of the latter. That section has the following disclaimer: "These settings are experimental and are not fully supported. Please revert these settings to the default values before submitting bug reports."

Another problem is that using bad values can completely break the game and/or severely degrade performance. It would be nice if the GUI protects you against setting 'bad values', but that's not always possible (or only possible by using arbitrary limits, which are also bad).

In my post on the forums, I tried to communicate what sort of GUI element it would be and if there were any limits. For instance, the screenshot type would be a dropdown that allows for PNG, JPG, or TGA with PNG being the default. I guess the behavior is currently undefined if the user manually set the value to something different. Maybe just reset to the default?

I'm not sure I'm as concerned about arbitrary limits. For the screenshot format example, there are only three valid values, so I don't really see the concern. As for stuff like Exterior Cell Loading Distance (which I suggested being a number spinner ranged 1-5), I had performance in mind for that. I'd hate for it to be something incredibly high (say, 1000) and then people complain that the game is unplayable. If we really did want a freeform value, I figure we can just use a text box.

It sounds like we have an agreement on the rest of your points.

#4 Updated by scrawl . 6 months ago

You know, you could always join us mere mortals in the forum to discuss the topics too ;)

Fair point. I like to use the forum for things that may or may not go anywhere, when a request looks sensible then discussion goes onto bugtracker for more technical discussion.

I think it's a waste of time and space to add options that are already in the game.

In some cases, which settings are available in-game was kind of an arbitrary decision (e.g. for Water, 'reflect actors' and 'texture size' is in-game, but 'small feature culling pixel size' isn't). These settings are very much related, and when you're editing them you might want to see all of them at once for more context.

Does anybody really want to have settings in the Launcher to manipulate the X and Y coordinates of the inventory menu?

Ok, we can certainly skip that one, and the character drop-down (they're not really 'settings' more like saved runtime state and I'm not sure if they should have been in this file to begin with). Better to use a black-list than a white-list of settings though, right?

Again, not sure that "Always Use Best Attack" is really worth having in the launcher

Not going to argue against that, but I think we can argue against making somewhat arbitrary exceptions that make the menu inconsistent.

I think that toggling Always Sneak is pretty safe.

It's not always easy to see potential issues with a setting. As a measure of safety we can look at how long a setting has been available for, how many people use it on a day-to-day basis, etc. But it's true that some of the settings that are not shown in-game aren't actually 'advanced' settings, they just weren't added due to lack of localisation, lack of users or other reasons. So if 'advanced' does not equal 'not available in-game', then do we need to have two separate filtering checkboxes? Would the 'not available in-game' one even be useful? I suspect some of these issues will become more clearer once we have an implementation up and can see what the window will actually look like.

In my post on the forums, I tried to communicate what sort of GUI element it would be and if there were any limits. For instance, the screenshot type would be a dropdown that allows for PNG, JPG, or TGA with PNG being the default.

You're free to compile your OSG with additional support for Derpaderp Image Format (.derp) and select that. There's hardly a use-case to do that though, so... sure, a drop-down is fine here I think.

I guess the behavior is currently undefined if the user manually set the value to something different. Maybe just reset to the default?

I don't think anything should be reset just by launching the configurator. The UI should support displaying an out-of-bounds value (or no value), then revert back to the standard suggestion of values when you click on it.

I'm not sure I'm as concerned about arbitrary limits. For the screenshot format example, there are only three valid values, so I don't really see the concern. As for stuff like Exterior Cell Loading Distance (which I suggested being a number spinner ranged 1-5), I had performance in mind for that. I'd hate for it to be something incredibly high (say, 1000) and then people complain that the game is unplayable. If we really did want a freeform value, I figure we can just use a text box.

But there are legit reasons to use such values, like scenic screenshots, or the user just wants to stress their computer. We shouldn't tell people what to do. The disclaimer at the top (which we need anyway) should be enough to not have people complain about crap performance.

"These settings are experimental and are not fully supported. Please revert these settings to the default values before submitting bug reports."

I would add that you can still report bugs, but should make it clear in the report that you're using said setting(s) (or even better, test which particular setting caused it). As an aside, it would be fun to have a 'bisect' button in the menu that repeatedly launches the game with progressively reverted settings, has you press 'good' or 'bad', until you find the culprit (not just for reporting bugs, but also for 'Help I messed up my settings and don't know what I did, but I still want to keep my other settings').

At this point, I think we have enough material to have someone go ahead and code this feature, we can still make adjustments later.

#5 Updated by Will Herrmann 6 months ago

Fair point. I like to use the forum for things that may or may not go anywhere, when a request looks sensible then discussion goes onto bugtracker for more technical discussion.

Makes sense. I guess the bugtracker is better for technical discussion while the forum is better for extended discussion. So I guess extended technical discussions could go on either?

In some cases, which settings are available in-game was kind of an arbitrary decision (e.g. for Water, 'reflect actors' and 'texture size' is in-game, but 'small feature culling pixel size' isn't). These settings are very much related, and when you're editing them you might want to see all of them at once for more context.

I can see that. Indeed, we already have Fullscreen and Vsync in the launcher despite them being in-game.

Better to use a black-list than a white-list of settings though, right?

Now that I think about it, I think you're right, a black-list is probably better than a white-list in general.

I don't think anything should be reset just by launching the configurator. The UI should support displaying an out-of-bounds value (or no value), then revert back to the standard suggestion of values when you click on it.

Fair enough. For instance, the screenshot would initially show the DerpDerp format, but the dropdown would only show the three expected formats otherwise.

I'm not sure I'm as concerned about arbitrary limits. For the screenshot format example, there are only three valid values, so I don't really see the concern. As for stuff like Exterior Cell Loading Distance (which I suggested being a number spinner ranged 1-5), I had performance in mind for that. I'd hate for it to be something incredibly high (say, 1000) and then people complain that the game is unplayable. If we really did want a freeform value, I figure we can just use a text box.

But there are legit reasons to use such values, like scenic screenshots, or the user just wants to stress their computer. We shouldn't tell people what to do. The disclaimer at the top (which we need anyway) should be enough to not have people complain about crap performance.

I see your point about not wanting to limit people taking scenic screenshots. At the same time, I want to prevent people to be typing in invalid options (e.g. "-5", "banana", or "9999999999999999999999999999999999999999999999999999999999999999"). I think we could probably come to an agreeable number for an upper range for settings (e.g. 9999) and then just have a number spinner than only allows inputs from 1-9999. As you said, that will probably become clearer with a mockup.

I would add that you can still report bugs, but should make it clear in the report that you're using said setting(s) (or even better, test which particular setting caused it).

How about this: "These settings are experimental and are not fully supported. If you are reporting a bug, please indicate which of these settings you have turned on (or better yet, test to see if any particular setting caused it)."

As an aside, it would be fun to have a 'bisect' button in the menu that repeatedly launches the game with progressively reverted settings, has you press 'good' or 'bad', until you find the culprit (not just for reporting bugs, but also for 'Help I messed up my settings and don't know what I did, but I still want to keep my other settings').

File a feature request ;-)

At this point, I think we have enough material to have someone go ahead and code this feature, we can still make adjustments later.

I agree.

#6 Updated by Will Herrmann 26 days ago

  • Assignee set to Will Herrmann

Submitted PR #1603, which provides support for most of these options. I left out those related to Distant Terrain, since there was a lot of disagreement on how to handle that, and I figured it ought to be a separate PR.

#7 Updated by Will Herrmann 26 days ago

  • Status changed from New to Resolved

#8 Updated by Alexei Dobrohotov 26 days ago

  • Target version set to openmw-0.44
  • % Done changed from 0 to 100

#9 Updated by Marc Zinnschlag 19 days ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF