Mod library and dependencies

[Sobralia]

Hello,

I'm new to Minetest but since it seems to run far better than minecraft and for many other reasons (and it's a free software!), i made the switch. I made a few mod for minecraft and i want to do so with minetest.

Then, i started to read documentation about lua/api and the modding book as i never used LUA.
I started to make some library to help me with mods, like a chat commands library (which subcommands supports) and a permission system (with groups). Before that, i spent a lot of time searching on the forum to see if someone already made that kind of mod but no result atm.

I read that some users doesn't like dependencies between mods but as a developper i don't like to repeat myself when i code (that's why i started the two "mod lib" mentioned above). But i can understand as there is no a true mod package manager to download mods and theirs dependencies (yet i found a github repo that regroup mods and a apt repo, but not what i was really looking for).

So there are my questions:
- does some library for mods exist?
- if not, will you use some command, permissions, etc.... library if they exists?

I think that's creating some "standard" library will be useful for a lot of mod, i have seen topics about mobs mod that works differently or use a fork of a mod which is not updated anymore, etc... This way modders could spend more time on creating innovative mods instead of reinventing the wheel (this famous wheel ^^')

[octacian]

Yes, there are many libraries for mods. One example is biome_lib by VanessaE, which makes it easier to add growing things (e.g. trees).

I don't understand, though, why you need to write a library for permissions and chatcommands. We already have register_privilege and register_chatcommand. These give pretty well all you would ever need. The whole Lua API is essentially a library, providing easy ways to register new content.

My personal opinion on dependencies is that developers should include everything needed in their mod, by putting the dependencies in subfolders then simply adding an extra dofile to the main init.lua for each dependency. Then include a simple if statement, that checks to see if the dependency is already installed as a separate mod before running the internal version. You could even set it up to automatically download the dependency through cURL (I think?).

[Sobralia]

Thank you, i didn't find the biome_lib by VanessaE!

I want to make a permissions library because with minetest.register_privilege you have to register/grant/revoke one by one, my permission plugin will give the posibility to add many privileges to a group and then add users to this groups: so it will be easier to manage users privileges for many users.

For the chatcommon, it's just that i don't want to make an if forest in my registered command to handle subcommand. I tested to register "/foo bar" but it didn't works. With my ChatCommand lib you will be able to register a command and his subcommand like this:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

local foo_cmd = chatcommand.register("foo", ...)
foo_cmd.register("bar", ...)


Then you'll have a command "/foo" and a sub command "/foo bar"

[octacian]

Right, so rather than using if param == "..." then ... Makes sense!

There are already several mods allowing grouping of privileges, one of these being ranks from ServerExtended. You might find it interesting to take a look, as you could always borrow code from there. Privileges within ranks using this system are set in config.txt.

I plan on implementing such a system in to my mod, servertools, at some point, so will be interested to hear what you come up with.

[Byakuren]

Yes, there are many libraries for mods. One example is biome_lib by VanessaE, which makes it easier to add growing things (e.g. trees).

I don't understand, though, why you need to write a library for permissions and chatcommands. We already have register_privilege and register_chatcommand. These give pretty well all you would ever need. The whole Lua API is essentially a library, providing easy ways to register new content.

My personal opinion on dependencies is that developers should include everything needed in their mod, by putting the dependencies in subfolders then simply adding an extra dofile to the main init.lua for each dependency. Then include a simple if statement, that checks to see if the dependency is already installed as a separate mod before running the internal version. You could even set it up to automatically download the dependency through cURL (I think?).

There are a few problems with this approach.

• If two mods have the same dependency, which does not create any global tables to check for, your method would cause duplication of the mod, since it would be impossible to check whether another mod has run the same mod code. Everyone using your method would have to adopt some convention to allow mods to check which other unregistered mods have been manually entered.
  
• Assuming the first problem was solved, "fixing" the mods would take more than just "a simple if statement". Here are some things you would have to change:
  
  • You would need to check BOTH whether the mod was loaded "manually", and whether it is registered with the system. If you only check the first, then a registered mod might not have loaded yet, and it will get loaded twice. If you only check the second, you miss other mods that included the dependency, as mentioned earlier. This would bloat your if statement immensely, or require you to assign some intermediate values.
  • Any calls to minetest.get_modpath or minetest.get_current_modname would have to replaced with hard-coded directories, which you would have to figure out from your project structure.
  • dofiles would have to be modified.
• Some mods check whether certain other mods are installed in order to enable additional functionality. They would not be able to see the dependencies in your mod. Sometimes "additional functionality" means compatibility, so this could break other mods.
• If your dependency has dependencies, you have to include and modify all of them too.

I assume you mean libraryish mods in general and not libraries that are specifically designed to be included in a project directly, because you were worried about making sure they are not loaded twice.

[octacian]

If two mods have the same dependency, which does not create any global tables to check for, your method would cause duplication of the mod, since it would be impossible to check whether another mod has run the same mod code. Everyone using your method would have to adopt some convention to allow mods to check which other unregistered mods have been manually entered.

Your right. Hadn't thought of that. The simplest thing I can see, would be to make some changes to the engine to define where mod libraries included within mods would be found (thus some sort of directory placement convention), and use global tables as in normal mods to require that the name of the folder / file in which the library is stored always is the name of the library. The engine could then review the libraries on launch, and run only the ones needed to prevent duplicate code which would cause a memory leak. This would mean some sort of naming and directory placement convention as in mods and modpacks already.

I think the above would deal with the second issue as well. Not only that, but get_modpath and get_current_modname would not need to be replaced with hard-coded directories (I think?).

Some mods check whether certain other mods are installed in order to enable additional functionality. They would not be able to see the dependencies in your mod. Sometimes "additional functionality" means compatibility, so this could break other mods.

With the engine check based approach, when mods query for dependencies, the engine could check the mod libraries already installed through the "in mod" method, and provided that a naming convention was followed, mods would not break and code would not have to be repeated. Not only this, the engine could be configured to use separate mod libraries over included mod libraries, if a naming convention was followed, requiring no changes or "forwarding" to be made for the mods with external dependencies.

If your dependency has dependencies, you have to include and modify all of them too.

With the above method(s), all dependencies could be included in a dependency directory within the mod directory and then processed by the engine as above.

[Byakuren]

Using normal dependencies (for mods that aren't designed to be inserted already) is simpler, as it doesn't require extending the mod-finding logic to add something very similar to modpacks. Also based on the discussion in here, I would guess your change would not get in, since it would create ambiguity as to which version of the mod-library to use if multiple mods have the same-named dependency.

I think more widespread use of package management for mods is the solution, since then the package manager can choose a canonical mod that satisfies the dependencies, instead of having to choose between two. This could be an external manager like rubenwardy's MTPM, or something part of minetest (like if MTPM was merged).

[octacian]

I agree, some type of package manager for mods is the solution. I am considering working on a mod manager like the old Mod DB and integrated directly into Minetest, including a command line utility, but do not have much free time right now. I don't really know any C++ either, and that would be the ideal way to do it.

[Byakuren]

It could also be done in Lua, since the main menu is in Lua. If you do something like this I hope it supports installing from bower repositories as in Minetest Bower, or at least has support for dependencies specified with version lists/ranges.