Split default into smaller mods

[rubenwardy]

Default has turned into a mod where you place stuff if you can't be bothered to think of a new modname or make a new folder.

Old IRC conversation

Advantages

• Easier to override and customise from mods.
• Easier for subgames to separate certain features.
• "More modular."

Disadvantages

• If not done correctly, could end up in removal of backwards compatibility.
• /mod spam.

Problems

1. Sharing default.node_sounds / having a default api.
   • Ideally these should be defined by a default mod which loads first and only has library stuff, but this breaks backwards compatibility.
   • As mods/ mods are loaded after game/ mods [citation needed, not sure if it's guaranteed], we could just call the library default. However we'd be assuming that mods in game/ were maintained by the subgame creator to know about the split, which isn't ideal.
   • This could be solved using a default_lib mod.
2. Changing names and aliasing requires complicated aliases. We could leave the old default:item names, however that is inconsistent.

Proposal

• Advanced aliases:
  • Chains of aliases. This is needed if a separate mod points from something to an old name.
  • minetest.registered_items["old_name"]
  • minetest.override_item("old_name")
• Split into the following mods:
  • default_lib - for library functions
  • default_natural, default_environment or default_mapgen
    • Dirt, stone, grass, ores, trees, cactus, papyrus
  • mese
  • nyancats
  • furnace
  • chest
  • tools
  • default
    • signs, books, ladders, etc
• Add a meta-mod (sort of) called "default" which depends on all other mods.

Feedback

Please suggest counter proposals and improvements, and any problems.

EDIT by SmallJoker: minetest.ru is down, replaced IRC link with irc.minetest.net

[C1ffisme]

I think nyancats should belong with the default_natural mod. Having one mod for nyan cats is a bit excessive, considering it's just two nodes and a generator script.

[rubenwardy]

I think it should be separate, as it's a special item and isn't necessarily wanted in other subgames. Along with mese too.

[C1ffisme]

I dunno... It would save on that /mod spam you talked about.

[rubenwardy]

By one item. I personally don't /mod spam is much of an issue.

[C1ffisme]

I suppose that's true.

Well, other than that, I say 👍. It also means it's easier to overwrite default mods with mods from /mods/

[ExcaliburZero]

The nyan cat is an odd node since it is fairly decorative and serves little other purpose. Perhaps it would be better to put it in a generally named mod such as decorations or special, so that if there were other similar types of nodes added later on then they would fit into that more general category, as just naming it nyancats would be too specific for a mod name.

[rubenwardy]

I'd be okay with special.

decorations is also a mapgen term for grass and trees etc.

[C1ffisme]

The nyan cat needs to do something useful at some point. Maybe it should generate light or be a crafting material for some boss spawner or super machine or something.

[rubenwardy]

The nyan cat needs to do something useful at some point. Maybe it should generate light or be a crafting material for some boss spawner or super machine or something.

That's offtopic, however maybe more reason should be given to why it exists, along with mese too.

[paramat]

👎 There isn't any desperate need for this and it would cause a huge amount of headache and complication. The advantages are minor, it's not even remotely justified.

[rubenwardy]

The default mod is already a headache.

[paramat]

Seems fine to me, and i have the 2nd highest number of commits.
Minetest may be structurally messy in places but aesthetic perfectionism is not worth the hassle.

[0-afflatus]

This is one of the reasons I started designing my own game. I don't like your proposed reorganisation @rubenwardy - I split it into: default, equipment, material, mineral, plant, tree and tool mods (see for yourself https://github.com/0-afflatus/grail_test/tree/master/mods) each has an aliases.lua, for which minetest.register_alias() works fine in practice. Most 3rd party mods work well with this so long as the required resources actually exist.

I'm not expecting Minetest Game to go down this route anytime soon. However I just want to point out that it needn't be that complicated.

[rubenwardy]

That's an acceptable split and I like that.

[kilbith]

I find some suggested splits a little excessive (e.g. mese, nyan cats). But nearly 2K lines of code for nodes.lua is indeed bloated, albeit it eases the search with a mere Ctrl+F.

IMO, it's not worth it since it doesn't improve the game much. And breaking the backward compat. is a no-go by itself.

[0-afflatus]

Backwards compatibility is possible using aliases. A few redundant textures would need to be maintained in default until such time as it is possible to alias textures. It won't change the game at all, ideally, but it may make it much easier to maintain and facilitate modding.

The names of the sub-mods would need to be reasonably generic: referencing mineral:mese is more logical (and therefore guessable) than mese:mese, naturally default:mese would still work via an alias.

[CasimirKaPazi]

I like the idea of splitting up the default mod. However, the proposed new mods seem useless to me. It's mostly tools, mapgen, furnace... things that have their own file in default at the moment. It would mostly move those files into separate mods, leaving them the same size.

The smallest, but most important split would be between functions and content (= nodes, tools, items, ABM). As proposed with default_lib you could keep the content in default and move the functions into a new mod. (I wouldn't call it after default, because other subgames might start to use it too that don't have a mod called "default". Also the idea of separating them is to make them modular, so they shouldn't be bound together by name like this.) I guess there is an easy way to map all foo.variable to default.variable, which then would make all the moved functions available from their old name in just one line of code.

Edit:
Mod "lib"

lib = {}

lib.hello_world = function()
    print("Hello World!")
end

Mod "default"

default = {}
default = lib

default.hello_world()

[0-afflatus]

I can see that the reason this is never going to happen is that we will never agree on how to refactor things. Personally I don't like your approach @CasimirKaPazi although I do understand why you would want to do that. I prefer to keep the functionality and content of each node type together, one file for each node type or group of related nodes. This makes it much simpler to add and remove node types. Having the content in one mod and functionality in another I find really confusing. What I don't like about default is that it mixes minerals, flora and equipment together. In my mind default should contain the minimum necessary for terrain generation excluding decorations.

This is because I'm a sub-game designer and my interest in Minetest Game is primarily as a basis for modification, although I do play it occasionally. I can see the value in splitting out the functionality from a programming POV, but even so, I think that would be better done with a functions.lua in each mod.

The use case for this was: I was thinking of making a sub-game that relocated the action to an imaginary planet with completely different animals, minerals and vegetables from those found on earth. The way it is organised currently makes it very difficult to remove, for example, default:tree.

MTG is never going to be all things to all people and should not attempt to be. Perhaps this approach should be directed at Minetest Development Test instead. It is certainly one of the issues that caused me to start developing Grail Test. It is interesting and possibly useful to see how different people's opinions are on this - so long as we don't get bogged down in this discussion. I favour a structure that reflects evolution, technological advancement and taxonomy - I'm the kind of person that rigidly organises my audio collection in an Artist/Album hierarchy. But then I do keep my video collection in a separate folder.

[sofar]

Death to nyan cats. That's all.

[0-afflatus]

Poptarts.

[CasimirKaPazi]

Personally I don't like your approach @CasimirKaPazi although I do understand why you would want to do that. I prefer to keep the functionality and content of each node type together

You misunderstood me here. I functions that are linked to a specific node should be kept together. e.g. furnace and furnace function would stay where they are. The "lib" mod would only contain general functions and definitions. Like the player definition, gui stuff, the dig_up function etc. (not sure about sounds). This would be especially helpful for subgame compatibility. Because when mods depend on "default" at the moment it is not clear whether it depends on some function or some node. With this spilt subgames could just include the "lib" mod without having to provide all the nodes used in "default".

Since my last comment I tested it in my subgame, used it for a while and had no problems at all. Because default depends on lib, there are no issues with mods that depend on default. I also noticed that mod profiling was more helpful when I have smaller and more modular mods.

[sfan5]

👎 Really no need for this, we already have seperate .lua files.
(Closing as there have been multiple disapprovals)

[rubenwardy]

Shame that the dev team can't see sense. The problem is that all different types of node are in the same file and mod (eg stone, dirt, wood, signs, furnaces, chests)

[C1ffisme]

The way I designed my realism game, default is just the mod that contains sounds and functions. The rest is in separate mods. This is what it looks like:

• animals
• awards (The one made by you, @rubenwardy)
• basic
• creative
• default
• farming
• hud (by Blockmen)
• hunger (by Blockmen)
• mapgen
• metal
• stairs
• thirst (Blockmen's hunger mod but tweaked.)
• tools
• villagers
• writing

Just thought I'd share.

[rubenwardy]

@paramat has agreed as long as backwards compatibility with mods is kept completely. He also doesn't mind calling stuff default: in other mods (cba to find link)

[paramat]

No i haven't, i'm still 👎 :] Too much disruption, complexity and headache we don't need.

[rubenwardy]

I disagree. Having it all in one mod causes issues when it comes to dependency management - mods will only work with one game if they need to use some default features. It also means that server owners can't disable features at will (eg: keys)

[paramat]

We can still split off small bits gradualy like keys or whatever is possible or practical or worth it, as we have been doing, and i support this. The problem is this approach of splitting everything for the sake of doing everything.
I won't want to work on MTG anymore if this is done due to the disruption of code and all the extra stuff needed for compatibility.
It's not much needed anyway, it will help some people a little yes, but the disruption outweighs the small benefits.

[ghost]

It's normal for items and functions to move within/without the default mod, I believe. Some features start small, and get big later. Others start big, and get small later. The book started in default, and originally it was only a craftitem. Now there are functions and stuff, so there's merit to moving items/functions when they get specialized enough, in my opinion.

…

On Fri, Nov 10, 2017 at 5:23 PM, Paramat ***@***.***> wrote: We can still split off small bits gradualy like keys or whatever is possible or practical or worth it. The problem is this approach of splitting everything for the sake of doing everything. I won't want to work on MTG anymore if this is done due to the disruption of code and all the extra stuff needed for compatibility. It's not much needed anyway, it will help some people a little yes, but the disruption outweighs the small benefits. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#726 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWXKYqZ9nV4PG0zZHOpDhTXxwneZgNKaks5s1MzSgaJpZM4GiD-l> .

[rubenwardy]

I don't feel like debating something tonight, but I will say that the issue is out of date and what I had in mind is less extreme

[SmallJoker]

For me that's a good idea, like splitting keys from default or the player API, which already has been done. However, removing too much from default shoots over the target, as modders need a solid base to rely on when items are needed.

[paramat]

Ok, i'm ok with a gradual process of splitting off some (not all) stuff that is easiest and cleanest to do so, as we have been doing already.
I strongly oppose the intention the first post.

[tacotexmex]

I wonder what level of splitting you’re talking about here, in comparison to MarkuBu’s effort.

[paramat]

Closing due to #2710

[rubenwardy]

This isn't a new feature, it's improving mod APIs and multiple game support

[paramat]

Yes i realise =)
Is there a reason this should be kept open? I closed it because, considering #2710 , i could not see any point in doing this.
If, hopefully, everyone moves on and games and mods no longer primarily revolve around MTG, i could not see much advantage in a new mod structure.
It might even be harmful in actually perpetuating the focus on MTG.
There does seem to be support for splitting off a few small bits, as we have already been doing, there is a PR for doing this with keys.
Your last comment suggests the first post is out of date, so we do not really know what you now propose, probably best to open a new issue for that though (if there is still something worth doing).