MTG was officially moved to a 'bugfixes, maintenance only' mode!

[paramat]

Because we need to move on from MTG, which is holding MT back.

There is still too much focus on MTG, core dev and contributor time is better spent elsewhere on new games.
Hopefully soon we will stop shipping MTG with the engine, the more i think about this the more i realise how obvious and important this is, to stop MT being judged by MTG and confused with MTG. I consider this the most important task in the engine.
The more we add to MTG the more maintenance and time it requires, resulting in more focus on it and neglect of moving forward and creating new games (either modding bases or coherent playable games).

This does not have to be completely inflexible and rigid. Occasionally we could still add highly beneficial refinements or highly beneficial fundamental features.

If this seems controversial and extreme, it is not, as MTG deveopment has already been close to this state for many months.
Few contributions to MTG are made, and these are mostly bugfixes.

Is MTG a modding base?

MTG is sometimes described as a 'modding base', but it is actually a bad one due to its mod structure. However, splitting default into many smaller mods is a nightmare task that involves many aliases and the complexity of compatibilty code. MTG is not worth the effort this requires.

A good modding base would not have random feature mods included, like beds etc. Stuff that a game customiser would prefer to choose themselves.
A good modding base, to me, would be a world with biomes and resources, and mods to do fundamental environment stuff like altering clouds and providing environment sounds. Nothing else. Then you add mods to do what you desire with those resources.

Is MTG a game?

But also, MTG is not a coherent game, it has a random collection of mods, some of which are exact copies of MC features, that do not make much sense together. Survival aspects but no dangerous mobs.
MTG can never be a coherent game, and we should give up trying, because it suffers from 'design by committee'. Celeron55 warned about this in the past, and it seems he tried to limit the number of MTG core devs due to this. But as engine core devs were added, most insisted on being MTG core devs also, resulting in a large number of MTG core devs.

The MTG core devs are large in number but not coherent, and have equal power, this is the worst situation for a game which, unlike the engine, is a work of art.
A group creating a work of art only works well if either:

• It is not a group but an individual who can work at their own pace and unrestricted.
• It is a small group of people with equal power and a cohesive vision (very rare).
• It is a group of any size but with an absolute dictator, such that the dictator's vision is realised. This is the structure of Hidden Worlds and why that game was so successful and progressed 10 times faster than MTG.

MTG is also developed in a MT repo and according to MT engine rules, this further harms creativity due to the bureaucracy which is actually fine for an engine.

So

MTG is stuck halfway between being a modding base and a cohesive and compelling game, unable to be good at either.
We should give up trying to make it either of those.

The value of MTG is:

• To support what depends on it.
• As a gentle introduction game to get used to controls and basic aspects of many MT games.
• As a good game coding example (in some parts, not in others).

None of these require the addition of new features.

MTG contains a lot of nasty implementations that cannot be changed because of so much depending on MTG being the way it is.
In this way, MTG is very restricted and stuck 8 years in the past. I am actuallly surprised that we are still so focussed on it, i feel we should have moved on many years ago.

Obviously, we have to maintain MTG to support what depends on it. But beyond that i do not think it deserves any more than a tiny amount of core dev or contributor attention.

To be clear, i am calm and am not ranting or insulting MTG. I feel good about what we have achieved. I just have a clear view of how things are and a need to move on.

EDIT:
Some more things that need doing:

• Remove 'hacktoberfest' from GitHub tags to avoid unwanted attention from a silly event and from people not familiar with MTG.
  Remove 'minetest-subgame' from GitHub tags, we do not use 'subgame' anymore.

[sfan5]

This is the structure of Hidden Worlds and why that game was so successful and progressed 10 times faster than MTG.

I have no idea what Hidden Worlds is and couldn't find it form a quick search.

But as engine core devs were added, most insisted on being MTG core devs also, resulting in a large number of MTG core devs.

The MTG core devs are large in number but not coherent, and have equal power, this is the worst situation for a game which, unlike the engine, is a work of art.

