Minetest-Mods team[Mod repository]

[sofar]

This project sounds interesting, but I am not sure what to think about it.

I'll attempt to answer each of your questions, however, you ask quite a few, so if I miss a particular one, please repeat.

So, how does this work, exactly? Do you accept just any mod which is compliant to license stuff or are there certain quality requirements? Which kind of mod would not be accepted?

I usually end up talking to mod developers before they contribute a mod. Most of them are very resistant to contributing beta-grade code, and therefore we don't see mods that are just not ready yet - almost all the mods are of decent quality, or better.

We've refused only a single mod at this point. The mod in question would be best described as "an experiment to see how much damage mod code could do", and therefore it fell squarely outside of the requirement that the mod should be of quality, since it had none, effectively, to serious potential users of the mod.

Anything closed-source is a no-go, from my perspective, as well. But that isn't really an issue due to the way github works.

Also, how would you handle mods which provide conflicting APIs to solve the same problem? Would you include both? Just one? None? And which one?

At this point it's a non-issue and we don't see actual conflicts. I can see that we may have conflicts in the future, and I'll attempt to actually work with people to iron out the details (e.g. favor a component approach and break up more complex mods so both can exist as one being dependent, etc.). Most mod developers do not want to maintain code that is duplicated and better implemented elsewhere.

Nonetheless this may arise. I'm not the person who should decide which implementation is favorable (although I will certainly proclaim my opinion if I think it's needed), but ultimately both implementations can live in minetest-mods. Time will ultimately tell which one ends up being used or well-maintained.

I've written down however that we may end up refusing mods for this reason, and I think it's good to understand that mod writers shouldn't carelessly reimplement mechanisms, and we may want to discourage that. While I think we won't need to use or apply that particular rule, it may come in handy in case people are unwilling to modify API conflicts and other implementations are - in that case we have a reason to collectively decide to apply it.

How is your repository going to solve mod fragmentation? If I see correctly, you are simply limiting the set of all mods to a subset of mods in your repo. The thing is, mod fragmentation does not magically disappear if you just make a repo. Or how exactly have you imagined to solve the fragmentation problem?

My best example of fragmentation is "carts". The original author isn't taking patches, there are 2 forks, but if you google for carts or do some forum searches, you will have a hard time finding that there are forks, and which one is better.

Just having a carts mod under minetest-mods would remove this problem entirely - the forked mods' authors could collaborate there on the original codebase if they wish, as long as pilzadam agrees to submit the project to minetest-mods. I've asked him, but, no reply.

The forks of 'carts' are likely to go exactly down the same route in the future - they were made out of frustration, and now they are not getting the right users or users won't even find their versions, etc.. It's a disaster.

Also, I'd argue it will be increasingly harder to “legally” add a mod to the repo since one requirement states that no mod in the repo may conflict with another one. This means that mods which managed to get in early had good luck whereas newer, perhaps better mods might have a hard time to get in. I can foresee that bad things happen as soon as the first mob mod is added because the current situation with mob mods is a big fucking mess. xD
Also, do you plan to remove mods from the repo in favor of another (better) one?

I'm thinking you're taking the "conflict" too literal. I'm certainly not going to rigorously apply it, especially if mod writers maintain warnings that their mod conflicts with other mods, and have good reasons to do so.

What I am concerned about is if mods are conflicting with large amounts of other mods by breaking interfaces and commonly used functions, such as incompatibly implementing a core.* function override that breaks other mods.

Now, if mod writers work with us we can get those issues addressed.

Yesterday I loaded a minetestserver with ALL the 45 currently listed mods. None of them conflicted. A few did have overlapping or even duplicate functionality, but nothing broke, so, they're all good to go.

Also, have people other than the original author already worked on mods (which seems to be the main motivation behind this project)? Can you point me to some examples?

I've been looking at statistics a bit, and I can't find easy ways to list what you want, but there are some good viewpoints you can use through github searches that list relevant aspects.

One page I visit daily is this: https://github.com/search?utf8=%E2%9C%93&q=user%3Aminetest-mods+is%3Aopen&type=Issues&ref=searchresults

