Add more settings to the pause menu.

[ThomasMonroe314]

Problem

You currently have to leave the subgame you're playing in, in order to change any settings besides the volume and keys. This can get very tedious when you try adjusting any settings to your liking which are more subtle in nature.

It's even worse when joining a heavier subgame with a longer load time, or a server where you have to not only constantly retype your login credentials but also wait for all the media to load.

Solutions

My idea is to take the current sound volume and configure keys buttons and put the volume slider and the keys button into a new menu that is opened by an options button.

The menu could have other settings like FOV and enable/disable clouds and many more could be added.

FOV getting added to the menu might be able to replace #5797 cause a slider to set the FOV is the only use that I can think of for that feature in CSM atm

[paramat]

#5797 is about normal and zoom FOV.
Zoom FOV can no longer be a client setting as explained in that thread.

The menu could have other settings [...] and many more could be added.

Only a few basic settings, for reasons explained here #3818 (comment)

[ThomasMonroe314]

@paramat I understand. The formspec can't be too cluttered and clients can't change their zoom FoV cause of the recent changes. I was thinking mainly of normal FoV, since in order to change it you have to log out and re-log in, it would be nice to have that adjustment easily accessible. And as for clouds and maybe shader controls in the menu that would allow the client to dynamically find the right balance of eyecandy/performance for their machine.

Here is my wish list(will be constantly updated):
This list is not set in stone and needs plenty of input from devs and players.

• fov
• build inside of player
• fog?
• clouds settings?
• show entity selection boxes?
• camera smoothing?
• mouse sensitivity?
• always_fly_fast
• recent_chat_msgs

and here is my TODO list(also going to be updated):

• fov
• build inside of player

[ThomasMonroe314]

@paramat is it okay if I play around with some ideas and post some screenshots to get people's opinions?

[paramat]

Of course, no need to ask me.
One issue with in-game changing of settings is that, for performance reasons, many settings are assumed to be (and are) constant during a game session (to avoid having to repeatedly fetch them from settings), so cannot be changed in-game.

[ThomasMonroe314]

True

[paramat]

Erm, unless they are cached and only changed when reset.

[ThomasMonroe314]

Screenshots will be here(updated constantly):

[paramat]

Do players need to quickly reset 'build inside of player' in-game?
View range is already adjustable in-game with keys.

[TekhnaeRaav]

Ya, view range won't be needed. As for building inside the player I'm not sure, you almost might as well but I don't know how simple you want the menu to be.

[ThomasMonroe314]

yeah I put view range, then realized its unlimited.

[TekhnaeRaav]

Would it be worth it to add any graphics settings? for example: I can run simple leaves real well, but only if I'm not in a jungle then I need opaque leaves.

[ThomasMonroe314]

Building inside of the player is a useful setting IMO because I got a little annoyed that there wasn't a key for it so I had to log out to reset it.

[paramat]

Not leaves settings, that's something you set once according to desired performance.

• shaders on/off?
• particles
• show entity selection boxes
• minimap?

Minimap has a key already. The rest do not have a good reason to be set in-game, so no for all 4.
Your TODO list is missing fog and 3D clouds, both i disagree with.
This issue doesn't seem to have much input, i recommend waiting for more dev input before working on this.
Why add fog when we already have F3 and R keys?
3D clouds is obviously not needed in-game.
There seems to be lack of good judgement here, only settings that have a strong reason for being quickly accessible in-game should be considered.

[ThomasMonroe314]

Yeah, I took away fog and 3d_clouds bcs they didn't need to be in there, and I have already removed them.

This issue doesn't seem to have much input, i recommend waiting for more dev input before working on this.

Ok, makes sense.

[ghost]

Being able to change settings in-game via menu would be very useful, and IMO a great feature addition.

…

On Fri, Jan 26, 2018, 6:07 PM Tre ***@***.***> wrote: Yeah, I took away fog and 3d_clouds bcs they didn't need to be in there, and I have already removed them. This issue doesn't seem to have much input, i recommend waiting for more dev input before working on this. Ok, makes sense. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6722 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWXKYj1Ov-nWXtv-zbWOnLqY2xeNyc2Nks5tOlq0gaJpZM4Qx0Kn> .

[ThomasMonroe314]

@jastevenson303 any suggestions?

[Sokomine]

@paramat:

'enable build where you stand' might be justified if builders need to switch often between those modes while building, @Sokomine