MTG had a team of 6 before and it was still somewhat productive. (roughly 2016-2018 on this graph)
With the current team of 3 active devs, the issue seems to be that nobody has time (or willingness) to work on MTG.

I am actuallly surprised that we are still so focussed on it, i feel we should have moved on many years ago.

I don't get where you see any focus on MTG.
Sure it's still shipped with the engine, but we couldn't even get the translation update done at the start of the feature freeze. Nobody even cares.

---

Despite the nitpicking above, I don't see any future for MTG this way either and moving it to a bugfix-only mode is a necessary step.

[rubenwardy]

I have no idea what Hidden Worlds is and couldn't find it form a quick search.

Hidden Worlds is @Ezhh's game. It's a private repo currently

[ghost]

The only problem I see is that 95% of mods depend on MTG. I mean if MTG is removed then all ContentDB mods will be useless and the mods will be dispersed. Then a batch of specific mods will appear just for unique games, and they will be incompatible with other games. 9 years of mod history will be compromised. It will be a clean slate.

Casual players will be upset if they can't install good mods: 3d armor, moreores, decor in their favorite game...

[NathanSalapat]

@runsy This isn't talking about deleting MTG. It will continue to exist, just won't see new features.

[ghost]

@runsy This isn't talking about deleting MTG. It will continue to exist, just won't see new features.

Ah, so i say: OK. No more features. Still. Pause. Freeze. Only bugfixes.

[Wuzzy2]

👍 This would be not the first time MTG would be in a bugfix-only mode. Yes, let go of MTG, apart from bugfixes. MTG still needs to be supported in a strictly technical sense just for the servers alone. I agree that MTG can't and shouldn't be killed entirely simply because of all the dependencies that grew from it. Moving to maintenence mode is probably the best solution.

As for the modding base view of MTG, I might argue that allowing documentation improvements/fixes is acceptable as well. But I don't think it's pressing, I think the documentation is fine for now.

I mostly agree with this post, obviously, as I have argued to dethrone MTG for YEARS. I'm very glad to see that you finally agree. Going to pure-maintanence-only mode is a clear signal to set priorities.

The MTG core devs are large in number but not coherent, and have equal power, this is the worst situation for a game which, unlike the engine, is a work of art.

I think that's not really the problem. The problem is that MTG has a near complete lack of vision, for years. You don't neccessary need a “dictator”, but more like a shared vision. Since there was basically none, MTG was being pulled in many opposing directions, so it did not head anywhere. I have also nagged you years ago about MTG's core goals, but I never got a satisfying answer or just very vague ones at best. The fact that you still have not figured out whether MTG is even meant as a game, or a modding base, or something else, is very telling. It's no surprise that MTG was always in this misery, nobody knows what MTG is even about!
I don't think the number of MTG core devs is high. The decision of reducing the number of core devs in MTG didn't really help anything, since the actual problem was (IMHO) the lack of vision.

I agree with most of the rest of the post, except:

(…) a gentle introduction game to get used to controls and basic aspects of many MT games.

Absolutely not. MTG is not a good gentle introduction. I have disputed your claim before, I don't understand why you still repeat this.
The player is just thrown into the world without any hints whatsoever. No crafting guide (very very bad), punch trees with your hand, no helpful in-game description/help of complex items like the key, and other gotchas. Put that all together, and MTG is very beginner-unfriendly, especially those who a re new to the genre. You can't play unless you have at least some prior knowledge. Reading the wiki is a must, but not all players might know that it exists.

I think Repixture might become a candidate for an introduction game. First, it's deliberately very simple, and includes some of the missing help stuff. Bot it's not quite ready for prime time, however. First, it too lacks in content (IMHO), second, it has no tutorial-like elements (yet).

[Wuzzy2]

It's probably a good idea to discuss which PRs are, and which PRs are not acceptable.

Acceptable PRs to me:

• Bugfixes
• Changes in documentation/README
• Translations

[paramat]

By 'focus on MTG' i mean it being shipped with the engine, being the basis for so many servers, and having contributions being made to it, it still seems 'the game to aspire to contribute to', probably because it is shipped with the engine.
MTG is still the MT game with the most focus on it.

