minetest.settings

[Kilarin]

I want to set a value for a mod used by a game, from the GAME.
Example, my not very well developed yet game fractured uses the mod realms. I want the game, fractured, to set a setting that will change the way realms works. BUT, I don't want to put this change into the realms mod folder, because that would mean that every update of realms would require careful merging or I would wipe out my fractured changes.

So, I could use minetest.settings:set() BUT, if fractured depends on realms, realms is going to load FIRST, and the modified settings won't be there. And I don't want to modify realms to depend upon fractured (that would, again, require game specific changes in the mod specific folder) And if neither one depends on the other, who knows what order they will run in.

How can I guarantee that game settings will be loaded before any mods run?
It is a security violation to try and get to the game folder.

If there is some way to do this using minetest.settings, GREAT!

If not, I would like to propose that, in addition to the mods folder, games have a config folder. Within that config folder a game can create a sub folder for any mod. (so, for example, config/realms) And every mod can use get_config_path("modname") to reference that folder. This would allow games to create settings for mods, WITHOUT having to customize the mod itself. Settings that would never be overwritten when updating to a newer version of the mod.

[ShadMOrdre]

Kilarin,

First, the settingtypes.txt file in the game folder, can set the value, via the main menu game settings. This essentially writes the value to minetest.conf. Now that the value, and thus the setting, is in minetest.conf, a simple minetest.settings:get call should work, either in the game control mod, or realms. Mod loading order should, and is, irrelevant, because this setting is set in the main menu, and not set by a mod.

Dependencies should not be a factor in the above, because again, the setting is not set from a mod, but from the main menu.

If you are looking to tailor a specific behavior in a manner where the above will not work, then mod dependencies are unavoidable. Think, in MTG, default is the mod that essentially provides the "game" setup, providing nodes for mapgen, basic player options (before this was moved to player_api), and other basic ingredients essential for MTG to function, and most importantly, reading the settings from minetest.conf that configure the mods, and thus the game. One could basically strip all the mods from MTG, sans default, and still play a usable something.

In your scenario, the Fractured game also has a basic mod, somewhere in games/Fractured that provides the game functionality. You should be able to simply add the setting you looking to add to the settingtypes.txt to the game folder of Fractured, and read this setting in the "game" controlling mod, altering it's behavior independently of how the setting affects the realms mod.

Shad

[Kilarin]

First, the settingtypes.txt file in the game folder, can set the value, via the main menu game settings.

Huzzah! I didn't realize I could have a settingtypes.txt in the game folder. Wonderful, that is EXACTLY what I needed. Will test, thank you.

[Kilarin]

https://dev.minetest.net/Settings
As of 5.0.0, while option value is not set by player manually, settings interface will show default value from settingtypes.txt but minetest.settings:get will return nil.

<sigh> Argh, ran into this. Well, hopefully this bug will be fixed soon.

AND, even after it is fixed, I can set a customized name for the realms config file, which is good, but I still can't get to the game folder.

Even with a customized name, I don't really like having the customized config file in the realms mod folder. I think what I will do, since I can't get to the game folder itself, is create a setting that specifies a mod that holds the realms.conf file. That way I can have the game dictate that the customized realms.conf is in the fractured mod for the fractured game. Which makes sense. And updates to realms can be done without requiring any kind of merge.

once the settings bug is fixed, that is.

Of course, I suppose another option is to just automatically check for a realmsconfig mod and get the realms.conf file from there if it exists? I'll have to experiment with that, not sure if I like the idea or not.

[ShadMOrdre]

Kilarin,

Sorry, I omitted a key understanding about this functionality.

In your code, where you read from settings, you should use somethink akin to this:

Code: Select all

local setting_val = minetest.settings:get("your_setting_from_game_settingtypes_txt") or default_setting_value

This is to accommodate those instances where a user has not configured the game via the built in menu. This also works for mod specific settingtypes.txt values, for when a user has not configured a mod.

[Kilarin]

Unless I've misunderstood you, I'm doing exactly that:

fractured game folder settingtypes.txt

Code: Select all

realms_config (Realms Config File) string realmsfrac.conf

realms code:

Code: Select all

local filename = minetest.settings:get("realms_config") or "realms.conf"

And the result is EXACTLY as described in the minetest developer wiki here: https://dev.minetest.net/Settings
under Bugs and Caveats

Code: Select all

As of 5.0.0, while option value is not set by player manually, settings interface will show default value from settingtypes.txt but minetest.settings:get will return nil.

-- Value is NOT set by player through the settings interface.
print(minetest.settings:get("mymod.untouched_value")) -- Will print "nil".
-- Value is set by player through the settings interface.
print(minetest.settings:get("mymod.touched_value")) -- Will print actual value.

