FOSS gamedev and creative worlds

I suggest a new rule for mods which are wanted to be moved to Mod Releases: The mod's shortname (folder name) must not collide with the short of any other known mod. All mods which are found in “Mod Releases”, “WIP Mods” and “Old Mods” count as “known” for sure, other mods which may be somewhere else may count or not (should be decided on the situation).

Reason: Having two different mods with the same shortname is problematic for the following reasons:

• AFAIK shortnames were supposed to be uniquie from the beginning anyways. I see no reason why this practice should be dropped
• Users can't just install (not neccessary use at the same time in the same world) two mods if they have the same shortname, because folder names have to be unique. If you want to have both mods installed at the same time, you'd have to change the shortname manually (which means: folder name and node identifiers and many more) or try some other ugly workaround. Or the user eventually “decides” for one mods and deletes the other mod; this “solution” is also unacceptable.
• If you use the chat command “/mods”, you only see the shortnames of the mods. If you see “mobs”, you don't know which mobs mod is actually meant (there are currently 5 mods using this shortname)!
• Many people refer to mods just by the shortname because they assume shortnames are unique. But if they are actually not unique, refering by shortname will be actually ambiguous. If, for example, someone lists the mod “mobs” as dependency, it is unclear which of the 5 mods with the shortname “mobs” is meant

In case two mods with the same shortname are proposed to be moved, the mod which has been posted earlier “wins”, the other one needs to change its shortname.

I wonder what should happen to the mods with ambiguous shortnames but are already in Mod Releases. The logical and consequent way would be to degrade all those mods to “WIP Mods” until they have resolved their name conflicts. The mod which is oldest may decide keep the shortname, or change it, but all other mods need to change their shortname. But I fear this policy may piss off some modders because of extra work. Or maybe not, who knows?

I personally have always made sure that my mods didn't use the same name as any other known mod because of the obvious conflicts that would arise should somebody want to use the two mods, not sure why other modders haven't done the same.

In the case of the various mobs mods; I believe most are forks of the original mobs mod and are intended as replacement mods for the original.

Most modders seem to follow these rules anyway and try to avoid naming conflicts. The many mobs mods are a diffrent case. Those more or less do the same, just slightly diffrently - they're forks, and they ought to be merged back together as far as possible, with their specialities becoming configuration options. That's work that needs to be done, and that's work that always happens if something's copied and slightly modified.

Other mods usually have far less of a problem with naming conflicts as people choose diffrent names by default or alert the modder to the problem once a new mod is introduced to the forum.

Naming mods is sometimes a problem of its own. If you take the villages mod I'm working on, you'll find that there's a much older mod that is called "villages", although all it does (did? not sure if it works anymore) is place a few structures randomly on the map. The villages mod my mg_villages mod is derived from does not even show up under that name in the forum - as it's part of Nore's mg mapgen. Thus, my version's called mg_villages. But who's to understand that name? And then there's my first attempt at a villages mod which never got as far as the one Nore developed. I intend to bundle the new version with a couple of helpful mods and realease a modpack called "villages", replacing the single villages mod. Admittedly, that's pretty chaotic, but that's what you get if things develop over time.

I wouldn't outright exclude mods with the same name. People ought to be aware of it (and they are) and try to avoid such naming conflicts. But sometimes they can't be avoided, and having the same name may even make it eaiser for players to locate the mod and to avoid installing conflicting ones.

Wuzzy you suggest some really good reasons, but there are also some reasons against it.

• a mod called farming or beds, which is designed to replace "default" farming or beds. There is no other way to do it except calling the mod farming or beds.
  Shure, there exists functions like overwrite_item, but no functions to disable an registered ABM.
• a mod forked from another is not designed to work together with that. If this mod takes the same name, you cant install both at the same time.
• a mod that does not work if another mod is installed. Its possible to print error messages in this case, but you will get a lot forum posts saying "Mod does not work" or "Installing mods is too complicated".

so its different from case to case, and there should not be a general § saying mods with unique name is not allowed

I agree this would be a good change, but it would have to be accompanied by an enhancement to dependencies. For example, instead of saying you depend on ModA, you'd have to say you depend on CapabilityX, and therefore you could use either ModA or ModB which provide CapabilityX (and since ModA and ModB both provide CapabilityX, they conflict with each other unless specifically called out as being compatible somehow).

This is pretty much the way various Linux packaging systems work. For example, in Arch Linux, irrlicht depends on libgl, and there are several graphics drivers that can provide libgl: mesa-libgl, nvidia-libgl, nvidia-340xx-libgl, catalyst-libgl, etc.

As well as prestidigitator's suggestion, I'd like to see versions like in requirements.txt of pip:



etc.

Most modders seem to follow these rules anyway and try to avoid naming conflicts.

This is good, but “most” is not good enough. I proposed the new rule especially because I saw a growing tendency to overuse certain shortnames, and I wanted to do something about it.

a mod called farming or beds, which is designed to replace "default" farming or beds. There is no other way to do it except calling the mod farming or beds.
Shure, there exists functions like overwrite_item, but no functions to disable an registered ABM.

This sounds like a legitimate exception, and I may be willing to change my suggested rule. Maybe it is the only legitimate exception. But I am not quite convinced yet.
Replacing a mod of the subgame (if this is what you mean) sounds a bit weird to me, but I can understand that there may be use cases for that. But I wonder if this is actually possible. What happens if Minetest encounters an user-enabled mod which has the same name? Does Minetest load them both, does it crash, does it load only one of them or whatever?

In case Minetest loads only one of these mods, and it is the user-enabled mod, then I am changing my propsed rule to (new text is underlined):

The mod's shortname (folder name) must not collide with the short of any other known mod, except when said mod aims to mostly or fully replace a subgame mod. All mods which are found in “Mod Releases”, “WIP Mods” and “Old Mods” count as “known” for sure, other mods which may be somewhere else may count or not (should be decided on the situation).

If the mod's aim is to mostly or fully replace a subgame mod, the thread text must clearly say so.

In case two mods with the same shortname are proposed to be moved, the mod which has been posted earlier “wins”, the other one needs to change its shortname.

a mod forked from another is not designed to work together with that. If this mod takes the same name, you cant install both at the same time.

Related is also:

to avoid installing conflicting ones.

With “installing” I only mean that the mod exists in the mod folder. I do not mean that those mods will be actually used on the same world at the same time.

IMO just being a fork of some mod does not justify to not change its shortname. Sure, the mod is not supposed to work together with the original mod, but I think this kind of stuff should better be resolved by dependency manangement. Minetest does not support conflicts yet, but it should. But this is for the future and off-topic.
And my argument was never about “working together”.

Also, it is inconvenient for the user who wants to decide whether to use the original mod and the fork of the original mod. In this case, it makes a lot of sense (even if probably just temporary) to have both mods available at the same time. If the shortnames are different, great, all it takes is just going through the mod list and some clicks. But if the shortnames are not different, the user has to manually move the folders each time the user wants to try thoe other mod. This is inconvenient. Also, think of custom worlds. Many user-submitted worlds also depend on mods. Suppose one world depends on Mod 1 [mod] and another world depends on Mod 2 [mod]. Because of the same shortname, each time you want to play on a different world you have to manually move around folders, which is annoying as hell.

The dependency system does not handle mod conflicts yet, but if it will, it will also rely on unique shortnames.

This leads me to:

a mod that does not work if another mod is installed. Its possible to print error messages in this case, but you will get a lot forum posts saying "Mod does not work" or "Installing mods is too complicated".

This is because of Minetest's lack of conflict management. This should be added IMO.
Using the same name because of a conflict is a flawed idea. This reason is arbitrary. What if your mod has a conflict with two mods? What if you mod has a conflict with a completely different mod? Under your logic, you have to create a naming collision, only because doing otherwise might confuse players. Especially in the 2 mod case, this would sound totally weird und unlogical to me.

Conflicts are a problem, but “solving” them by intentionally creating name clashes just creates a new problem and funnily adds to the confusion. Conflicts should be handled, when they exist, but in a different way.

Naming mods is sometimes a problem of its own. If you take the villages mod I'm working on, you'll find that there's a much older mod that is called "villages", although all it does (did? not sure if it works anymore) is place a few structures randomly on the map. The villages mod my mg_villages mod is derived from does not even show up under that name in the forum - as it's part of Nore's mg mapgen. Thus, my version's called mg_villages. But who's to understand that name? And then there's my first attempt at a villages mod which never got as far as the one Nore developed. I intend to bundle the new version with a couple of helpful mods and realease a modpack called "villages", replacing the single villages mod. Admittedly, that's pretty chaotic, but that's what you get if things develop over time.

You are missing the point completely. I always have considered the shortname to be a technical, internal name, but not the “real” (I mean: human-readable, plain English (or whatever language)) name under which you present the mod.
Under the new rule, you still can call your mod anything you want, even naming collisions are not forbidden. Many modders do this already and it is the de-facto rule rather than the exception to make a distionction between the “real” name and the shortname. I have a mod which I call “Flying Carpet”, and “flying_carpet” is its shortname. The first name is the name I usually use in normal forum talk, the second one only when it gets technical.

It's a bit sad that Minetest only shows the shortname in the mod manager and that we are unable to define the “real” mod name at the moment, but that's off-topic.


