Minetest-Mods team[Mod repository]

[sofar]

Very good project. That's what we need to develop Minetest mods.

I have not a lot of mods to share, only valleys_mapgen, and it's now less useful since it has been merged in the core. But I can give it to minetest-mods if you want, even if duane maintains it.

Well, with it being merged in core, it would quickly be obsolete. I tend to keep those mods out of there for now.

However, isn't there a lua addition to the mapgen for the extra plants and trees that is still useful?

[Gael de Sailly]

However, isn't there a lua addition to the mapgen for the extra plants and trees that is still useful?

Yes but few people seems to be interesting in it. And now we try to more or less reproduce it with the core biome system.

Maybe valleys_c but that's duane's repo.

[sofar]

However, isn't there a lua addition to the mapgen for the extra plants and trees that is still useful?

Yes but few people seems to be interesting in it. And now we try to more or less reproduce it with the core biome system.

Maybe valleys_c but that's duane's repo.

well, ultimately both are quite welcome - especially since both are finished and usable mods. That and being Open Source are the only real requirements at this point.

[sofar]

45 repositories as of today. Come join the fun!

[Wuzzy]

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

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?

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?
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?

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?

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 am interested to see how this project works in real life (not just in theory).

[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%9 ... rchresults

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?