Support for mod that is loaded before any other mod

[Wuzzy2]

Problem

If you need to have code that must run before any other mod, there's currently not really any reliable method to do so.

Specifically, for overwriting things like minetest.nodedef_defaults, it is very crucial to have this ability. Only very early in the mod loading does it make sense to overwrite the node definition defaults. If you already had 2-3 mods before you had the ability to overwrite things, then it is probably already too late.

Not having this ability makes it practically impossible to overwrite minetest.nodedef_defaults (and similar) in a reasonable (!) way.

Solution

Add support for a special mod (let's call it “gameinit”) that is treated specially by Minetest. If a mod with the name gameinit is found in the game, then Minetest will make sure this mod is always loaded before all other game mods and user-selected mods (but after builtin). Apart from that, this will be a mod like any other.

This mod must be a game mod, using the name for a regular mod must result in an error.

This will allow games to safely do their early initialization tasks like overwriting minetest.nodedef_defaults.

Alternatives

Suggest them. :D

[benrob0329]

Alternatives:

• init.lua in the game's parent directory
• Mod named init for simplicity's sake

Overall idea: I fully support the request as-is, although I'll still have suggestions :P

[AKryukov92]

How mod loading order is defined now exactly? Alphabetically? By position in dependency tree?
I don't think that relying on specific mod name is a good idea.
How this mod is supposed to be published and identified in contentDB?
What if you need two distinct mods for this behavior?

If this mod should work only for specific game, then init.lua with definition of mod load order is a good way to solve your problem.
If load order is defined by position in dependency tree, then you could make every mod in your game to depend on this "init" mod. It will push it to the begining of the loading order in this case.

[SmallJoker]

Dependency tree.

minetest/src/content/mods.cpp

Line 336 in 23bd563

void ModConfiguration::resolveDependencies()

It adds mods with met dependencies to the list, and adds the left overs below as soon their dependencies are met. First entry is loaded first. This code does not know where the mod comes from (MTG/CSMs/world mods/regular mods).
EDIT: Alternative algorithm: #8603

[benrob0329]

How this mod is supposed to be published and identified in contentDB?

Did you read the issue? This mod would only be a part of games, not anything seperate.

[AKryukov92]

Did you read the issue? This mod would only be a part of games, not anything seperate.

If it is called a mod, then it is supposed to be standalone thing. If it is a part of some game and have no meaning without it, then it should be included to some existing mod present in the game.

[SmallJoker]

Alternatives

Suggest them. :D

CSS z-index-like priority value that's used for sorting when there are no dependencies: #8873 (comment)
priority = 99999999 should then suffice unless a mod uses priority = 999999999

[Wuzzy2]

I don't really like the idea of z-index. Too complicated and fragile and probably not needed.

I don't think a 100% full control over the mod loading order is neccessary. I suggested a special case for a “first game mod” because it will be important for most init stuff like minetest.default_nodedef.

I don't think defining a mod order even more detailed is neccessary. I kept the suggestion intentionally simple.

I don't like dumping init.lua into the mods folder or even main game directory directly. Although that might still work. I don't think the init code needs any textures, metadata and other stuff you normally find in a mod, so it's probably safe.

I intentionally named the mod “_gameinit” to emphasize it's special game-only status. But I won't fight over the name, really.

[AKryukov92]

If you really need some piece of code to be a mod and if it is always part of some specific game and it should always load first, then put it as hard dependency for every mod in this game. Problem can be solved using existing tools.

If this solution doesn't suit you, then elaborate what additional requirements do you have.

[Wuzzy2]

Won't work.

Note that current mod loading order is kinda stupid. Game mods and user mods are “randomly” (ok, not really, but it looks chaotic) interspersed, so there's no guarantee that one mod will be definitely, 100% reliably, the first mod.
#8933

[AKryukov92]

If user mods and game mods don't depend on each other, then random load order of mods with satisfied dependencies should not be an issue.
If random load order leads to errors, then hard dependency is missing.
I assume you can't add hard dependency in your case and look for workarounds.
So you want to make a mod which will influence other mods, which are not directly depend on it?
What problem are you solving exactly?

[benrob0329]

If user mods and game mods don't depend on each other, then random load order of mods with satisfied dependencies should not be an issue.

If it is called a mod, then it is supposed to be standalone thing. If it is a part of some game and have no meaning without it, then it should be included to some existing mod present in the game.

So no, you haven't read the issue, you don't understand how Minetest game-development works, and you don't know the slightest bit of context for why this is needed because of that. You expect answers when they've already been given in the first post:

Specifically, for overwriting things like minetest.nodedef_defaults

---

If user mods and game mods don't depend on each other, then random load order of mods with satisfied dependencies should not be an issue.

Except any default behavior that the game overrides is not guaranteed to be applied to mods, and will result in inconsistent behavior because of that.

[AKryukov92]

for overwriting things like minetest.nodedef_defaults

This is exactly what I call "mod which will influence other mods, which are not directly depend on it".
And I think that influencing mod without appropriate dependency should not be possible.
Allowing this will lead to mess.

Except any default behavior that the game overrides is not guaranteed to be applied to mods, and will result in inconsistent behavior because of that.

This is why the game should not depend on mods outside of the game.
If all definitions are within the game, then author can make game_core mod with default behaviour and put it as hard dependency for each other mod within the game.

[benrob0329]

This is why the game should not depend on mods outside of the game.

It..it's not. Nothing inside the game is depending on an external mod. That doesn't mean us gamedevs don't still want to easily change all default nodedef settings (or any setting!) without looping through all definitions or making custom forks of every generic mod just for one tiny tweak that is easy to do with either a sane loading order or an 'init' type mod specific for games.

Games are meant to be a foundation for other mods, let us do that.

[AKryukov92]

Sounds like you want to ruin current mod dependency architecture "just for one tweak".
You know how to achieve same result now, that's why there is no need to change engine.

What do you mean by "foundation for other mods"?
Game feature consistent, ready to play content. I assume that there is game_core mod, which contains all defaults for this game.
If someone wants to make mod for this game, then he should add game_core as hard dependency.
You can't throw bunch of mods to user mods directory and expect that they will just work. You need to tweak them anyway.
Hard dependency to the game core emphasise the fact that some specific mod is developed for specific game, tested and supposed to work with it.
So by "foundation for other mods" I mean that game core is required as hard dependency for all mods developed for it.

[Wuzzy2]

If someone wants to make mod for this game, then he should add game_core as hard dependency.

For the last time: This won't work.

Making all game mods hard-depend on some init mod will NOT work. Because the current mod loading order is chaotic. After builtin is loaded, game mods and user-provided mods are “randomly” interspersed. So it's very possible that an user mod can be loaded BEFORE a game mod, including the init mod.

A request to force the mod loading order to be builtin → game mods → user mods was rejected recently.

[Wuzzy2]

To clarify: It's very impractical to force all user mods to depend on an arbitrary game mod name just for the init routines. Because the init mod name will likely be non-standard, so you can kiss good-bye to generic mods that want to be compatible with loads of games. Generic mods are very valuable.

[AKryukov92]

So is it impractical or not work at all?
How exactly it will not work? Could you provide an example with code?
I'm still under the impression that you want to avoid copypaste with hacks in mod dependencies architecture.

So it's very possible that an user mod can be loaded BEFORE a game mod, including the init mod.

If user mod has hard dependency on game mod, it should be loaded later. Dependency management will do ordering for you.

Because the init mod name will likely be non-standard, so you can kiss good-bye to generic mods that want to be compatible with loads of games.

And this is OK for me. Assuming our goal is to provide smooth experience for player. Imagine that there is mod "more air" and games "MTG" and "Pixture".
In case of author of "more air" should test his mod with all possible games which are present now (MTG, Pixture and all others) and which will be added in the future. Testing unknown games which will be added in future is just impossible. Author should watch for freshly published games and fix problems which can appear with them. More than that, those fixes should be universal and should not break "more air"+MTG and "more air"+Pixture combinations.
Act of making "more air MTG" and "more air Pixture" and adding hard dependency to appropriate game cores will reduce amount of testing for this particular mod "more air". Author should test only "more air"+MTG and "more air"+Pixture combinations. If someone uploads new game aircrafts_world, then author of "more air" should just make mod "more air aircrafts_world" with hard dependency and test ONLY "more air"+aircrafts_world.
Players who download mod "more air MTG" will surely know that there is a guarantee of working with MTG.
If someone will want to use "more air" with aircrafts_world, then he could manually change hard dependency and solve all possible problems by himself. Changing mod dependencies proves that user is experienced enough to solve problems. Casual gamers will not face potential problems at all.

A request to force the mod loading order to be builtin → game mods → user mods was rejected recently.

I have seen rejected request #8933 meant by you. This request #8934 will be rejected for the same reason. Rubenwardy in #8933 stated it as "You should not be depending on the mod load order, only on dependencies" and this statement is applicable now too.

[AKryukov92]

Copy-pasting generic mod with different hard dependencies is a lesser evil compared to the hacking dependency resolution algorithm.

[rubenwardy]

I think it would be better to make item definitions use metatables to allow the defaults to be changed after registration, but before the game finishes loading

This only solves your specific usecase, however

[paramat]

👍 proposal seems useful and worth considering.

[tigercoding56]

also a mod that gets loaded after every other mod ?

[benrob0329]

also a mod that gets loaded after every other mod ?

It's easy to run code after things are loaded, we have minetest.register_on_mods_loaded() for this exact purpose.

[sfence]

PR #14177 should fix this.