Perhaps. I never felt the desire to disable 'enable build where you stand' as it is very important to me. Others who might profit from it do not even know that the option exists.
Auto jump (step height?) that is/was enabled on Android clients and allows to walk up full blocks without jumping fits into the same category. I can't even remember the name for the setting. Yet it would be something I'd love to be able to turn on and off easily.
Enabling/disabling autorun (Continous forward?) belongs here as well. Needs to be turned on and off while playing, not as a global setting. The key for that also needs to be added to the key settings menu.
-> settings category "game controls"?

Settings that change in my minetest.conf from time to time and would be nice to change even while playing in a world are:

• minimap-settings. Usually disabled to save ressources while developing but wanted on servers.
• language (easy to start with the wrong one; change seldom needed)
• screenW/screenH: indirectly. sometimes minimizing the window in order to check something or to take a smaller screenshot is needed. It is annoying that switiching between two resolutions is no longer working well. Maybe a diffrent issue.
• enable_local_map_saving: beeing able to activate that while playing on a server would be very very welcome. This is easily the most often changed setting in my minetest.conf and a frequent reason for a restart. Could be implemented as a CSM technically but ought to be triggered by a menu setting instead of a CSM command because not only those who follow development closely ought to be able to use it. Maybe a diffrent issue as well but ought to be placed in the same menu.

Changing graphics settings (smooth lighting, waving trees, leaf transparency, filters, ..) might also be of intrest as the effects could be observed immediately and the settings thus be understood. No idea if those can be changed while the game is running.
Clouds are sometimes disruptive on servers with high mountains -> on/off switch welcome

Font and font size are settings which are seldom changed after the player has found settings he/she is comftable with. Yet at first start a too small, too big or otherwise unreadable font may make it close to impossible to play. Might be mixed in with language setting. Sometimes the font i use is too big to read a sign. Using a smaller font would be very tiresome for the eyes. -> increase/decrease font size

It is true that the above two groups (graphics and font/language) are both usually set only once. Still, beeing able to observe the effect without having to restart could help understand what they mean.

Functions on function keys (show hud, chat, debug options, third person view, minimap activation/size, chat console, take screenshot) might be added even though there is already a key for it. Reason: Players can see what is activated. Effects of accidently pressed keys can be undone. Options become available for Android users.

[ghost]

Mouse sensitivity. Cue paramat saying "no". I'll look through and suggest more soon.

…

On Sat, Jan 27, 2018, 12:23 AM Sokomine ***@***.***> wrote: @paramat <https://github.com/paramat>: 'enable build where you stand' might be justified if builders need to switch often between those modes while building, @Sokomine <https://github.com/sokomine> Perhaps. I never felt the desire to disable 'enable build where you stand' as it is very important to me. Others who might profit from it do not even know that the option exists. Auto jump (step height?) that is/was enabled on Android clients and allows to walk up full blocks without jumping fits into the same category. I can't even remember the name for the setting. Yet it would be something I'd love to be able to turn on and off easily. Enabling/disabling autorun (Continous forward?) belongs here as well. Needs to be turned on and off while playing, not as a global setting. The key for that also needs to be added to the key settings menu. -> settings category "game controls"? Settings that change in my minetest.conf from time to time and would be nice to change even while playing in a world are: - minimap-settings. Usually disabled to save ressources while developing but wanted on servers. - language (easy to start with the wrong one; change seldom needed) - screenW/screenH: indirectly. sometimes minimizing the window in order to check something or to take a smaller screenshot is needed. It is annoying that switiching between two resolutions is no longer working well. Maybe a diffrent issue. - enable_local_map_saving: beeing able to activate that while playing on a server would be very very welcome. This is easily the most often changed setting in my minetest.conf and a frequent reason for a restart. Could be implemented as a CSM technically but ought to be triggered by a menu setting instead of a CSM command because not only those who follow development closely ought to be able to use it. Maybe a diffrent issue as well but ought to be placed in the same menu. Changing graphics settings (smooth lighting, waving trees, leaf transparency, filters, ..) might also be of intrest as the effects could be observed immediately and the settings thus be understood. No idea if those can be changed while the game is running. Clouds are sometimes disruptive on servers with high mountains -> on/off switch welcome Font and font size are settings which are seldom changed after the player has found settings he/she is comftable with. Yet at first start a too small, too big or otherwise unreadable font may make it close to impossible to play. Might be mixed in with language setting. Sometimes the font i use is too big to read a sign. Using a smaller font would be very tiresome for the eyes. -> increase/decrease font size It is true that the above two groups (graphics and font/language) are both usually set only once. Still, beeing able to observe the effect without having to restart could help understand what they mean. Functions on function keys (show hud, chat, debug options, third person view, minimap activation/size, chat console, take screenshot) might be added even though there is already a key for it. Reason: Players can see what is activated. Effects of accidently pressed keys can be undone. Options become available for Android users. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6722 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWXKYgu-zNOZtZdDOlE19IPvjipjRUtTks5tOrLYgaJpZM4Qx0Kn> .