it lists open PR's and Issues. As you can see there are a few PRs pending, most if not all are from non-authors.

Similarly: search github for: "user:minetest-mods is:closed is:pr" and you'll see quite the list of PRs, most by non-authors. Some may have been done before the projects were moved, but it should give you an idea.

I am interested to see how this project works in real life (not just in theory).

Well, I'm impressed by the amount of mods at this point. However, I have to spend some more time convincing the more popular mods to make the move: mesecons, technic, moretrees/homedecor, pipeworks. With them in the group I think we can make a huge, huge difference.

[Don]

I added some of my mods and have been pleased. Sofar has fixed some issues that I never noticed. One of my mods has been taken over (with my permission) for further development. Knowing that the mods are being tested to make sure they are working right and work with other mods is a huge benefit. Also knowing that my mods will continue to be updated even if I leave minetest is really awesome. I have no plans to leave but you never know what the future holds.

If this project works like I think it will then this will be the go to place for mods.

[Wuzzy]

Sofar, thanks for your answers. I think this all sounds pretty reasonable.
Now I think the project is indeed a good idea.

Yesterday I loaded a minetestserver with ALL the 45 currently listed mods. None of them conflicted. A few did have overlapping or even duplicate functionality, but nothing broke, so, they're all good to go.

This sounds really great. However, I doubt it makes sense to ever use a server with all these mods loaded at once. xD
But it is good to know that you could.
I hope that duplicate functionality can be fixed, if it is needed.

What I am somehow missing in the repository is an overview of mods. Something like “I want to do XYZ, which mod do I need?”. Maybe a readme or something? I mean, 45 mods are a lot and they will probably become more over time. Such a readme could also contain differences if there are similar mods. Also, even worse, some mods in the repository are lacking a description in the repo (on this page: https://github.com/minetest-mods), more specifically, all the “my” mods. IMO this should be fixed to make this repository more useful to work with.

[Don]

Wuzzy - I will add a readme.md file soon to "my" mods. I am assuming that is what you are referring to.
The point you made about the description is a good reason for minetest-mods. With several people working together we find things that others missed. My mods never had a description but now that others are looking at them and having a bit of a guideline as to how they should be there will be a better standard.

If people are looking for a mod they will use the forum. The forum posts for the mods are still relevant. If they are looking for xyz then they will most likely google it and end up on the forum to find it.

[sofar]

What I am somehow missing in the repository is an overview of mods. Something like “I want to do XYZ, which mod do I need?”. Maybe a readme or something? I mean, 45 mods are a lot and they will probably become more over time. Such a readme could also contain differences if there are similar mods. Also, even worse, some mods in the repository are lacking a description in the repo (on this page: https://github.com/minetest-mods), more specifically, all the “my” mods. IMO this should be fixed to make this repository more useful to work with.

I think we can just copy the contents of description.txt to the github description to fix this. I'll certainly do this for all the mods when I get to it.

I'll make a checklist that lists README.txt as well for mod authors. We already require mod.conf and description.txt, it doesn't hurt to enforce having a bit more explanation what a mod is and we should also verify that the license is properly written down in an easy-to-find way.

[sofar]

I'll make a checklist that lists README.txt as well for mod authors. We already require mod.conf and description.txt, it doesn't hurt to enforce having a bit more explanation what a mod is and we should also verify that the license is properly written down in an easy-to-find way.

Seems like lots of people read this, there were only 2 mods left without repo titles on github.

We've grown 2 more mods, and I managed to get the bug count down to 4(!) open issues.

[afflatus]

Awesome initiative sofar. I'm only sorry it's taken me 2 weeks to catch up.

[afflatus]

I have an issue that may be outside the scope of this repo, or even contrary to your aims here, but I'd like to discuss.

As a sub-game author, the mods I find most difficult to integrate are the ones in minetest_game. Having these separately, but 'officially' hosted would make life easier for me. I'd be interested in thoughts of the 'proper' WTG about this. Probably I need to figure out how to include submodules of another repo as submodules in mine?

Feel free to move this discussion somewhere else if appropriate.

[Wuzzy]

As a sub-game author, the mods I find most difficult to integrate are the ones in minetest_game.

I agree. These mods are not very useful as standalone. The worst offender is probably the default mod because it does so many things: It creates the HUD, it creates the player model, AND registers a huge truckload of nodes, items, crafting recipes, plus ABMs and more stuff.

But I like the idea of ripping out the cool stuff out of Minetest Game and making it standalone.

In fact, I have already created a mod called “Player Model” (viewtopic.php?f=11&t=10349) whose only purpose is to add a simple player model like in Minetest Game. I took Minetest Game code and simply ripped it out of it to make it a dependency-free stand-alone mod. IMO it works pretty well so far and you can probably drop it blindly into your fresh (=not based on Minetest Game) subgame.
I think we (mod authors) should make a simple “base set” of mods to provide simple yet often needed functionality like creative inventory, player model, and whatnot, mostly kept dependency-free or with very light dependencies so they can be easily dropped into new subgames without worrying about the details.

The big thing in Minetest Game which would be *very* interesting as a standalone mod is creative. But ripping that one out might not be that easy since it makes assumptions about the player inventory. In practice this means you have probably to modify it manually if you want to use custom HUD or inventory sizes.
It was actually not that hard to integreate the new creative inventory into my Tutorial, but this is only because I used the default inventory and crafting grid sizes, so I was lucky. ;-)

IMO the other mods are too interdependent to be used as standalone mods. To make standalone mods of these, it might make sense to make “pure API” mods instead. For instance, pure API mods which only provide conveninence “register” functions to add your own stairs but it doesn't add any default stairs.

Finally, to get back to topic somewhat: Such “pure API” or generally just “basic functionality” mods would probably be great to have in a mod repository like this one.

Hmm, I am starting to think it might be actually a good idea to officially add some of my mods to this mod repository. :-)
You will hear from me again soon (hopefully).

