Minetest_game: [Discussion] Add new features as mod to MTG

[MarkuBu]

Today some bugfixes and new nodes are added to MTG. I had no problem to update sfinv and screwdriver mod just by replacing them in my subgame.

I also would like to add the new sandstone blocks. But because they are added to default as usual, I have to find each single line and copy it.

The new sandstone blocks could be added as new mod without any problems and subgames or servers could add them just by adding the mod.

Would this be possible in the future?

related discussions are #515 and #1485

[sfan5]

No this is dumb, soon minetest_game will have 100 mods just because we added a few new nodes.

[MarkuBu]

Not necessarily. Not each new node needs to be introduced by a new mod. Once there is a mod category, e.g. like stone nodes, new stones can be added to this mod.

Or maybe there is just one mod for nodes

But to be honest, the current development style is dumb because maintaining MTG is horror

[rubenwardy]

Roughly independent mods would be good, however a mod per node would be excessive and damaging.

My idea structure would make books and keys separate, as they're contained craft trees and keys is a feature that should be done using callbacks and overriding imo - and is something people would like to disable.

Overriding default isn't a big usecase for me, I see this as better for maintaining intersubgame support (easier to isolate features, and for mods to depend on what they need)

[paramat]

Doing this to some degree is ok, and we are already doing this, if a significant addition can be a separate mod it is made to be so. Too many mods makes dev work harder though.

[MarkuBu]

I agree that it doesn't makes sense to make a mod for single nodes or item like I did here (will change this), but I think this should be a level each dev can handle.

For me it is hard to work with MTG because related functions are spread over several files.

[paramat]

That looks borderline acceptable, but the issue is how to get to that state from where we are without extreme disruption and headache. Ease of dev for subgame creators doesn't take priority over ease of dev for MTGame devs, if anything it's the other way around as MTGame devs are generally more overwhelmed and stressed. It's a balance.

[MarkuBu]

That looks borderline acceptable

But it makes the whole thing more flexible. Let's assume you want to add new dirt nodes. All you have to do is edit and update the dirt mod. If you want to add new liquids just edit and update the mod. It doesn't effect the rest of the code

but the issue is how to get to that state from where we are without extreme disruption and headache

I understand that, but I think it is possible. A lot of mods work without any problem because they don't have any dependencies. A lot of mods only depend on some nodes and the default.node_sound_stone_defaults() functions

Maybe a lot of dependencies can be solved with aliases (I don't want to add them now) and maybe a temporary default mod with some common functions. But I think about a new sound API

Maybe my approach is not perfect yet. I'm open for suggestions. But I think the basic idea is good

[Desour]

If default would be split to many mods, would it be good to keep the default mod with an empty init.lua but with a depends.txt with all the new mods? This would be good for mods that depend on default and don't change.

[octacian]

It would be good IMO to keep the default mod with the player code and files. That's the one thing that kinda makes sense there. Aside from that though, I think that almost everything should be split up. I was going to open an issue proposing a new method of organizing MTG, but haven't gotten to it.

[Wuzzy2]

I give my input for you:

The whole design of default is based on an anti-pattern: God Class. (Okay, more like “God Mod” in this case). It is way too big and has way too many features which are totally unrelated:

• Basic GUI elements
• Default sounds
• A ton of items, including trees, fences and keys. The items in default often feel completely random and unsystematic
• Many API functions which also feel pretty random
• 3D player model
• Map generation

This is a huge problem whenever you need to depend on any of those particular features. You always have to pull in everything and the kitchen sink. For example, it is very common to depend on default node sounds.

default does not have a defined scope either. As a result, the bloat becomes worse. There is seemingly no limit to which features can be added into default.

Too many mods makes dev work harder though.

I disagree. My subgame MineClone 2 literally has over 100 mods, yet it did now make development harder in any way. In fact, it helps me a lot in keeping the overview.
What is important is not so much the actual number of mobs, but how they are organized. But I agree on the reasoning that creating a mod for every semi-reasonable set of nodes may be excesive. I think this can be decided on a case-to-case basis. I agree that a mod only for sandstone nodes is WAY too excessive. This would only be justified if we really had a big number of sandstones or even a sandstone API. Which is not the case for us.

I think well-organized mods should be organized in a way that makes dependency management easy. One mod for one feature. Mod size should not be a major concern. Just because a mod is small it does not mean it would be a good idea to merge it with another mod. For example, I would not recommend to pull in basic GUI configuration and default sounds into the same mod.
As a rule of thumb: if it has its own API, a new mod definitely makes sense.

As a result, I keep default sounds, basic GUI, 3D player model, map generation and fences separate in my subgame MineClone 2. I still have a mod directly derived from default (mcl_core) but it is now very small and contains only a few items and nodes.

I hope my input helped you a bit. Take what you want from it. :-)
This post is not so much a suggestion, but more what I know from experience as a modder.

[rubenwardy]

I agree with everything wuzzy said.

Kinda wish we could just rip it all up without a care about breaking mods

[paramat]

Well, there are suggestions going around that MTG is from now on only 'maintained', minor improvements and bugfixes only, and that new subgames are started to be freshly designed with a better structure from the start.
There has been an intention to work MTG towards being a more complete game, but maybe if it's a mess new features are best added to new subgames instead.
So much relies on MTG it cannot be restructured.

[raymoo]

Dependency on the default table could be solved with a skeleton default mod that just makes the old API functions as aliases to the actual functions from the mods that are split from default. For example:

-- Example case, I'm not suggesting organizing a "sounds_mod" and I know there isn't a function with this particular name
default.stone_sounds = sounds_mod.stone_sounds

I can't think of a way to solve the dependency on default textures though, or reliance on node/item names.

[paramat]

We intend to add new content as mods if possible, so the answer is yes.
Author has left MT.