Mod configuration options, settingsypes.txt

Sokomine
Member
 
Posts: 3616
Joined: Sun Sep 09, 2012 17:31
GitHub: Sokomine

Mod configuration options, settingsypes.txt

by Sokomine » Wed Dec 20, 2017 22:03

Some of my older mods still use a config.lua file withhin the mod folder. That is far from ideal as players will have to adjust settings whenever a new version comes out. Thus, it seemed that using a settingtypes.txt file and thereby having the mods settings show up in the configuration menu directly in the game did sound promising. However, that did not work as intended. The settings never showed up. This is due to the way I play the game: Mods are not enabled on a per-world basis. Instead, I do have a huge number of subgames which are in essence folders with symlinks to the mods that are needed for that particular subgame/setup. Pretty often that's just mtg + a handful of (diffrent) mods needed for a particular test/development/world.

I wonder if modders and subgame developers are aware of the existence of settingtypes.txt and the situations when it is parsed and when not. Some mods contain the file, but of the real subgames, only MineClone2 seems to provide a settingtypes.txt. Trouble is: In a subgame and even in a modpack, the settingtypes.txt hopeful mods in the subgame/modpack come with are ignored. Subgames are expected to come up with their own version of the file (and summing up all configs in there). Modpacks may hope for a pull request paramat mentionned.

The documentation reads like this:
doc/lua_api.txt, Mod directory structure wrote:### `settingtypes.txt`
A file in the same format as the one in builtin. It will be parsed by the
settings menu and the settings will be displayed in the "Mods" category.


There's no mentionning anywhere that only mods in the regular mods/ folder and no mods in subgames are ever searched for that particular file. It makes some sense to have the subgame developer check all possible configuration values, set fitting ones for the subgame and provide some additional subgame-specific config options. But in order to do so, subgame developers need to be aware of their duty. I somehow doubt that they are.

As this is a bit more complex (which configuration shall be valid? and: where shall the setting be accessible?), I'd like to discuss this here.
A list of my mods can be found here.
 

twoelk
Member
 
Posts: 1257
Joined: Fri Apr 19, 2013 16:19
Location: northern Germany
GitHub: twoelk
IRC: twoelk
In-game: twoelk

Re: Mod configuration options, settingsypes.txt

by twoelk » Thu Dec 21, 2017 16:41

a general "checklist" for modders might be usefull.

It should also contain all the stuff that is beyond pure coding
 

User avatar
Linuxdirk
Member
 
Posts: 1656
Joined: Wed Sep 17, 2014 11:21
Location: Germany
In-game: Linuxdirk

Re: Mod configuration options, settingsypes.txt

by Linuxdirk » Fri Dec 22, 2017 06:15

Sokomine wrote:I wonder if modders and subgame developers are aware of the existence of settingtypes.txt and the situations when it is parsed and when not.

I think we all agree that config.lua and other solutions in individual mods have to die (not update-save, users have to deal with code, code and config are not separated, etc.) and settingtypes.txt HAS to be parsed everywhere (mods, subgames, mods in subgames, modpacks, modpacks in subgames, mods in modpacks, mods in modpacks in subgames - some of them are acutally working) without any exception.

Having an automatism to get the value stored in a settingtypes.txt file if there is no user-set value for the requested option is a nice feature. Yes, local option = minetest.settings:get('mymod_option') or 'default value' works but should be seen as workaround for a missing feature because you have to keep the settingtypes.txt value and the in-code value aligned and you start mixing code and configuration again.

Sokomine wrote:As this is a bit more complex (which configuration shall be valid? and: where shall the setting be accessible?),

It could be displayed like this.

Code: Select all
Subgames
    Subgame Name
        Mod name
            Option 1
            Option 2
            Option 3
        Modpack Name
            Mod name
                Option 1
                Option 2
                Option 3
Mods
    Mod name
        Option 1
        Option 2
        Option 3
    Modpack Name
        Mod name
            Option 1
            Option 2
            Option 3

If a mod is present in a subgame and as an individual mod, the individual mod's configuration should be used if not playing the subgame. If a mod is present in a modpack and as individual mod, the modpack's version is used if the modpack is enabled as a whole, otherwise the individual mod's configuration will be used. Always the most specific configuration is used.
 

User avatar
sorcerykid
Member
 
Posts: 861
Joined: Fri Aug 26, 2016 15:36
Location: Illinois, USA
GitHub: sorcerykid
In-game: Nemo

Re: Mod configuration options, settingsypes.txt

by sorcerykid » Tue Dec 26, 2017 15:06

I think we all agree that config.lua and other solutions in individual mods have to die


It seems, the vast majority of mods that allow for reconfiguration, use config.lua. Whereas other mods actually require editting init.lua itself. So if an alternative standard recommended, then I really hope it can be documented somewhere so that all modders are advised to adhere to that standard.
 