[Byakuren]

One potential conflict if Wuzzy wants to get involved in minetest-mods is that monoidal_effects, which conflicts with playereffects (in functionality), is on there. I said that I would try to work on adding functionality similar to monoidal_effects to playereffects, but I haven't been very active on Minetest recently. Depending on how my spring schedule turns out, I may or may not have time to work on it, but I'm hoping to get to it soon. Don't take this as a warning not to add your mod or anything, I just wanted to mention this in advance.

[sofar]

We're up to 60 mods! Notable new mods that have moved to minetest-mods are:

- moretrees
- homedecor
- pipeworks
- biome_lib
- signs_lib
- plantlife_modpack

[afflatus]

One potential conflict if Wuzzy wants to get involved in minetest-mods is that monoidal_effects, which conflicts with playereffects (in functionality), is on there.

This is a great example where we could work together to create "one api to rule them all".
I have not had time to study monoidal_effects properly yet, but I intend to do so over the next couple of weeks.
Are there important (or unresolvable) differences of purpose or design between these two?

[Byakuren]

One potential conflict if Wuzzy wants to get involved in minetest-mods is that monoidal_effects, which conflicts with playereffects (in functionality), is on there.

This is a great example where we could work together to create "one api to rule them all".
I have not had time to study monoidal_effects properly yet, but I intend to do so over the next couple of weeks.
Are there important (or unresolvable) differences of purpose or design between these two?

I don't think there are any unresolvable differences. The main motivation for monoidal_effects is that it supports effects that can combine together (e.g. if you have multiple speed multipliers, it chooses the maximum. Or it multiplies them together, or something else that makes the most sense).

I think there is a workable way to add the functionality of monoidal_effects to playereffects. What could be done is to have monoid effects be separate from the normal effects in playereffects. Monoids would be registered as in monoidal_effects, and then an effect could optionally have a table of monoid-value pairs, like in monoidal_effects. The effects from monoids would happen separately from the normal effect application (apply/cancel).

