settingstypes.txt does not produce GUI elements though code seems to be there

[Poikilos]

Where is missing "Mods" category in advanced settings (:edit: category is called "Games," with subcategory being game name upstream)? The code seems to be there: https://github.com/minetest/minetest/blob/ae1caba6aaa6f0a13e70f195f371fd4e7a378491/builtin/mainmenu/dlg_settings_advanced.lua

wget https://github.com/minetest/minetest/raw/ae1caba6aaa6f0a13e70f195f371fd4e7a378491/builtin/mainmenu/dlg_settings_advanced.lua

:edit: Now that I think about it, the mod settings should be in the world settings (possible now with Final Minetest's world.conf). Minetest.net's decision to have these settings included in the global settings part of the menu GUI doesn't make much sense (changing the global settings after using a single player world could lead to missing nodes and other issues in that world).

• Instead of a "Configure" button, the world should have a "Mods" button and "Settings" button. The "Mods" button would replace "Configure," and the "Settings" button would change mod-defined settings
• Mod-defined settings are in the settings["Mods"] table and settings["Games"][worldgame] table (where worldgame is the game the world uses) that is generated from settingtypes.txt files in various mods (can also be in game directory).
  • The table should be updated after enabling a mod (?)

[slopsbucket]

I think the trigger for the code needs to be listed the the game itself. That's why you get all the settings available in the upstream version of game but not in ours.

This was also an issue discussed with OldCoder a long time back, he doesn't understand the importance of that gui menu.

[Poikilos]

Maybe I could take a look at the related C++ code later this week and submit a pull request.

[Poikilos]

@OldCoder @slopsbucket Short-term idea: maybe add a button in the world Configure menu to "Use Game Settings" then confirm to overwrite world.conf with game.conf as determined Advanced menu (after reimplementing "Mods" and "Games" categories there). Doing the same action (copying game.conf to world.conf) on world creation may also be a good idea. Any thoughts?

[slopsbucket]

That's not a silly idea. The power that world.conf gives people is not to be taken lightly, for hosts wanting to serve different types of game, and similarly for teachers in an edutech environment where they want different lessons set up for different age groups.

But most would be a lot more comfortable doing this through a GUI panel.

[slopsbucket]

Another thought to go with that, a decent and easy to follow GUI panel would save us from having to write out many many pages of documentation. This stuff just makes obvious sense in a GUI.

It needs to get it's settings from world.conf first, or create one if not already available.

It needs to list every available option that can be included in world.conf, that's almost every option that's available, there's only a couple that need to be set globally and I think OldCoder could fix some of those for us too. That's a very long page.

Most options are only booleans, the ones with numerical options such as dayspeed could be limited here by only allowing more logical ranges to be entered. This could always be overridden by manually editing the world,conf file.

Food for thought.