[ThomasMonroe314]

@Sokomine Thanks you for all of those nice suggestions! I'll be sure to add many of them to my todo list, though not all of may be implemented.

@jastevenson303 although paramat may not like the idea, I personally don't mind it as many other games have it in their options menu. Also, I do know that @SmallJoker would be for this option.

[TekhnaeRaav]

Not leaves settings, that's something you set once according to desired performance.

I must object to this. Graphics can change(as in my example above), and customizing these setting is much much easier to do in game. Also, why not? The more that's in the menu the better right? Of course there is things that are unnecessary, but only because they are already changeable in game.

[paramat]

@Sokomine
Android auto-jump is actually hardcoded in the engine so is invalid here.

Enabling/disabling autorun (Continous forward?) belongs here as well. Needs to be turned on and off while playing, not as a global setting.

There's a bindable key for that already if wanted in-game.

minimap-settings

Which ones?

Language

That's really not needed in-game and is rarely set wrongly.

screenW/screenH

You can resize the screen by dragging. Resizing the wiindow in-game is not much needed.

Changing graphics settings (smooth lighting, waving trees, leaf transparency, filters, ..) might also be of intrest as the effects could be observed immediately and the settings thus be understood.

I feel that's not enough justification.

Clouds are sometimes disruptive on servers with high mountains -> on/off switch welcome

I feel that's not justified.

Functions on function keys (show hud, chat, debug options, third person view, minimap activation/size, chat console, take screenshot) might be added even though there is already a key for it. Reason: Players can see what is activated.

There are in-game keys already and the argument is weak, text already appears when you use these.

Options become available for Android users.

They should be added to the existing android 'gear icon' menu instead.

What is added needs justification, we can't add things for minor convenience.

[paramat]

jastevenson303

Mouse sensitivity. Cue paramat saying "no".

Actually that may be justified as you need to instantly see the effect, not sure.
Don't be unpleasant, devs say 'no' for good reason.

ThomasMonroe314

I'll be sure to add many of them to my todo list,

You should discuss them first, these need justification.

TekhnaeRaav

customizing these setting is much much easier to do in game.

Of course, but that's not a justification, otherwise we would have all 100-200 settings in pause menu.

Also, why not? The more that's in the menu the better right?

No. I've explained why, many settings don't need to be changeable in-game, and because of the code bloat and extra maintenance it causes. Every setting duplicated outside of advanced settings creates a large amount of formspec work.

/////////////////

Please everyone, there are too many suggestions here with too little justification, think about what few settings have a lot of justification for fast in-game access.
Please think about how this is a FOSS project with a severe lack of dev time, and how MT needs to be kept simple.

[ThomasMonroe314]

@paramat what do you mean by justification?
do you mean giving a good reason, or something else?

[paramat]

Yes sorry, a good reason.

[ClobberXD]

In my opinion, all audiovisuals and input settings should be accessible in-game, as they have the most significant, and not to mention immediate effect on gameplay.

[ClobberXD]

If #6965 isn't going to be taken up again, I'm willing to make an attempt at this too.

To support settings changes on-the-fly, I suggest having a C++-side callback that allows for immediate updating of only the changed settings, like the one in #6965.

[ghost]

Yes, and this practice dates back to Quake. It was a step up from Doom's setup.exe. Circa 1995.

…

On Fri, Dec 7, 2018, 12:39 AM ClobberXD ***@***.***> wrote: If #6965 <#6965> isn't going to be taken up again, I'm willing to make an attempt at this too. To support settings changes on-the-fly, I suggest having a C++-side callback that allows for immediate updating of only the changed settings, like the one in #6965 <#6965>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6722 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWXKYj5v8hiqqIF6VVjCoqhi5XqtB0G2ks5u2f75gaJpZM4Qx0Kn> .