Or maybe another way to do it would be to make a system for just adding/removing "permanent" monoidal effects to a player, and then you could write an effect that uses its apply to add the effect, and uses cancel to remove it. This might be a more modular design.

Other differences I can think of are (starting with the most significant):

• monoidal_effects can stack multiple effects of the same type, while playereffects does not
• monoidal_effects can have effects with permanent duration, playereffects cannot
• monoidal_effects uses os.time for timing effect cancellation, while playereffects uses minetest.after
• playereffects has exclusive groups, monoidal_effects does not
• monoidal_effects has effect tags, playereffects does not

There are also some API differences that make some things easier/harder. For example, in monoidal_effects, it is difficult to make sure only one of a certain effect type is active on a player.

One feature that I think would be useful, in the presence of effect monoids, is the ability to have "ephemeral" effects which do not have a set duration (temporary or permanent), but instead just go away when the player logs off. This would allow mods using playereffects to manage the lifetime of effects on their own. An example use-case might be an RPG mod, where a speed buff should be applied to a player in proportion to their agility stat. The mod could apply an ephemeral speed buff effect on player join. Another use would be to have an effect monoid that just adds values to another effect monoid, to create a sort of nested monoid. An example where you would want this is if the "top-level" speed monoid multiplied multipliers together, and you wanted one child monoid for speed buffs, and another child for speed debuffs. The two children could pick the best and worst multipliers, respectively, to get nice behavior.

Would it be useful for me to post this in the playereffects thread too?

[sofar]

digilines is the latest mod to join minetest-mods. Although it's technically a modpack, we wouldn't want to let this excellent mod out. In this case we may end up considering making this a regular mod that has everything included as a single mod. We'll see in the long run.

[Byakuren]

Actually I realized there is a much simpler way to add monoidal functionality to playereffects, and it wouldn't even require any changes to playereffects. I could make a new mod that only handles "ephemeral" monoidal state, so doesn't do persistence or anything. Then to make a playereffects effect that has a monoidal effect, you would just add a monoid value ephemerally through the effect's apply function (and remove on cancel). This way is more modular and would allow other mods to make direct use of monoidal state, rather than having to make an effect.

[sofar]

73 mods as of today.

I've merged all open PR's (except for one that was WIP, still), so at least PR wise we're meeting our goals.

We do have a lot of unactionable issues open, mostly feature requests. I'll continue to monitor to knock down the actual bugs, but we sure have lots of items that could use a good look.

[sofar]

82 mods as of today. New are Xdecor, intllib, MoreMesecons, irc, firearms, wiki, and a few others.

[sofar]

Even more mods are coming in.

New ones added since last tally:

https://github.com/minetest-mods/awards
https://github.com/minetest-mods/jump
https://github.com/minetest-mods/diet
https://github.com/minetest-mods/cmd_aliases
https://github.com/minetest-mods/unifiedbricks
https://github.com/minetest-mods/mysoundblocks
https://github.com/minetest-mods/privilegeareas
https://github.com/minetest-mods/vote
https://github.com/minetest-mods/smartfs

Bugs are fairly stable at 40-ish, with very little open PR's. 91 mods total!

[CraigyDavi]

The locked sign mod has been deleted from GitHub https://github.com/Kotolegokot/minetest-mod-locked_sign and other mods by Kotolegokot.

Maybe we could add a fork of it to the minutest-mods org? It's quite a popular mod.

The most up-to-date fork I've found is here: https://github.com/SmallJoker/minetest-mod-locked_sign

[lightonflux]

Is there a plan to have the repo integrated in MT or have a CLI client (python script) to download them?

[sofar]

The locked sign mod has been deleted from GitHub https://github.com/Kotolegokot/minetest-mod-locked_sign and other mods by Kotolegokot.

Maybe we could add a fork of it to the minutest-mods org? It's quite a popular mod.

The most up-to-date fork I've found is here: https://github.com/SmallJoker/minetest-mod-locked_sign

