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.