///////////////////////////////

Part of the reason i request this is to make clear to non-core dev contributors what PRs will be considered.

We still get PRs for new textures and random low-priority features (which should obviously be optional mods used with MTG), currently there is still pressure to attend to these, i feel obliged to. And it is then painful to try to argue these should not be added, and this disappoints the contributors.
For example a recent PR for new (and bad) textures, which i spent hours reviewing (in order to point out the problems) and requesting changes, then regretted spending time on.
It would be kinder to contributors to just say "we do not accept PRs for new textures unless the core devs have specifically asked for them", so that they do not waste their time in the first place and to avoid going through a review process of argument and disappointment.

• We make clear to non-core dev contributors only limited types of PR will be considered: Bugfixes, maintenance, documentation, translations etc.
• Existing high priority and fundamental new features in the process of being added can still go ahead, for example lava sounds.
• All the issues planning new features will be updated and/or closed.
• Low priority non-fundamental feature PRs will be closed.
• Very occasionally, the core devs might decide to add a new feature if it is highly beneficial and fundamental, for example the recent additions to alter the clouds and add environment sounds. But these would be organised by core devs, who could then possibly ask for submissions.

I think that's not really the problem. The problem is that MTG has a near complete lack of vision, for years. You don't neccessary need a “dictator”, but more like a shared vision. Since there was basically none, MTG was being pulled in many opposing directions, so it did not head anywhere.

This is actually what i meant by a large non-coherent team of equals.

MTG is not a good gentle introduction.

Well yeah, it is not great for that, i should not have included that =)

As this is a big decision, i ask for one more core dev to agree, that will then be a majority of active MTG core devs.
If this goes ahead i offer to go through all issues and PRs to update/close etc, and to make a post in the news forum.

[paramat]

Also:

• Remove the mention of MTG in the MT repo.

I mostly agree with this post, obviously, as I have argued to dethrone MTG for YEARS. I'm very glad to see that you finally agree.

Well ... the core devs, and celeron55, have actually also intended to dethrone MTG for many years, by shipping multiple games with the engine. But that never happened.
Now that we have the Content Database, that is not necessary, a far better, simpler and easier approach is now possible, by shipping no games at all. This is necessary to dethrone MTG, the problems will persist if MTG is still shipped with the engine even if it is in maintenance-only mode.

[paramat]

Also:

• Remove 'hacktoberfest' GitHub-wide label from repo, to not attract unwanted attention.
  (Label should be removed anyway.)

[rubenwardy]

Minetest Game is stagnating because there's a lack of direction. We try to please everyone, but end up pleasing no one at all. I want to see MTG be more fully-featured as a light minecraft-like, with:

• craft guide
• blast furnaces and alloy furnaces, to make iron harder to get
• make mese have a longer reach than diamond, to add a distinction to mese
• more underground variety
• throwable TNT sticks
• add mobs, eventually
• add bows
• make default into a meta mod, depending on other mods

Whether it's a fork or an official project, I think it's useful for Minetest Game to continue.

[paramat]

I do not consider the 'stagnation' to be a bad thing, using that word implies a bad thing, i think it is necessary and we realise this.
Considering how badly structured MTG is, how difficult it is to fix that, how much bad stuff it contains that cannot be changed because of how much depends on it being the way it is, i think MTG is too much of a history- and dependency- restricted mess to be worth adding more to or trying to base an impressive game around.

I consider the intent to create an 'impressive game' around MTG to be a mistake. It cannot be a good modding base either.

Better to make MTG maintenance/bugfix-only to support what depends on it, and start a new unrestricted game, even if the new game copy-pastes many of the better parts of MTG (to not waste that work) but uses a good mod structure, removes unnecessary mods and fixes the bad stuff like the horrific plant-spreading implementation.

So i suggest a fork (or multiple forks) that is free to alter and fix all that is wrong with MTG, not restricted by what depends on MTG remaining the way it is. Good chance to use a new name.