We don't "take over" projects, instead we ask people to "contribute" their mods (and move while keeping their access and control). So you should ping SmallJoker (Krock) and ask if he wants to move it - a github issue may be enough enticement for him.

[sofar]

Is there a plan to have the repo integrated in MT or have a CLI client (python script) to download them?

It was certainly the intent of the project to make this easier, but ultimately, that's up to the minetest team.

An integrated client seems like a far better solution (works on all platforms!) than a python cli. Someone just has to write it and submit.

[Wuzzy]

Hi! I maybe would like to contribute the following mods to the mod repository (but I am not so sure yet):

- bedrock2
- playertools
- wateringcan
- playermodel
- ltool
- galaxybox
- basic_hud
- hudbars
- hbhunger
- hbarmor
- teletool
- slimenodes
- mana
- inventory_icon
- dice2
- origin
- no_sneak_glitch

I hope none of the suggested mods cause serious conflicts with the other mods, and there are no serious overlaps. But please check for yourselves.

The main reason why I do this is because I noticed I just don't have the motivation and/or time to maintain so many mods (plus so many unfinished ones) at once anymore.

Note that all the code mods are hosted on repo.or.cz. I have no idea if this is a good starting point since your project seems to heavily depend on GitHub. I have uploaded my mods only on repo.or.cz because I thought the website was simpler and less bloated.
Would adding my mods to the mod repository mean I have to abandon repo.or.cz? That would be a lot of annoying and boring migration work for me, not fun at all. Or is maybe some kind of “mirror” possible? Please answer these questions before adding the mods to the repository.

About the mods (and information for potential contributers):
Most mods here are finished, luckily, but some need updating and boring maintenance work. Minetest tends to add more and more of “metadata” files, like screenshot.png, description.txt and mod.conf lately. It is boring work to update all those mods by hand after basically every Minetest release.

A mod which constantly annoys me is hbhunger. The complaints in this thread tend to pile up and I don't have the motivation to update the mod for missing food, etc. Also I am not a big fan of food myself. 3rd party contributions to hbhunger would be greatly appreciated.

The ltool mod works pretty fine, but I like to see:
- Bugfix: If you try to spawn a tree with unbalanced square brackets after the axiom got expanded, this causes a crash. I think it should be Minetest which fixes this, not me, but whatever
- I wish there was some way to access the formular via GUI only (currently there's only a server command). Inventory Plus and related mods don't help me as they require the mod using the inventory formspec, not a standalone formspec like ltool does.
- Other ideas are in the ltool thread


Lastly: One suggestsion about the project: I would like to see a central readme file which lists all the current mods in the repository, sorted roughly by categories (e.g. “decoration”, “map generation”, “server administration”, “tools”, “gameplay”, etc.) and with a short description and maybe a link to the mod's repository. Because there are so many mods now and it is hard to keep an overview.
Such a readme file could also list potential/known conflicts (at least within the repo).

[sofar]

Hi! I maybe would like to contribute the following mods to the mod repository (but I am not so sure yet):

- bedrock2
- playertools
- wateringcan
- playermodel
- ltool
- galaxybox
- basic_hud
- hudbars
- hbhunger
- hbarmor
- teletool
- slimenodes
- mana
- inventory_icon
- dice2
- origin
- no_sneak_glitch

I hope none of the suggested mods cause serious conflicts with the other mods, and there are no serious overlaps. But please check for yourselves.

The main reason why I do this is because I noticed I just don't have the motivation and/or time to maintain so many mods (plus so many unfinished ones) at once anymore.

Note that all the code mods are hosted on repo.or.cz. I have no idea if this is a good starting point since your project seems to heavily depend on GitHub. I have uploaded my mods only on repo.or.cz because I thought the website was simpler and less bloated.
Would adding my mods to the mod repository mean I have to abandon repo.or.cz? That would be a lot of annoying and boring migration work for me, not fun at all. Or is maybe some kind of “mirror” possible? Please answer these questions before adding the mods to the repository.

Because your mods are currently not at github, we'd clone them (you can't fork between github and repo.or.cz) and they would both exist. The risk is that people will only update one of those repo's and the other will grow stale.