To all the other comments I just say: Sorry, but you are off-topic. This topic is about a specific rule I proposed, not about Minetest's dependency management system in general.

Wuzzy wrote:To all the other comments I just say: Sorry, but you are off-topic. This topic is about a specific rule I proposed, not about Minetest's dependency management system in general.

I think that's the root of the problem. As minetest's dependency management lacks some features you have to rely on naming rules with many valid or controversial exceptions.

The solution is probably to discuss what needs to be done in the engine and then adapt the rules...

Wuzzy wrote:This sounds like a legitimate exception, and I may be willing to change my suggested rule. Maybe it is the only legitimate exception. But I am not quite convinced yet.
Replacing a mod of the subgame (if this is what you mean) sounds a bit weird to me, but I can understand that there may be use cases for that. But I wonder if this is actually possible. What happens if Minetest encounters an user-enabled mod which has the same name? Does Minetest load them both, does it crash, does it load only one of them or whatever?

In case Minetest loads only one of these mods, and it is the user-enabled mod, then I am changing my propsed rule to (new text is underlined):

Minetest does already handle mod loading like this:

example with farming:
farming is loaded from /games/minetest/farming except, there is no farming mod installed in /mods/farming or /world/worldmods/farming
1. /games/minetest/farming
2. /mods/farming
3. /world/worldmods/farming

so 3. will overwrite 1. and 2..
2. overwrites 1.
1. will only load is there is no 2. and 3.

this is what I tried to say you for your tutorial game/world :-)

Wuzzy wrote:To all the other comments I just say: Sorry, but you are off-topic. This topic is about a specific rule I proposed, not about Minetest's dependency management system in general.

Well, if you want to exclude discussion of dependency enhancements, then (FWIW) my vote for unique short names would be an absolute, solid, NO! Hopefully there's room for more discussion than that.

Prestidigitator: I don't see the logic behind this, but well, that's your decision.

I also do not see how your particular suggestion is related to this. And why a capabilty-based system is needed before creating this rule.

Sure, such a system would be interesting, but I don't see why it would be needed before implementing this rule.

And that's why I said it is off-topic. But maybe I was wrong and it was actually on-topic. Sorry if I was a bit harsh.

Well, let me give a concrete example. Let's say I want to publish a "Confections" mod. It uses wheat and flour and bread (products of farming) and also some interesting things you can get from certain exotic plants for decorations, and it gives all kinds of fantastic recipes for amazing edible and decorative baked goods. It also adds some new growable plants that depend on a farming API and some new trees that depend on tree placement and growth functions.

Well, it turns out I can get wheat, flour, and bread from either minetest_game's "farming" mod or from Farming Redo, and they even provide compatible APIs for registering new growable plants, so I don't don't have to care which mod is actually installed. Oh, and it also turns out I can get the exotic plant products from either More Trees or Ethereal, and I don't really care which.

What should I do? At the moment for the farming dependency I can just list "farming" and I'm good, no matter which farming-related mod the server admin installs. If those two mods are required to have different short names, on the other hand, I must either require that the server admin go into my "depends.txt" file and change the dependencies to match what they have actually installed, or I have to publish different versions of my mod (e.g. "minetest_confections" and "farming_redo_confections") that have different dependencies. Requiring server admins to change dependencies is a pretty bad choice for both maintainability and usability, but publishing many different versions will create a NIGHTMARE of exploding mods as soon as someone wants to create a mod that depends on my confections.

Right now, the name "farming" and the public API that is an intersection of that provided by minetest_game's farming mod and Farming Redo comprise a base class, with polymorphism that can be fulfilled by either mod. By requiring unique short names, you remove that polymorphism. To add it back, SOME kind of dependency enhancement has to be made. It could be breaking things down into capabilities, like Linux package management typically does it, or it could be some kind of more flexible dependency specification (e.g. depends.txt specifying "minetest_farming OR farming_redo").

The other dependency is interesting because More Trees and Ethereal are NOT drop-in replacements. Pretend for the moment that they both provide far more functionality than the common subset I am interested in (certain trees, fruits, an API for registering more, etc.), and that they aren't trying to be completely compatible with each other. For example maybe one provides an API for registering new fruit for existing trees, while the other adds an API for biome variations (Now I've reached my limit as far as familiarity with the actual mods, so I'm departing into the theoretical). But again, I only depend on the part that is compatible between the two. This faces the same problem I outlined above for farming, but also makes it difficult to argue that one is just a replacement for the other. Again I could somehow specify that the dependency is met by having either, or perhaps they could agree on a common API and each specify that they provide a "fruit" capability, and then I wouldn't even care if someone separated out just fruit into it's own third mod that doesn't try to generate complex biomes and tree growth and all the rest. One could also provide the capability "pluggable_fruit" while the other provided the capability "biome_variations", or something to that effect.