User avatar
rubenwardy
Moderator
 
Posts: 5544
Joined: Tue Jun 12, 2012 18:11
Location: United Kingdom
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
 

User avatar
jas
Member
 
Posts: 263
Joined: Mon Jul 24, 2017 18:15
GitHub: jastevenson303
IRC: jas_
In-game: jas

Re: Mod configuration options, settingsypes.txt

by jas » Tue Dec 26, 2017 15:11

Yes, I noticed this too. If settingtypes.txt is in a mod it works fine if that mod is not part of the sub-game.

If the mod with settingtypes.txt IS in the sub-game, it won't load. Because the settingtypes.txt file in the sub-game root directory takes precedence.
 

User avatar
sorcerykid
Member
 
Posts: 861
Joined: Fri Aug 26, 2016 15:36
Location: Illinois, USA
GitHub: sorcerykid
In-game: Nemo

Re: Mod configuration options, settingsypes.txt

by sorcerykid » Tue Dec 26, 2017 16:03

I guess our experiences differ because I've yet to see any consistent approach for mod configuration. About half of the mods I've downloaded from the WIP subforum use init.lua or config.lua or otherwise incorporate their own configuration file reader (including functions to open and parse the conf file). Only a small handful seem to use minetest.settings_get().

Moreover, I'm not sure I understand the rationale for mod-specific settings being stored in the global minetest.conf file.

If I were to install a CGI script for the Apache Web server, it would be unreasonable to expect that I have to change /etc/apache/httpd.conf in order to configure a script to execute under /var/www/cgi-bin.

I would think that mods should each have their own configuration file that is either subgame or world specific. While settingstypes.txt is a good approach, it doesn't seem to be particularly conducive to editing in my experience (add to the fact, the file extension is quite misleading because that suggests it's an ordinary text file, not a data file.)
 

User avatar
Linuxdirk
Member
 
Posts: 1656
Joined: Wed Sep 17, 2014 11:21
Location: Germany
In-game: Linuxdirk

Re: Mod configuration options, settingsypes.txt

by Linuxdirk » Tue Dec 26, 2017 16:20

sorcerykid wrote:Only a small handful seem to use minetest.settings_get().

And even this is deprecated and should be replaced with using the settings API (minetest.settings:get() replaces minetest:settings_get(), there is more but as always: it lacks documentation/presence).

sorcerykid wrote:While settingstypes.txt is a good approach, it doesn't seem to be particularly conducive to editing in my experience (add to the fact, the file extension is quite misleading because that suggests it's an ordinary text file, not a data file.)

It is a good beginning. Modders can provide configuration options shown to the user in a uniform way within the client (at least in some of the possible locations a mod could be loaded from).

The problems are that settingtypes.txt is not flexible. It does not support translations and there is no way to get the value from settingstypes.txt or the user-set value (if present) without either mixing code with configuration (local the_value = minetest.settings:get('the_option') or 'the default value' in the code) or by creating a function that first checks if a configuration option is set by the user and if not parse settingstypes.txt and retrieve the value from there.
 

User avatar
sorcerykid
Member
 
Posts: 861
Joined: Fri Aug 26, 2016 15:36
Location: Illinois, USA
GitHub: sorcerykid
In-game: Nemo

Re: Mod configuration options, settingsypes.txt

by sorcerykid » Tue Dec 26, 2017 16:37

Thanks for the insight, that is useful information to know.

My primary concern with settingstypes.txt is it seems to be tied into the menu system of Minetest. What about the many server operators that work 100% of the time in a console and their Minetest engine was compiled only as a standalone server, without a GUI?

Two other very important questions, perhaps someone can help me with:

How is multi-dimensional tabular data stored in settingstypes.txt? And what method is used to retrieve such data?

How is multi-dimensional tabular data stored in minetest.conf? And what method is used to retrieve such data?
 

User avatar
Linuxdirk
Member
 
Posts: 1656
Joined: Wed Sep 17, 2014 11:21
Location: Germany
In-game: Linuxdirk

Re: Mod configuration options, settingsypes.txt

by Linuxdirk » Tue Dec 26, 2017 18:53

sorcerykid wrote:What about the many server operators that work 100% of the time in a console and their Minetest engine was compiled only as a standalone server, without a GUI?

Manually read through the file and transfer the options and the desired value to the server’s minetest.conf file. The settingtypes.txt file is very good readable for humans.

sorcerykid wrote:How is multi-dimensional tabular data stored in settingstypes.txt? And what method is used to retrieve such data?

Maybe serialize to JSON before storing it? The file is a minimal key-value store with comments that are parsed, not a database.
 


Return to Feature Discussion



Who is online

Users browsing this forum: No registered users and 1 guest