If a fork is made it needs to be developed under a new system, one of the 3 i list in the first post, not 'a large number of non-coherent core devs with equal power' as that is what MTG does and that does not work for a game and results in a dull unfocussed game as well as lots of subjective-taste arguing.

I will not be a part of any gameplay-focussed popular MTG-fork as i am not gameplay-orientated, or rather, my concept of 'gameplay' is radically different to most users of MT.
I intend to work on new games alone, or be part of other projects that have a dictator (like HW).

[Wuzzy2]

I fully agree with paramat. The dependency argument cannot be dismissed easily, there is a ton of mods and servers that depend on MTG so that some major changes would actually make things worse.

If you want to “rescue” MTG, the only reasonable way forwards would be an independent fork. A fork which can ignore all these restrictions safely. But I like to note the fork would have to have a radically different development method. It also needs an actual plan and vision, some goals to work towards, rather than just a vague and useless notion of “voxel game”. The bureaucracy of MTG has prevented MTG from getting a crafting guide, for crying out loud! The discussion about the crafting guide is >100 comments long, while almost all other games just did it.

Some advice for a potential fork:

• First and foremost, have people in the core dev team who are actually enthusiastic and/or highly motivated about the project. The next MTG release has only about 10 changes. That's basically nothing! In other words, nobody really cares about MTG anymore. If you can't get people excited about your project, if you can't get excited about your project, it will be dead before arrival.
• Create an actual design document, a vision, a project goal to work towards. Everyone who wants to become a core dev for this project needs to agree on this. This design document should lay out things like style of gameplay, style of “technology”, which is the “target audience” of the game, how multiplayer is supposed to work, etc. A set of core values also will make it much easier to decide whether a particular new idea for the game is acceptable or not. The lack of any shared vision is what has put MTG into this misery in the first place.
• Decide which parts of MTG you want to keep, and which parts not. No part of the original MTG shall be considered untouchable.
• When you have a rough vision, it is time to flesh out particular gameplay features in detail. Figure out how everything in the game will work out together. It needs to be more than just “more ores”. Also answer: Which ores? How many? Where? Why ores in the first place? What can you do with ores? Etc.
• Keep coherence in mind. Everything needs to make sense with everything. If you add a new item, think about how it interacts with everything else in the game.
• Quickly shut down any useless discussion about unimportant details without figuring out the bigger picture first. Ignore comments that discuss e.g. the shape or color of buttons when the topic is actually a crafing guide. It's not always wrong to discuss details as such, but it is a huge waste of time to discuss details before there is agreement on the bigger picture. MTG and MT have a serious bikeshedding problem.
• This design document should also have a very clear set of goals for version 1.0.0
• Decide early on whether focus is on singleplayer, multiplayer, or both. This decision will have a major impact on the game design.
• Develop all the planned core features and the core content of the game, and during this time, dump the extreme conservative development approach and perfectionism. In the early stages, major changes, including breaking ones, should be completely normal, just make clear to your player base that your game is in alpha/beta stage. You can return to conservatism when the game is actually in a stage that is worth conserving, but not before that
• Rework the dumpster fire that is default
• Desync releases from Minetest releases. Syncing releases with Minetest releases is a very arbitrary restriction

This list only applies if you actually want to do a fork, obviously. I don't know if we even need a MTG fork, or if it is better to just start something from scratch. Also, we already do have games which already have most of the features that rubenwardy lists, games with much greater potential. So check out those, too.

[Fixer-007]

There is still too much focus on MTG, core dev and contributor time is better spent elsewhere on new games.

What new games you people have in mind and will you even contribute to them in any way... Will it end up as even more "dead MTG" game? Will it be different this time with red tape on contributing, will PRs stall for years?

[paramat]

It also needs an actual plan and vision, some goals to work towards

MTG had all that except 'vision', see the many issues discussing the many planned features.

The bureaucracy of MTG has prevented MTG from getting a crafting guide

Nah, the delay is due to us still working through the necessary changes and refinements, and of course the usual lack of core dev time.