That means you can't simply rely on default value from settingtypes.txt and this code could result in ModError: 

It appears in the settings interface correctly, BUT, if the user has not touched that setting, then settings:get returns nil. As soon as the user has touched the setting, then settings:get returns the correct value.

[ShadMOrdre]

Kilarin,

specify the full path to the default value of "realms.conf". You just supply the file name..

In settingtypes.txt. This can appear in both the game and mod settingtypes.txt, with minetest.settings reading the "global" value. You can alter the value of this in each file, as long as your code determines the appropriate value to take, if they are different.

Code: Select all

realms_config (Realms Config File) string realmsfrac.conf

In your code, instead of:

Code: Select all

local filename = minetest.settings:get("realms_config") or "realms.conf"

Try:

Code: Select all

local modpath = minetest.get_modpath(minetest.get_current_modname())

local filename = minetest.settings:get("realms_config") or modpath .. "realms.conf"

The trick begins if you are trying to use different realms.conf files, one from the game folder, and one from the mod folder. If this is the case, then realms.conf should be reconfigured/rewritten, to use the settingtypes.txt method of configuration. In this way, the game can set values that are different than the mod. If the game is present, the default values are set by it, and your mod only sets those values if they are not already set, which would make them nil. So in the mod, if setting is nil, only then does the mod set the setting.

[Kilarin]

specify the full path to the default value of "realms.conf". You just supply the file name.

I can specify the full path using minetest.get_modpath(), or minetest.get_worldpath() (which isn't helpful to me)
Is there a minetest funciton that will return the game folder path? I haven't been able to find one.
and, I can't hardcode the path, because it will, of course, be different on different systems. Trying to use get_modpath("realms").."/../.." results in a security violation, as it should.

Sorry, I'm not trying to be obtuse, I'm just that way naturally.

[ShadMOrdre]

Kilarin,

Sorry, I was editing above post. Please reread.

[ShadMOrdre]

Another suggestion, is to use the lua_api.txt file in the minetest/docs folder, instead of the wiki. The wiki is not up to date, and some core devs consider it non official.

[ShadMOrdre]

A separate thought, regarding minetest.get_worldpath().

In earlier versions, this was a common way to set game wide settings. Some mods use the world folder to keep world specific settings. So not totally useless.

The preferred method now is to use the game settingtypes, and or mod settingtypes files to make settings.

minetest.settings:get only reads from minetest.conf. If the setting value does not exist in minetest.conf, it must be hard coded into the code, which is probably good programming practice to begin with. The only way that settings get written into minetest.conf, is if the user of each running instance of minetest manually alters those settings in the main menu, or copies a minetest.conf file with those settings included. It is because of this, that the default value should be hard coded.

[rubenwardy]

You can use a minetest.conf file in the game's root to provide settings

[Kilarin]

Thanks for all the input folks, I'll hopefully get some time to play with this again soon!

[Kilarin]

You can use a minetest.conf file in the game's root to provide settings

got a few minutes to test this today. Even when using minetest.conf to set a variable, I still run into <this bug>

A variable set in minetest.conf or settingstypes.txt like this:

Code: Select all

realms_configpathmod (Realms Config Path) string "fractured"

will show up in in the settings menu in minetest:


but in the code, minetest.settings:get

Code: Select all

local configpathmod=minetest.settings:get("realms_configpathmod") or "realms"

will return nil

UNTIL you have touched that value in the settings menu. Then minetest.settings:get picks it up just fine.

So, unless I'm doing something wrong (which is certainly a possibility) you can not currently use minetest.conf or settingtypes.txt in the game folder to create default settings.

Actually, the settings in my minetest.conf in the games root folder don't seem to be picked up at ALL.

[rubenwardy]

So, unless I'm doing something wrong (which is certainly a possibility) you can not currently use minetest.conf or settingtypes.txt in the game folder to create default settings.

Using minetest.conf works for me. I use it for CTF: https://github.com/MT-CTF/capturethefla ... etest.conf

settingtypes.txt is only used for the advanced settings menu. It cannot be used to set default values. Support for this may be added in the future, though.

[Kilarin]

thank you for the example. I'll dig through it and see what I'm doing wrong.

[Kilarin]

DUH! It was me being an idiot again.
I just copied my setting over from settingtypes.txt to minetest.conf. minetest.conf cant use that format, it just uses variablename=value.
Thank you very much!

One warning for other people playing with this. Once you have set a variable using the settings menu, it gets written into .minetest/minetest.conf
and it STAYS there.
deleting it from settingtypes.txt does NOT get rid of it, and it will override any settings in your games minetest.conf.
So if you set something, and change your mind and remove it from settingtypes.conf, you have to go into .minetest/minetest.conf and delete it by hand.