Preserving settingtypes.txt

ThorfinnS
Member
 
Posts: 221
Joined: Mon Feb 25, 2019 22:05
GitHub: ThorfinnS

Preserving settingtypes.txt

by ThorfinnS » Fri Aug 09, 2019 17:24

Nordal wrote:It's strange to me that your stoneworks is always already enabled. Even if I uninstalled it and unpacked a "fresh" downloaded zip in the mods folder again.

This has bothered me somewhat, too. Particularly those who install from zips, where you get settingtypes.txt overwritten. Also a problem if you don't know what you are doing with git merge, or if you run an AFK update script.

But settingtypes.txt is vastly superior to expecting the end user to modify some .conf file. Or worse, a .lua file.

1. Is there a way to keep your settings from being overwritten?

2. Is there a way to have a different settingtypes.txt associated with each world?
 

neoh4x0r
Member
 
Posts: 70
Joined: Wed Aug 29, 2018 20:16
GitHub: neoh4x0r

Re: Preserving settingtypes.txt

by neoh4x0r » Fri Aug 09, 2019 18:24

Nordal wrote:It's strange to me that your stoneworks is always already enabled. Even if I uninstalled it and unpacked a "fresh" downloaded zip in the mods folder again.

================================================================

I'll assume that it is [Mod] stoneworks [1.2][stoneworks] by TumeniNodes: viewtopic.php?t=14926

(not that it matters, as this applies to all mods)

Mods are enabled per-world, so if a particular mod is always enabled (after having enabled it once in that world).

The line
Code: Select all
load_mod_stoneworks = true


is present in
Code: Select all
<minetest_user_folder>/worlds/<world_name>/world.mt


Also, I'll assume that you are not installing to games/<installed_game>/mods but into <minetest_user_folder>/mods.

If you install directly into games/<installed_game>/mods (then those mods are considered to be required game content
and cannot be disabled and they would also only be available for that particular game).

================================================================

ThorfinnS wrote:This has bothered me somewhat, too. Particularly those who install from zips, where you get settingtypes.txt overwritten.

Also a problem if you don't know what you are doing with git merge, or if you run an AFK update script.

1. Is there a way to keep your settings from being overwritten?
2. Is there a way to have a different settingtypes.txt associated with each world?

================================================================