The next MTG release has only about 10 changes.

That is fine and expected for a game that has mostly unofficially gone into maintenance mode, just a few bugfix and maintenance commits.

nobody really cares about MTG anymore.

Well, i see what you are trying to say, but we very much care about MTG because it has to be very carefully maintained. We are just not much interested in further feature development, and are busy elsewhere.

Create an actual design document, a vision, a project goal to work towards. Everyone who wants to become a core dev for this project needs to agree on this.

Only needed if the development is 'small group of coherent devs with equal power', which is unlikely to happen with any more than 2 core devs, and i warn is one of the less good development methods likely to end up with similar problems to MTG. 'Agreeing' to an initial plan is not necessarily the same as having the same vision.
A group with a dictator can develop much faster with much less arguing.

What new games you people have in mind and will you even contribute to them in any way

Strange and negative question, there is plenty of ideas and enthusiasm for new MT games.
I referred to 'core devs and contributors', which means everyone, so i assume this is what you mean by 'you people'.

Will it end up as even more "dead MTG" game? Will it be different this time with red tape on contributing, will PRs stall for years?

Another strange and negative question. Some games will go well, some will not, obviously, just as currently. What i refer to is no different to current general MT game development.
I have made it very clear i am suggesting developing games in a different way to MTG.

[paramat]

Maybe i did not make it clear enough ...
My vision for the future of MT development is:

After the necessay main menu changes, ship MT with no games.
There will be no 'default' or 'official' game. MTG becomes just another game that just happens to have a lot that is based on it.

Move MTG officially to maintenance-only mode.

There will then be:

• Official MTEngine.
• Independent game projects, that may or may not include or be controlled by MTEngine core devs.
• Official MTGame in maintenance-only mode.
  (Here, by 'official', i mean in terms of where it is stored and how it is developed, i do not mean it is publicly presented as 'the official MT game'.)
  Kept in the current repo, developed as currently, and by the current MTEngine core devs, these are all necessary due to how much is based on it and depends on it, it needs to be kept under official control, maintained with high standards by those with the most experience of working on it.

[Wuzzy2]

I can get 100% behind this particular plan. Making MT more “neutral” as a whole and moving the spotlight to the particular game projects. Also, we need more of these “independent game projects”. =) It is good to see this issue as part of the Bigger Picture. Whether MTG is ever forked or not is actually besides the question, sorry for the distraction …

[sofar]

I support @paramat on this.

[paramat]

@rubenwardy @SmallJoker shall we do this? On the understanding that compatibility-breaking forks of MTG could be started as unofficial game projects (i might make one myself), so the good work in MTG can be extracted and built upon and ideas for MTG already discussed could go ahead in these.

[SmallJoker]

Generally I agree to your proposition.
MTG is going nowhere and I see the potential in focused mod collections overall (games, modpacks). However, the core of it must stay unified to avoid major compatibility issues arising from forks and mods that rely on a specific "default" version.

• Features are added only to new mods in forks
  • Mod API changes must be forwarded to MTG to preserve compatibility among forks
  • This might include minor features
• New MTG features (added due to popular demand) must have options to disable or override on startup
  • Avoids breaking forks
• "default" must have a standardized feature-check and version format
  • Eases mod integrity
  • Reduces compatibility issues when forks extend their "default" mods

Generally, MTG would be a repository to provide the official version of "default", "dyes", "wool", ... but happens to be a game which could be installed and used on its own.
I'll ignore the "what to ship with Minetest by default" discussion. Should be discussed in minetest/minetest.

[Wuzzy2]

• "default" must have a standardized feature-check and version format

Just add some variable names to the default table like default.version. That should do the trick.

I disagree with turning MTG to a mere modpack. This is too disruptive, and actually goes against the goal of keeping compability. OK, even if it is compatible, it would be super annoying for everyone. It might cause a lot of stress for server operators. Please note that a ton of servers use MTG in some way or other. Usually heavily modded, but still. No need to provoke them. ;-)

