In-game settings menu using separate Lua env

[grorp]

Closes #6722

With this PR, users can access the settings menu via the pause menu, making it possible to change settings in-game.

settings.in-game.mp4

I've outlined this PR's approach in #6722 (comment)

This PR is, from a technical perspective, unrelated to rollerozxa's POC or PR #14785. These patches (ab)use the CSM API, this PR does it the proper way by introducing a separate Lua environment (see comment linked above for reasoning).

High level overview of scripting changes

• New PauseMenuScripting owned by GameFormSpec (thanks for the nice refactor, cx384)

• cpp_api:

  • New ScriptApiPauseMenu: functions exclusive to PauseMenuScripting
  • New ScriptApiClientCommon: functions shared between ClientScripting and PauseMenuScripting (code moved from ScriptApiClient)

• lua_api:

  • New ModApiPauseMenu: functions exclusive to PauseMenuScripting
  • New ModApiClientCommon: functions shared between ClientScripting and PauseMenuScripting (code moved from ModApiClient)
  • New ModApiMenuCommon: functions shared between MainMenuScripting and PauseMenuScripting (code moved from ModApiMainMenu)

To do

This PR is a Ready for Review. When reviewing, please pay special attention to the security stuff.

Things this PR will not do, as described in #6722 (comment):

• Make more settings actually support in-game changes (registerChangedCallback)
• Make it clear which settings are server-side and which are client-side in settingtypes.txt, don't show server-side settings if playing on a remote server
• Make it clear which settings support in-game changes in settingtypes.txt

These are big tasks on their own and are left for future PRs to keep the scope of this one reasonable.

How to test

Open the pause menu, click "Settings" and enjoy :)

Additional testing:

1. Settings menu must still work in the mainmenu
2. CSM must still work (you can try the .help command)

[grorp]

The button for changing key bindings being called "Controls" doesn't make much sense.

To change key bindings, you have to navigate to "Controls / Keyboard and Mouse" -> "Controls". Calling that button "Key bindings" or something would make more sense.

(This PR replaces the "Controls" entry in the pause menu with the "Settings" entry, since there's not enough space for both and the "Controls" entry is now redundant. It would be possible to replace the "Sound Volume" entry instead of the "Controls" entry if desired.)

[y5nw]

To change key bindings, you have to navigate to "Controls / Keyboard and Mouse" -> "Controls". Calling that button "Key bindings" or something would make more sense.

I'm thinking about porting #15152 to Lua as a followup for this PR. Then we will be able to embed the entire keybinding form into the settings form.

[nerzhul]

it's a good idea, but if i'm correct some settings won't apply when game is launched. I don't think we have notice for those specific cached settings

[grorp]

it's a good idea, but if i'm correct some settings won't apply when game is launched. I don't think we have notice for those specific cached settings

See #6722 (comment) linked above, specifically this section:

[...]

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.

[...]

[Desour]

Looks good. 👍

Tested, works nicely!

The fps unfocused should probably only be used if the window is actually unfocused.

Nitpick: Should the back button be a close button, because it closes the pause menu completely?

Other parts of the pause menu do use formspec prepend. Disabling it for now because of security risks is reasonable, but we should at some point think about filtering it or something.
Speaking of which, the main pause menu (or how should I call it? x)) still has formspec prepend. This might be dangerous.

[grorp]

The fps unfocused should probably only be used if the window is actually unfocused.

Indeed. See also #13780. While this is a trivial change from a technical perspective, I don't want to make it in this PR because I imagine it may result in additional discussion later.

Nitpick: Should the back button be a close button, because it closes the pause menu completely?

Changing the button label to something like "Exit" would make sense.

Other parts of the pause menu do use formspec prepend.

"Other parts"? Only the main pause menu formspec, other sub-menus are implemented in raw Irrlicht GUI.

Disabling it for now because of security risks is reasonable, but we should at some point think about filtering it or something.

If (the current implementation of) formspec prepend was allowed on the settings formspec, you could probably use it to completely replace the formspec (container, syntax error) and add a button and some hidden fields. Then if the user clicks the button, the settings menu will handle the input, allowing you to set arbitrary settings.

Speaking of which, the main pause menu (or how should I call it? x)) still has formspec prepend. This might be dangerous.

The main pause menu input handler isn't as powerful as the settings menu input handler, I don't see how. You could prevent the user from exiting the game or something (Alt+F4 still exists), but otherwise ...?

[Desour]

Other parts of the pause menu do use formspec prepend.

"Other parts"? Only the main pause menu formspec, other sub-menus are implemented in raw Irrlicht GUI.

Oh right, it's only the main pause menu.

Speaking of which, the main pause menu (or how should I call it? x)) still has formspec prepend. This might be dangerous.

The main pause menu input handler isn't as powerful as the settings menu input handler, I don't see how. You could prevent the user from exiting the game or something (Alt+F4 still exists), but otherwise ...?

It could show a fake main menu and grab passwords, see also #12067. But yes, right now it's not a big issue.
However, if in future the main pause menu is also implemented in lua, it might be different.
(Or maybe it will never be an issue because formspec prepend can't influence the formname. 🤷)

[Desour]

Thanks! <3

(Funnily, the "Exit" button is still translated to "Zurück" in our german translation.)