if [someone doesn't] know what [they] are doing with git merge, then they should not be using git merge -- they should learn how to use it and understand what it does before they use it.
Likewise for an "AFK" update script (ie an automated script)....

These sorts of things should not be done directly on installed content.
For instance you checkout a mod from git and want to update -- git pull and git fetch should be used but it should be done out-of-tree with installed content (eg checkout to a sperate folder, update, and then copy those files over -- never do it over live/production/installed files)
=========

To address both 1 and 2:

That is what is already being done...(you just need to set them up correctly)

Never use settingtypes.txt directly -- these are just the mods default settings.

If a mod uses global settings (ie the settings affect that mod in all worlds) -- they go in minetest.conf

If a mod's settings are per-world (ie the settings affect that mod only in a specific world)
then they go in worlds/<mod_name>_settings.txt **

** note that some specific mod might read them a file other than <mod_name>_settings.txt
In that case you would have to check with the mod author (or look at the .lua files) to get the correct file name.

EG: pipeworks by VannesaE viewtopic.php?f=11&t=2155&start=650
uses per-world settings and they go in worlds/<world_name>/pipeworks_settings.txt

Dynamic liquids by FaceDeer viewtopic.php?f=11&t=16485
uses global settings and they go in minetest.conf

If you configure the settings like that then overwriting settingtypes.txt becomes a non-issue.


PS:
A similar issue happened to me -- with installing and enabling mods and mods packs (I could not disable them and was not shown an enable tickbox).

For the longest time I was installing them to games/minetest_game/mods which (to minetest) meant they were default game content and could not be enabled/disabled (they were always enabled).
Also, it meant that those mods could only be used with minetest_game and no others.....

Then after this went on for a while......I realized that they were supposed to be installed to <minetest_user_folder>/mods (they could be enabled/disabled per-world and used with any installed game).
 

ThorfinnS
Member
 
Posts: 221
Joined: Mon Feb 25, 2019 22:05
GitHub: ThorfinnS

Re: Preserving settingtypes.txt

by ThorfinnS » Fri Aug 09, 2019 19:14

neoh4x0r wrote:
Nordal wrote:It's strange to me that your stoneworks is always already enabled. Even if I uninstalled it and unpacked a "fresh" downloaded zip in the mods folder again.

================================================================

...

The line
Code: Select all
load_mod_stoneworks = true


is present in
Code: Select all
<minetest_user_folder>/worlds/<world_name>/world.mt


Also, I'll assume that you are not installing to games/<installed_game>/mods but into <minetest_user_folder>/mods.

Maybe I should have asked Nordal what he meant by that. Every time I start a new world, all mods are disabled by default, and I have to enable them specifically. If I've updated a mod, and loading an existing world, the mod is in the same on/off state it was when I last configured the world. I couldn't figure out what it meant to always be enabled, but installing in the worlds directory would do it, I guess.

You are correct. I'm assuming everyone is installing in the minetest/mods directory.

neoh4x0r wrote:
ThorfinnS wrote:This has bothered me somewhat, too. Particularly those who install from zips, where you get settingtypes.txt overwritten.

Also a problem if you don't know what you are doing with git merge, or if you run an AFK update script.

1. Is there a way to keep your settings from being overwritten?
2. Is there a way to have a different settingtypes.txt associated with each world?

================================================================

To address both 1 and 2:

That is what is already being done...(you just need to set them up correctly)

Never use settingtypes.txt directly -- these are just the mods default settings.
Hmmm. I don't think that was the question I meant to ask.

When I start minetest and go to the Settings tab, click on the Advanced Settings button, scroll down to Mods and select the mod in question, it brings up a list of settings I can set for that particular mod, defined by what's in settingtypes.txt. But it's global. So far as I can see, you can't tell bell07's compost mod to produce compost:garden soil in some worlds, default:dirt in another. Change it in the Settings tab, it changes it for all current and future worlds. In some cases, this means some inventory items are no longer defined, so you get the blue and pink dummy textures.

Did I miss some manner of setting those things per each individual world? Apart from manually editing files, I mean. Yes, I know how pipeworks and farming redo and cucina vegana all use configuration files you edit, and in the current state of the game, maybe one should expect all users to be coders, but it seems to me the Settings tab is designed to make it possible for each end user to set the game up without risking messing up a config file or worse, a lua file. I don't think an end user should be expected to do anything more than open an options page and click checkboxes. If he's entering anything, that input has to be validated. I'm just not seeing a good way to do it in minetest quite yet. Though I'm pondering doing it through formspecs...

Image
 

neoh4x0r
Member
 
Posts: 70
Joined: Wed Aug 29, 2018 20:16
GitHub: neoh4x0r

Re: Preserving settingtypes.txt

by neoh4x0r » Fri Aug 09, 2019 20:32

ThorfinnS wrote:When I start minetest and go to the Settings tab, click on the Advanced Settings button, scroll down to Mods and select the mod in question, it brings up a list of settings I can set for that particular mod, defined by what's in settingtypes.txt. But it's global.


Yes when changing settings like that -- through the settings menu -- they are assumed to be global (as the world isn't specified).

Code: Select all
The only current solution:
1) don't change individual mod settings from that menu
2) only change settings for minetest itself and installed games
3) manually create and edit per-mod-per-world settings in worlds/<world>/<mod>_settings.txt
4) manually edit minetest.conf to add global mod settings as needed


It honestly sounds like a bug...

In my opinion settingstypes.txt should be eliminated and replaced with global_settingstype.txt and world_settingstypes.txt

Then the settings tab should show:

Code: Select all
+ Mods
   + mod1   
      global_setting1      value
      global_setting2      value
   + mod2
      global_setting1      value
      global_setting2      value
+ Worlds
   +world1
      + Mods
         +mod1
            world_setting1   value
            world_setting2   value
         +mod2
            world_setting1   value
            world_setting2   value
   +world2
      + Mods
         +mod3
            world_setting1   value
            world_setting2   value


Then it only puts the settings that are meant to be global in minetest.conf
and for worlds/world1/mods/etc -- would go into worlds/world1/<modname>_settings.txt

For minetest to grab the currently defined settings for each installed mod in worlds folders it
could simply call some function to load the mod's settings per world.

Again, it sounds like a bug and probably needs to be opened as a bug report.
 

ThorfinnS
Member
 
Posts: 221
Joined: Mon Feb 25, 2019 22:05
GitHub: ThorfinnS

Re: Preserving settingtypes.txt

by ThorfinnS » Fri Aug 09, 2019 21:23

Ideally, I'd like to keep the current settings format to establish global, um, settings, then have something like you are showing to expand the world settings within the Start Game -->Configure pathway. Currently, on that screen, + only applies to modpacks, but I don't know why it couldn't open up game settings, so this particular game can deviate from global settings, and save it in the world directory, like you are talking about.
 


Return to Modding Discussion



Who is online

Users browsing this forum: No registered users and 1 guest