Just stop “tweaking” MTG already. MTG could be locked down right now. Just do it. What's stopping you?

I think the idea like “compability helpers” qualifies as “maintenence work”, so those won't be blocked if MTG is in “maintenenace/bugfix mode”. This can safely be added, even after the lockdown.

[paramat]

Features are added only to new mods in forks

MTG will not have new features added (after the larger ones already in progress), and a feature added to a 'new game derived from MTG' has nothing to do with MTG.

Mod API changes must be forwarded to MTG to preserve compatibility among forks

I think i might be misleading by my use of the word 'fork'. I mean completely unrestricted new games that are derived from MTG and use some of the work done in MTG, with no intention of being concerned about compatibility.
I probably should not have used the word 'fork' as it seems to have an assumed technical definition related to development and compatibility.
Besides, forwarding API changes to MTG means doing non-bugfix feature work on MTG, so should not happen.

"default" must have a standardized feature-check and version format
Eases mod integrity
Reduces compatibility issues when forks extend their "default" mods

New games derived from MTG should not have a "default" mod at all, it would be insane to do that, they should use a well designed mod structure.

I get the impression you are writing about the MTG project actually growing to include closely-related 'forks' with compatibility concerns. This seems a very bad idea as this is not 'moving on' at all. I am not proposing this and discourage it.

I propose that everyone makes a clean break from MTG and moves on (in terms of game and mod development).
The only compatibility concerns will be MTG being maintained as it is to support what depends on it.
The mods of MTG could be developed into new mods, with new names, that progress with no restrictions and become independent mods like any other.

I discourage anyone making a 'fork of MTG that has compatibility concerns'. If someone does want to do this, they are of course free to do that, but the maintainers of MTG should not feel obligation or do any work.
I think we should officially advise against any 'forks of MTG that have compatibilty concerns', and state we will not do any compatibility work on MTG related to such forks. Otherwise we would be letting others force us to do what we know is wrong.

We seem to have some kind of consensus now so i will start work on re-assessing issues and PRs, and will make a forum post.

[codeandfix]

first let me clarifiy that this comment is not against core developers or all the hard-working coders here.
these lines are just some thoughts about what should never be forgotten while working on the core.

focus on minetest core development/engine is an important task.
mods can be developed by users much easier.
anyway for most players (i think and would bet) most people tend to say minetest = minetest_game.
yes, there are other mods, but minetest-game is the product which makes the people like and love this "game".
dont get me wrong, it is nice, that there is much progress on core code, but if the user experience is beein on hold, the game tends to be dead. i dont like much eye candy, but this is a game where the only reason is to have fun with.

so if developing is focused on the core, never break backwards compatibility.
it is very important, that old mods (lets say on actual basis 2021 mt build) can be used in 5-10 years later without having to change one line of code.
if i talk for mt-game users: we want to build for the eternity and keep worlds we spend many manyears in for our "life" and not just for a game session of days, month or some years.

but last but not least let me honor, that iam very happy to see, that minetest is still under active development after c55 dropped it years ago. especially having core developers who are able and willing to spend very much time in coding the mt core!
so dont feel accused by my critic, i just fear, that the progress of the game part will stop or in the worst case will be deprecated.

one idea for the core api: if big api changes appear, you should provide apis of different version which are all maintained for many many years. after near to ten years with an old world i managed to upgrade most mods, so the world still works as nearly a decade before. so if core development is focused and compatiblity wont break its ok.

just my 2 cents about core vs. game dev

[ghost]

I think it is a good step, so devs can focus more on the engine.

But I would recommend to do one last thing for mtg:
split the mods from default into several ones and make default a modpack, please.
I tried that once (sadly deleted, in a time where I dropped minetest) and funny I've just found this work from Burli here who had the same idea nearly at the same time in the past (wish I had found that post when I was doing this...).
Of course it must keep the support for mods based on default.

[phseiff]

I think doing that at this point would not really add anything, but break a lot of mods.... And breaking a lot (if not a majority) of mods that depend on default (which lots of mods for MTG do) just for the sake of having some files ordered for something that won't receive new features anyway seems a little too extreme to me.