[paramat]

all audiovisuals and input settings should be accessible in-game,

I disagree, it seems ideal but is practically difficult and problematic, as the game is still running. Having many settings requiring a world restart creates performance gains and simplifies code.
Consider that exiting to menu to change a setting is only slightly slower than exiting to the pause menu. Also, very many audiovisual and control settings only need occasional or rare resetting.

So what settings are available in-game needs to be minimised and carefully considered, only a very few need to be in-game.
I don't know why key bindings are in-game as these are things set once and not touched for months. It would be good to remove these to make space for settings that actually need to be there.

[ClobberXD]

Consider that exiting to menu to change a setting is only slightly slower than exiting to the pause menu.

@paramat This is not just about the time taken to change the setting(s). In #7760 I've given an example of why leaving the game (even if just to change a setting) could have negative side-effects:

This is especially pain-staking if leaving the server has significant negative effects. e.g. In CTF, a player's inventory is cleared on rejoin, and if one wants to adjust a setting, they'd have to wait till the match is over, which could occasionally take more than 2 hours.

Leaving or dying would result in the weapons being dropped on the ground, and possibly into enemy's hands. This is just one use-case where on-the-fly settings would be useful.

[paramat]

A significant loss from exiting to menu is rare though, and most players will, and should, have their settings correct before playing in such a critical situation. So a significant loss is a very rare situation.

So on balance for many settings, the performance and simplicity gains from not having it changeable in-game outweigh the very minor benefits. I do agree that a very few settings are probably justified being adjustable in-game.
Stating "all audiovisuals and input settings should be accessible in-game," is a sloppy approach because that doesn't consider what actually needs to be adjustable in-game.

Mouse sensitivity is something that is used as an example, although it is slightly slower to exit to memu to tune the value (you would do this in singleplayer obviously), once a good value is set you don't need to touch it for months/years. So i'm not sure it's justified to be adjustable in-game.

[ghost]

Some setting need fine tuning. Repeated fine tuning. Going back to the menu sucks for this. But I agree it's a balance. Not being able to /set mouse_sensitivty in-game is the worst.

…

On Sat, Dec 8, 2018, 6:34 PM Paramat ***@***.***> wrote: A significant loss from exiting to menu is rare though, and most players will, and should, have their settings correct before playing in such a critical situation. So a significant loss is a very rare situation. So on balance for many settings, the performance and simplicity gains from not having it changeable in-game outweigh the very minor benefits. I do agree that a very few settings are probably justified being adjustable in-game. Stating "all audiovisuals and input settings should be accessible in-game," is a sloppy approach because that doesn't consider what actually needs to be adjustable in-game. Mouse sensitivity is something that is used as an example, although it is slightly slower to exit to memu to tune the value (you would do this in singleplayer obviously), once a good value is set you don't need to touch it for months/years. So i'm not sure it's justified to be adjustable in-game. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6722 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWXKYoiUH1QybgvN-UV3cF0x8hGLxCYvks5u3ExogaJpZM4Qx0Kn> .

[paramat]

