Mods that use default have to depend on default in mod.conf

[Blockhead]

Hi all,

Not (my) problem any more but I'm leaving this here for reference since I couldn't find it by searching around.

I was trying to fix advtrains_train_rocket. It was giving weird errors like:

Code: Select all

021-07-05 22:13:11: ERROR[Main]: ModError: Failed to load and run script from F:\Non-installs\minetest-5.4.0-win64\bin\..\mods\advtrains_train_rocket\init.lua:
2021-07-05 22:13:11: ERROR[Main]: ...-5.4.0-win64\bin\..\mods\advtrains_train_rocket\init.lua:144: attempt to index global 'default' (a nil value)
2021-07-05 22:13:11: ERROR[Main]: stack traceback:
2021-07-05 22:13:11: ERROR[Main]: 	...-5.4.0-win64\bin\..\mods\advtrains_train_rocket\init.lua:144: in main chunk
2021-07-05 22:13:11: ERROR[Main]: Check debug.txt for details.
2021-07-05 22:13:11: ACTION[Main]: Server: Shutting down

Weirdly enough, enabling mesecons fixed it. I thought that was a bit odd. Well, as it turned out, if your mod is running on its own and it doesn't depend on default in its mod.conf, it seems to act like default doesn't exist. However, if you have any other mod enabled that depends on default, the error goes away!

I do like it in principle that it makes you fix your dependencies but I don't like in practice how it doesn't tell you why it's happening. It's subtle - default should be there - after all, I'm playing minetest_game. Maybe this is why it gets confused and instead of telling you you're missing dependencies, it throws itself into this exception..

Relevant commit that fixed the problem for reference.

[Linuxdirk]

Despite the name "default" the mod is nothing special. It's just huuuge. So when you use features provided by "default" in your mod, the mod needs to depend on "default" like it needs to depend on every other mod whose features it uses.

[Blockhead]

Despite the name "default" the mod is nothing special. It's just huuuge. So when you use features provided by "default" in your mod, the mod needs to depend on "default" like it needs to depend on every other mod whose features it uses.

I would have thought default would be loaded first as it's a part of the game - minetest_game in this case. Also, advtrains_train_rocket depends on advtrains, but advtrains does not depend on default either. So in a dependency forest, minetest_game mods sit in a different dependency tree.

I get that it's hard to handle this special case. You would have to analyse the dependencies when loading a world and figure out if it's a forest of just one tree or multiple. If there are multiple trees in the dependency forest, and there is a nil value error thrown during load, and that nil error is to a table the same name as a mod name in the current game, report back with the text "does this mod depend on game mod <mod> without declaring it?". I'm not sure if it's worth coding this special case in or not.

[Linuxdirk]

I would have thought default would be loaded first as it's a part of the game - minetest_game in this case.

Unfortunately no. Mods are loaded in a somewhat random order. Mods that depend on other mods are loaded after the dependencies are loaded.

If you know that your mod uses a certain feature of another mod you must add it as dependency. If you optionally support that mod you can add it as optional dependency and if the optional dependency is present it gets loaded first and then your mod gets loaded. But that's the best you get when it comes to dependency solving with mods.

I'm not sure if it's worth coding this special case in or not.

You can also delay the loading of your mod to the point after all other mods are loaded and then check in your mod loading code if the feature/function/node you want to access is present. With this you can avoid the dependency issues during load time. Not sure what happens when you have multiple mods doing so. Maybe race conditions.

I started doing this with some of my mods without any issues so far.

[Blockhead]

I've come back to this problem after encountering again a few times. My opinion now is that the best thing to do for simple mods that want to get default sounds from the base game is to optionally depend on default/mcl_core etc and assign variables to get the sounds from. Similarly for crafting materials, you can assign a string to hold the contents of whatever your game's steel/wrought iron/iron bar equivalent is and use that in the recipes.

I would like to put some of these features in a library mod, which I have a (stub WIP) repository for here. EDIT: You are looking for xcompat Some planned features were:

• Common crafting materials e.g. iron ingots, paper, dyes.
• Sounds, especially game-provided defaults of node walking, damaging and breaking sounds.
• Displaying a player's full inventory inside of a formspec (e.g chest -> node-based, advtrains wagon -> detached or even an admin tool for modifying other players' inventories player->player)
  
  Currently the player's inventory size is almost universally assumed by the game's own mods and 3rd-party mods for that game. This means a simple port of e.g. advtrains to Mineclone2 doesn't show players' full inventories

Other suggestions are welcome and when it reaches a certain level of maturity or if others have a lot to say, I'll make that mod its own thread to not go too far off-topic from this thread.

[orwell]

Will this become something like the Debian "alternatives" system? So you can call multigame_lib.get_common_item("steel_ingot") and get the closest equivalent of that depending on the game that is used? If so, nice idea.

Some features I can imagine:

- Common API for adding things like buttons to the default inventory formspec (back in 2017, Worldedit used to add an editor button onto the default MTG inventory formspec, but that conflicted with 3d_armor)
If someone has installed unified_inventory, sfinv or similar stuff it should bridge that as well

- Group definitions? (perhaps games define different group names for common things like "a stone material" or "something that can burn" - unify these)

- A unified API to check for certain info about the game's nature: "does the game have a classical inventory", "does the game use the classical crafting/smelting mechanism or a custom one (and which one)" etc

[Linuxdirk]

I would like to put some of these features in a library mod, which I have a (stub WIP) repository for here.

Yet another default mod?

[Blockhead]

I would like to put some of these features in a library mod, which I have a (stub WIP) repository for here.

Yet another default mod?

No, the intention is not to provide any content in the mod. It's to reduce boilerplate like

Code: Select all

if minetest.get_modpath("mcl_core") then
    craft = "default:steel_ingot"
elseif minetest.get_modpath("default") then
    craft = "default:steel_ingot"
end

with a call to the library like:

Code: Select all

if not lib_multigame.has_content("iron_ingot") then
    error("You need to run this mod on a game with iron ingots!")
    -- Alternatively: Disable crafts
end
craft = lib_multigame.get_craftitem("iron_ingot")
minetest.register_recipe([[--some craft that needs iron ingots--]])
...

If a feature is unavailable in the base game, the mod author will have to error out or drop a feature.

EDIT: I never went through with that project, but SFENCE has made basically what I intended it to be: adaptation_modpack.

EDIT 2: Nowadays I would recommend xcompat.