Of course it must keep the support for mods based on default.

Would this work, considering that splitting a mod into several mods changes the names of the items they register? I don't know much about modpacks in minetest, though.

[BuckarooBanzay]

split the mods from default into several ones and make default a modpack, please.

@voxel-minetest if you need (like me) a stable base for your game or just use the mods as submodules you can do that already here: https://github.com/minetest-game (those are just mirrored from the minetest_game)

[ghost]

@BuckarooBanzay
I don't understand, default isn't splitted at your repo...
And I guess I am not the only one who want to have default polished before it gets abandoned.

[BuckarooBanzay]

@BuckarooBanzay
I don't understand, default isn't splitted at your repo...
And I guess I am not the only one who want to have default polished before it gets abandoned.

Sorry, i didn't read your comment properly: no, default isn't split, only the other mods in the game

[ghost]

Sorry, i didn't read your comment properly: no, default isn't split, only the other mods in the game

NP.
;)
But the other mods in minetest_game are already single mods that can be picked as anyone like, so I do not get the sense of your repo.

[BuckarooBanzay]

But the other mods in minetest_game are already single mods that can be picked as anyone like, so I do not get the sense of your repo.

(this is getting offtopic, sorry)

My usecase was that i can use some of the mods from the minetest_game (default, doors or flowers for example) and re-use it in another game, while also keeping it up-to-date with the latest upstream repo.
I'm using the standalone mod-repos as a submodule in another git-repository.

Example (wip): https://github.com/BuckarooBanzay/eco/tree/master/mods

[codeandfix]

also there should be a simple legacy detector inside the core which helps to debug mods without changing debug out.
like: show me all items/nodes/* which are not defined anymore and tell me which name they have.
then admin can map a replacement or reinstall the mod.
if the admin confirms this remap it should be changed by a global //* abm which changes all database items/nodes/* to the new mapping (inreversible).
so we can clean up "moreores", "streets" etc.
also users/devs can provide "legacy" mods who convert old to new or other mods.
this could be improved much.
goal is, that for e.g. streets 1.0 can be converted to streets 2.0 without loss..
i think a mapping GUI ingame for the admin would be cool too.
this can be a mod thing but i think its a main core thing as it works on db.
yes i know, i can do it already (and yes i do), but its not comfortable for normal people (admins).

[AntumDeluge]

Is MTG going to be broken up into individual mods so they can be added to ContentDB?

[sfan5]

No, why would it?
Large parts of MTG are interdependent and only work with the exact same version of the other mods. Neither would they work inside other games.

[AntumDeluge]

No, why would it?

Because 85% of mods depend on default. So many of the mods on ContentDB won't work unless MTG is installed.

Edit: I'm just ballparking "85%". I don't know what the actual percentage is. Would be interesting to find out.

[sfan5]

MTG isn't going anywhere and if no longer shipped with the engine it will be added as a game in CDB.

[rubenwardy]

https://content.minetest.net/packages/Minetest/minetest_game/

It doesn't really make sense to distribute default externally, as it's essentially MTG itself.

Work should be done to add APIs and encourage not depending on default. Cross game support is hard though, so most mods only support one game and can then be ported to other games

[AntumDeluge]

Something that might be helpful (if not already implemented), would be an ‘or’ option in dependencies. So we can write mods as alternatives to default.

Though this can already be done using soft dependencies with global or mod path checks, I don’t think it is used very often. Mods just add default as a hard dependency. Many mods only depend on default for its sounds.

[Oblomov]

Or maybe allow mods declare a “provides” specification?

[triplehx3]

This page https://github.com/minetest still states Building an open source voxel game engine and game, However if MTG is maintainance only and not actively developed is this statement entirely true?

[appgurueu]

This page https://github.com/minetest still states Building an open source voxel game engine and game, However if MTG is maintainance only and not actively developed is this statement entirely true?

Maintenance qualifies as building IMO, although perhaps less emphasis should be put on the game.