Going back to the problem introduced by unique short names for a moment, I now either require the server admin to change two dependencies depending on which of the 4+ combinations of farming and exotic trees they install, or I have to publish 4+ confections mods ("minetest_moretrees_confections", "minetest_ethereal_confections", "farming_redo_moretrees_confections", "farming_redo_ethereal_confections", etc.).

Look at how the Food mod supports multiple mods.

It adds groups to the items to be used in crafting: https://github.com/rubenwardy/food/blob ... it.lua#L17
With a list of items to add groups to: https://github.com/rubenwardy/food/blob ... rt.lua#L15
And backup ingredients if no items exist: https://github.com/rubenwardy/food/blob ... ts.lua#L18

*sigh*

Wuzzy wrote:
In case Minetest loads only one of these mods, and it is the user-enabled mod, then I am changing my propsed rule to (new text is underlined):

The mod's shortname (folder name) must not collide with the short of any other known mod, except when said mod aims to mostly or fully replace a subgame mod. All mods which are found in “Mod Releases”, “WIP Mods” and “Old Mods” count as “known” for sure, other mods which may be somewhere else may count or not (should be decided on the situation).

If the mod's aim is to mostly or fully replace a subgame mod, the thread text must clearly say so.

In case two mods with the same shortname are proposed to be moved, the mod which has been posted earlier “wins”, the other one needs to change its shortname.

I have read a lot of different discussions. I have seen why Wuzzy is saying this. If mod developers were 100% able to do the research and pick a name that works then there would be no problem. That does not happen. I do believe that most do try to be considerate and pick a name that works but not all do.
Plus, with so many mods available, it is hard to know if the name is taken or not.

I think that if a mod is in the mod releases then any mods that request to be moved to mod releases should be refused if it has the same name as any that are in mod releases. If Minetest is going to maintain a mod repository then there should be no name discrepancies. If mods like farming require same name for replacement then that would need to be changed before any changes like this happen. I am not a programmer so I do not know how that would happen but the core developers would need to make the appropriate changes.
A system where everyone knows there right way to do things would be great. One thing to remember is that this is open source and as such people can do as they please. If people choose to make mods that are the same name as other mods that is their choice. The forum and minetest community might not like it but they can choose to release there mod other ways.
Just my 2 cents worth.

Wuzzy wrote:...except when said mod aims to mostly or fully replace a subgame mod...If the mod's aim is to mostly or fully replace a subgame mod, the thread text must clearly say so.

Yeah, I'd be good with it in that case, and fine with keeping dependency discussions separate.

rubenwardy wrote:Look at how the Food mod supports multiple mods.

It adds groups to the items to be used in crafting: https://github.com/rubenwardy/food/blob ... it.lua#L17
With a list of items to add groups to: https://github.com/rubenwardy/food/blob ... rt.lua#L15
And backup ingredients if no items exist: https://github.com/rubenwardy/food/blob ... ts.lua#L18

Yeah, that's definitely a good way to design mods. I agree this kind of flexibility and modularity is ideal. It's not always practical, though, and actually practiced far less often even than that.

This is a good proposal, but a list of taken names would need to be provided.
No one would go over 12+ pages of forum topics to note down all taken names.
And using a webcrawler would put unneeded stress on the forums.

Exilyth wrote:No one would go over 12+ pages of forum topics to note down all taken names.
And using a webcrawler would put unneeded stress on the forums.

Since there are strict rules on how te thread titles have to be in the mod sub-forums simply reading all of the titles directly from the forum’s database and then parsing them into a list would be very easy.

Already done many times: see mtpm_lists on my GitHub account, Krocks mod search.

Mtpm_lists is the only one of these than finds out the modname. Krocks mod search just stores the topic title without extracting the basename. However, mtpm doesn't work for modpacks (as they don't specify a modname) and ignores mods with invalid downloads, so may be missing a few mods.

Let me just throw this idea in real quick: shims. One could have a "real" mod with its own, unique name (say "my_gnarly_mobs") and then another "mod" named "mobs" which simply replicates the "mobs API" in term of my_gnarly_mobs by depending on it. Then a player / server admin would need to install this mobs shim, and every other mod could just require "mobs".

Then we could/should have unique names for real mods, but allow colliding ones for shims. The only problem would be that one could not simply install two real mods using the same shim or interface.

More later, gotta go!

rubenwardy wrote:Already done many times: see mtpm_lists on my GitHub account, Krocks mod search.

Good to know.