I don't want to have minetest-mods maintain trees in both platforms. As it stands right now it's fairly trivial for me to make sure bugs are looked after and PRs are reviewed reasonably quick because it's all in one place.

Of course, nothing prevents you from keeping repo.or.cz in sync if you desire, it shouldn't be too hard to do this but it does mean running a script to keep them in sync.

I can do the migration for you, as well, just ask.

About the mods (and information for potential contributers):
Most mods here are finished, luckily, but some need updating and boring maintenance work. Minetest tends to add more and more of “metadata” files, like screenshot.png, description.txt and mod.conf lately. It is boring work to update all those mods by hand after basically every Minetest release.

A mod which constantly annoys me is hbhunger. The complaints in this thread tend to pile up and I don't have the motivation to update the mod for missing food, etc. Also I am not a big fan of food myself. 3rd party contributions to hbhunger would be greatly appreciated.

The ltool mod works pretty fine, but I like to see:
- Bugfix: If you try to spawn a tree with unbalanced square brackets after the axiom got expanded, this causes a crash. I think it should be Minetest which fixes this, not me, but whatever
- I wish there was some way to access the formular via GUI only (currently there's only a server command). Inventory Plus and related mods don't help me as they require the mod using the inventory formspec, not a standalone formspec like ltool does.
- Other ideas are in the ltool thread


Lastly: One suggestsion about the project: I would like to see a central readme file which lists all the current mods in the repository, sorted roughly by categories (e.g. “decoration”, “map generation”, “server administration”, “tools”, “gameplay”, etc.) and with a short description and maybe a link to the mod's repository. Because there are so many mods now and it is hard to keep an overview.
Such a readme file could also list potential/known conflicts (at least within the repo).

Good ideas and good mods!

[sofar]

We've had a good half year with many projects operating well and doing regular updates. We also had lots of new folks come in and help out with new PRs. The number of projects has grown by another 12 or so to 107. I think we removed one or two mods as well due to circumstances (mostly conflicts with our guideline rules).

All in all we've made it through a year!

I intend to do a census soon and revive the project manifest and leadership. We can, as a community, all step in to help out, and there is opportunity for new people to take charge.

[TheReaperKing]

Would it be possible to change all the WTF licenses to CC0? I was thinking that since there is such a great collection of mods that it would be a good chance for my students to learn how to clone git repos and also mess around with the code and learn about lots of mods available for minetest.

Also, if UjEdwins blessing, would be able to put his mods in there:
viewtopic.php?p=249854#p249854

Thanks so much! Take care.
-Mike

[Nathan.S]

I want to add my drinks mod to the minetest-mods, but for some reason I can't transfer the ownership there? Any ideas/help.

[sofar]

I want to add my drinks mod to the minetest-mods, but for some reason I can't transfer the ownership there? Any ideas/help.

Direct transfers are not possible. You need to submit an issue ticket first here so that we can review whether the mods fit the requirements :)

https://github.com/minetest-mods/minetest-mods.github.io/issues/new?title=New%20mod%20request

[sofar]

Would it be possible to change all the WTF licenses to CC0? I was thinking that since there is such a great collection of mods that it would be a good chance for my students to learn how to clone git repos and also mess around with the code and learn about lots of mods available for minetest.

Thanks for pointing this out. Yes this is something we want to do.

However, I will not force a mod maintainer to change their licenses. Obviously.

The question is how to handle this though, I can ask each of the 40 or so mods to change licenses, but it'll be a large amount of work, and I would appreciate some help with that.

https://gist.github.com/sofar/6f1cca05fbf610b0b90e9f2b164ef494

I think the best way to do this would be to either submit PRs with license changes to each project so that the maintainers can just merge them as-is. Sending an issue would just never get merged.

[sofar]

Also, if UjEdwins blessing, would be able to put his mods in there:
viewtopic.php?p=249854#p249854

I believe he doesn't have his code in github, right? That complicates things a bit. I would certainly prefer if he could confirm that he is OK with that.