1 year bump. Any core dev support? (i'm neutral).

[SmallJoker]

Already three issues were merged into this one because it would be convenient to do fine-tuning in-game. If you close this issue, people will just open a new one with a similar idea. I like this request, although the exact implementation should IMO rather be like a minimal version of the Advanced Settings dialogue.

[ghost]

Many players - including young ones - don't even realize you can adjust the mouse sensitivity via the game, as opposed to the operating system's setting.

If they don't realize this, they likely won't adjust it via the OS. I suggest a new unique issue be created recommending putting the mouse sensitivity setting in-game via a slider.

Also, one adjustment is rarely enough. Repeated adjustments need to be made, as you very rarely ever land on the perfect value the first time. I've mentioned this above, but it bears repeating.

[grorp]

I've spent some time thinking about this issue and a possible implementation:

Why is this important?

Problems caused by the current situation:

• Minor adjustments / fine-tuning require rejoining many times.
• When playing competitive games, changing client settings requires leaving your current round. This can result in losing or not being able to rejoin.
• It's even worse if you're hosting a server from the mainmenu to play with some friends: If you want to change a client setting, you'll have to kick everyone else out.

How can we do it?

Use the existing CSM environment? (iirc that's the approach the author of #14785 tried to get started with)

• CSM is experimental, disabled by default and can be disallowed by servers (and looking at the default value of csm_restriction_flags, they even do by default)
• CSM is an untrusted environment, but the settings menu needs unsafe access (changing arbitrary settings, reading settingtypes.txt from builtin, reading settingtypes.txt of games/mods)
• CSM was never meant to exist as is and may be removed at any time, so we shouldn't build something on top of it
• -> No.

Create a new, separate "trusted mainmenu environment, but in-game" used for the settings menu?

• This seems like the way forward. Thoughts?

Additional considerations

For an in-game settings menu to be really useful, we'll need to implement support for in-game changes for more settings.

• Many settings already support in-game changes.
• Many settings are missing callbacks for in-game change support. Some of these can be implemented easily, some are more complicated (e.g. shader settings would need shader recompilation).
• Some settings are incompatible with in-game changes in general, we need a way to declare that in settingtypes.txt.
• This should be done in later PRs to keep scope reasonable.

We'll need to distinguish client-side and server-side settings.

• Client-side settings: These always make sense to change in-game.
• Server-side settings (including mod/game settings): These only make sense to change in-game if you're in singleplayer / hosting a server from the mainmenu.
• -> We need a way to declare the "side" of settings in settingtypes.txt?
• Crazy idea: Allow remote servers to provide settings for the menu too (very far future, but seems desirable).
• This should be done in later PRs to keep scope reasonable.

[Desour]

Good suggestions!

Create a new, separate "trusted mainmenu environment, but in-game" used for the settings menu?

• This seems like the way forward. Thoughts?

So a lua env that drives the pause menu (hmm, pmcsm)? The menu would come from builtin, if we also allow users to add mods to it, we get something I thought of as client-settings csm (cscsm): A modding env that the user uses for freely programmable advanced config.

Needful to say, this modding env needs to be restricted in the kind of information it gets, to avoid cheating. If you have an on_globalstep for example, you can easily make an autoclicker (assuming the modding env can set keybinds). Or if you have access to the player position, you can make the player walk exactly to the edge of a node. Hence, the cpcsm we have now is unsuited.
(We could also make it so that the server can decide which information to give to the pmcsm/cscsm, e.g. via an ipc channel from sscsm to cscsm, in the far future.)

• -> We need a way to declare the "side" of settings in settingtypes.txt?

Ideally we should've made the distinction clearer much earlier already. E.g. by prefixing the names (server_foo, client_bar).
There are probably even some settings that both the server and the client use.

[y5nw]

Create a new, separate "trusted mainmenu environment, but in-game" used for the settings menu?

• This seems like the way forward. Thoughts?

So a lua env that drives the pause menu (hmm, pmcsm)? The menu would come from builtin, if we also allow users to add mods to it, we get something I thought of as client-settings csm (cscsm): A modding env that the user uses for freely programmable advanced config.

While I do agree on having a separate environment for the pause menu, what would be a usecase for user-programmable CSMs in such an environment though (especially given that it will likely be constrained)?

(assuming the modding env can set keybinds)

It should be able to set keybindings. Then we can follow/replace #15152 with a Lua-side form for configuring keybindings.

• -> We need a way to declare the "side" of settings in settingtypes.txt?

How about using # Requires: in the settingtypes for this? The settings form would then show all settings when opened from the main menu but only client-related settings if it is opened from the pause menu. Server-related settings can still be shown if the client is running in singleplayer or a server launched from the main menu.

• Some settings are incompatible with in-game changes in general, we need a way to declare that in settingtypes.txt.

This can also be implemented in a way similar to above with e.g. Requires: mainmenu.

• Crazy idea: Allow remote servers to provide settings for the menu too (very far future, but seems desirable).

With #12488 in mind this might not be very far off in the future.

[Desour]

While I do agree on having a separate environment for the pause menu, what would be a usecase for user-programmable CSMs in such an environment though (especially given that it will likely be constrained)?

Arbitrary key binds. E.g. press a key to en/disable autojump (or change any other setting), or press a key to switch between two different key bind layouts, or move your joystick in a specific direction and press a key to trigger some action. Some more restrictive, specialized language could probably also solve the issue, but throwing lua at it is easier, for both us to implement and maintain and for the user to learn, and a specialized language might end up being too restrictive to cover all users' wishes.