Minetest: Hide or discourage mapgens in main menu on subgame request

[Wuzzy2]

There are some subgames which are mostly designed to work with only a subset of the available map generators. Subgames might either perform poorly with the “wrong” mapgen or simply don't work at all.
One example is Pixture. The recommended mapgen is v7, and v6 is strongly discouraged for Pixture.
Other subgames completely overwrite the mapgen choice. But in the main menu, the user still has the illusion of choice. Restricting the mapgen choice often has legit reasons. Either other mapgens would simply never make sense with this subgame, they don't work well together or the subgame is entirely singlenode-based.

I think Minetest should allow subgames to specify a list of mapgens for the user to be selectable. Additionally, it should be possible to list mapgens which technically work more or less, but do not provide the best gameplay experience as “discouraged”. For example, if the subgame's mapgen gives poor balancing results in v6 but v6 still works good enough to not outright disable it, v6 can be called “discouraged” which means a small warning is displayed in the world creation dialog.

The scope of my suggestion is basically ONLY the main menu, specifically the world creation dialog. Configuration and world data files are still taken seriously. The goal is to not clutter the world creation dialog with mapgens which in reality are never used in the subgame.

This new feature will also mean a comeback of singlenode in the main menu, but only for those subgames which allow it.

Examples:

• SkyTest: This subgame currently overwrites all mapgen settings of the user and forces singlenode. Which is of course a direct contradiction to user request (e.g. v6 selected). With this suggestion implemented, SkyTest can list singlenode as the only available mapgen.
• Minetest Game: No changes neccessary.
• Pixture: Only specifically designed for v7. It also is apparently completely broken for v6. So this subgame would remove v6 and discourage all mapgens except v7.

Specification. Subgames specify their mapgen preferences in game.conf with two new variables:

• available_mapgens: Comma-separated list of mapgens which are available. Default is v5, v6, v7, flat, fractal, valleys, i.e. the current mapgen list in Minetest 0.4.14
• discouraged_mapgens: Comma-seperated list of mapgens which are discouraged. Adding unavailable mapgens into this list will be ignored. Default is empty.

[Ferk]

In my opinion, the whole World creation window should be provided by the subgame, and the ability to select a mapgen in that dialog should be something MTG-specific.

Other subgames might want entirely different settings to be available when creating their world, so it would be great to be able to have custom options in the new game window for those subgames.

Even the "seed" field might not be needed for a singlenode game that intends to have a deterministic map generation, like the tutorial game for example.

[Wuzzy2]

I am not against subgames overwriting the mapgen. I am just proposing that this is properly communicated to the main menu. How is this not an improvement?

IMO the fact that you can select v7 when in fact this mapgen is impossible in the current subgame is a bug. Therefore, neccessary. That's why v7 should be hidden in this case.

Especially if the player got the subgame from somewhere else than the forum thread, the argument that players are aware of every technical detail does not hold. Also, most players are not aware of the inner workings of Minetest, let alone the fact that subgames can overwrite mapgens, which you kinda seem to assume.

and often state that this happens,

No, _subgames_ themselves can currently not state this (by e.g. game.conf). That's the point! It is only very indirectly stated in a forum thread (if at all).

In my opinion, the whole World creation window should be provided by the subgame, and the ability to select a mapgen in that dialog should be something MTG-specific.

I think your suggestion is going a bit too overboard. I don't think subgames should gain full control over any part of the main menu. A single broken subgame could then break the main menu, and this is a no-go. But what I would be OK with is giving subgames more options/parameters to add, but only through config files (like game.conf) and without any code, to keep things simple.

Restricting mapgen choice ONLY to Minetest Game is very lame IMO. There are many forks of Minetest Game which are very similar, so they would want a full set of mapgens (except singlenode) as well. My suggestion was more generic and will cover all possible subgames.

Other subgames might want entirely different settings to be available when creating their world, so it would be great to be able to have custom options in the new game window for those subgames.

I am OK with this, but I feel this deserves a new issue.

Even the "seed" field might not be needed for a singlenode game that intends to have a deterministic map generation, like the tutorial game for example.

This is a good idea. A simple show/don't show option for game.conf (see above) could be added.

[Wuzzy2]

Note: I am currently trying to implement this. I report back when I fail or succeed.

[rubenwardy]

:-1: Unnecessary. Subgames can and should already override and set the mapgen, and often state that this happens, so the player will understand why their choice is overriden.

This is bad UI/UX imo. Why offer a mapgen they can't have?

[zeuner]

I think it's a good thing to preserve the possibility of combining different mapgens with different subgames where possible. So, I would also prefer the possibility to make information about subgame/mapgen incompatibilities explicit rather than having the subgame override the choice silently.

[paramat]

I'm neutral on this now.

[rubenwardy]

This can be done by reading the subgame's game.conf when a new subgame is loaded, and putting (recommended) after some

hidden_mapgens = v6
recommended_mapgen = v7

show hidden mapgens in grey with (not allowed by subgame)
show recommended in pure white with (recommended)
show others in slightly off white (#f0f0f0?)

It may be worth doing #5332 instead though, less complex

[zeuner]

I think #5332 and the recommended/hidden settings are orthogonal to
each other.

original message follows:

This can be done by reading the subgame's game.conf when a new
subgame is loaded, and putting (recommended) after some

hidden_mapgens = v6
recommended_mapgen = v7

show hidden mapgens in grey with (not allowed by subgame)
show recommended in pure white with (recommended)
show others in slightly off white (#f0f0f0?)

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-336975691

[Ezhh]

The ability to limit which mapgens are available for a subgame would be very helpful.

[zeuner]

Recommending or discouraging mapgens for a subgame may improve user
experience. Completely making them unavailable may hinder development
(in order to improve mapgen/subgame compatibility), though.

original message follows:

The ability to limit which mapgens are available for a subgame would
be very helpful.

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-343615560

[Ezhh]

@zeuner The issue is that I am currently working on a subgame, but v6 doesn't handle biome registration as other mapgens do. I have been advised (including by a developer) to simply not support v6, so if a player selected it, the result would be an extremely broken and unusable map, which would make my work look broken as well. If I can disable v6, there is no danger of a player getting a broken map and what I release will work in full. v6 presents a problem to anyone focusing on biomes. (Check the ethereal mod for example - it notes it's not to be used with v6). I can't see v6 itself being changed to address this.

If a mapgen is simply incompatible with a subgame's intentions it isn't an issue of hindering development; it's one about the game creator being allowed to make decisions about how their game works.

[rubenwardy]

As a temporary fix, you can use the get mapgen info function and check the mgname, and then crash:

assert(minetest.get_mapgen_info().mgname ~= "v6", "Mapgen V6 cannot be used with this game. Please choose another Mapgen")

Not sure about the function name there

[Ezhh]

That will help, though it's really not ideal. If something is not usable, it should not be an option to begin with.

[rubenwardy]

Hence why I said temporary fix. This issue should become a thing

[Ezhh]

Seems it needs to be:
assert(minetest.get_mapgen_setting("mg_name") ~= "v6", "Please choose another Mapgen.")

[rubenwardy]

Ah, I was thinking of minetest.get_mapgen_params().mgname but that one looks better

Also, mgname vs mg_name? Grrr

[paramat]

That's old API, use 'get/set mapgen settings' instead.

Here's how to override the selection of mgv6 and force mgv7 in this situation:

local mg_name = minetest.get_mapgen_setting("mg_name")
if mg_name == "v6" then
    minetest.set_mapgen_setting("mg_name", "v7", true)
end

Since we have a reasonable workaround i think this is low priority.
A subgame can state what mapgens it is meant for, but when someone selects the wrong mapgen this code will reset it to a default, therefore not giving a bad impression.
I would prefer this workaround is used than add code to have subgame filter available mapgens, but still feel somewhat neutral.

[Ezhh]

@paramat Why favour a workaround over a subgame being able to decide what mapgens it should have available?

This workaround isn't ideal. For example: if a player learns they can't use v6 with a given subgame, maybe they'd prefer valleys, only to be given v7 instead. Some players don't like v7's "weirdness", whereas others would want to avoid valleys because there's not many flat areas. That should be player preference and this workaround would deny them that.

[paramat]

For code simplicity and because we are always inevitably short on core dev time.
If a user selects mgv6 against the subgame documentation then that's their own fault, at least nothing crashes and the mapgen is reset to one that works well.

[Ezhh]

I'm sorry, but limited dev time isn't a reason to be in favour of a poor solution. You are not automatically expected to do everything yourself, and there are other contributors outside the development team. This is even something I'd probably look at myself eventually if no one else attempts it, though I obviously can't say I'd be successful until I look at the code.

Reasons against using your workaround:

1. It shows players an option they can't have.
2. It fails to communicate in any way that they can't have it.
3. It then removes all choice from them if they select it.

This is just bad design.

[zeuner]

Looks good. If necessary, a warning message could be printed when
overriding the selection.

original message follows:

That's old API, use 'get/set mapgen settings' instead.
Here's how to override the selection of mgv6 and force mgv7 in this
situation:

local mg_name = minetest.get_mapgen_setting("mg_name")
if mg_name == "v6" then
minetest.set_mapgen_setting("mg_name", "v7", true)
end

Since we have a reasonable workaround i think this is low priority.
A subgame can state what mapgens it is meant for, but when someone selcts
the wrong mapgen this code will reset it to a default, therefore not giving
a bad impression.
I would prefer this workaround is used than add code to have subgame filter
available mapgens, but still feel somewhat neutral.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-344458145

[paramat]

Changed my opinion again, if you consider a game runing on a game engine, restricting the mapgens is fairly obvious, removing label, i'm not opposed.

[Ezhh]

@paramat Thank you.

I started looking at what's possible last night, but the barrier I'm running into is how to check the settings for an individual game from the mainmenu. I can have the mainmenu check what's in the main minetest.conf, but not what's in minetest.conf in the subgame. Am I taking the wrong approach?

[paramat]

Seems to me this info should be in https://github.com/minetest/minetest_game/blob/master/game.conf i think the mainmenu already reads that.

[Wuzzy2]

Thanks for picking this up again.
I made a PR a long time ago, but I basically gave up on it (sorry!).

[Ezhh]

@wuzzy Do you still have whatever you managed to do? I'd be interested in seeing if so.

[Wuzzy2]

@Ezhh: https://github.com/minetest/minetest/pull/4772

[zeuner]

I would disfavour a crash unless we could catch it from the main
menu. As far as I interpret the original point of this issue, it is
about avoiding a broken, mapgen-related state when starting a server.

original message follows:

You can use the get mapgen info function and check the mgname, and
then crash:

assert(minetest.get_mapgen_info().mgname ~= "v6", "Mapgen V6 cannot
be used with this game. Please choose another Mapgen")

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-344286270

[Ezhh]

Crash is simply the messy workaround that can currently be used, but isn't (in my opinion) a good answer. I will try and look at this, but it's messy, and I'm travelling/working a lot right now, so it won't be quick even if I do manage it. If anyone wants to try in the meantime, please do.

[zeuner]

So, to put things together, discouraging mapgens might work like this:

local mg_name = minetest.get_mapgen_setting("mg_name")
if mg_name == "v6" then
print("Mapgen " .. mg_name .. " is not recommended, falling back.")
minetest.set_mapgen_setting("mg_name", "v7", true)
end

original message follows:

Ah, I was thinking of minetest.get_mapgen_params().mgname but that
one looks better

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-344307284

[zeuner]

@Ezhh: Then it's a communication issue, isn't it? After all,
the subgame _is_ able to decide what mapgens to support since the
mapgen can be checked for.

So, in my opinion, optimizing this would be all about improving the
ways of the subgame to communicate to the player.

original message follows:

@paramat Why favour a workaround over a subgame being able to decide
what mapgens it should have available?

This workaround isn't ideal. For example: if a player learns
they can't use v6 with a given subgame, maybe they'd prefer
valleys, only to be given v7 instead. Some players don't like
v7's "weirdness", whereas others would want to avoid valleys
because there's not many flat areas. That should be player
preference and this workaround would deny them that.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-344464418

[Ezhh]

@zeuner Can you clarify what you mean? To be clear, I have no interest in discouraging mapgens (though if someone else wants to try that, that's fine...) because it makes no sense to me. I only wish to be able to either remove mapgens from the dropdown for specific subgames (when they are completely incompatible, as in my earlier examples with v6) or alternatively generate an error informing the user they should pick a different mapgen on world creation (not as good, but seems more likely achievable).

Digging into this code so far has shown me other issues I might try and figure out first, because it is all really messy. I am still wishing anyone else was interested in trying :)

[zeuner]

Would it be feasible to allow the server to post back information in a
structured way upon failure? This way, it would be up to the
mods/subgames to do whatever checks in order to ensure a valid state,
but the server starter can have it presented in a user friendly manner.

original message follows:

I don't know how to approach this.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-345064241

[Wuzzy2]

Hmm, this “discouraged mapgen” idea was probably too esoterical, because there can be many different opinions when to discourage (but not disable) a mapgen. Let's forget that for now. XD

I think hiding mapgens which are known to be broken in the subgame is already good enough.

Well, I just thought: If you in the config file just name every single broken mapgen by name, then this solution is not really future-proof. As soon a new mapgen comes out, and it turns out to be broken in the subgame, the user will again be able to select something which is broken. Unless the subgame is updated.

Maybe a special mapgen name “biomes” can be added to the config file. This special mapgen name is a shorthand for all mapgens which only work if your subgame uses the Biome API. This is a very common use case especially early in development, when you don't support the non-v6 mapgens yet (it's FAR easier to support v6 than to support the rest).

This is still not perfectly future-proof but at least it covers a common use case.

[Ezhh]

@Wuzzy2 Interesting idea and I see where you are coming from. The question for me here is whether or not the devs ever plan for there to be other mapgens that do not support the biome API. I suspect adding such mapgens would not be of huge interest given the difficulties with them.

As a secondary (but lesser argument)... for a game to stay up to date, you'd expect the creator/(s) to be actively updating it when/if such issues occur. If they are not being updated, there would probably be bigger issues than this anyway.

Please note that I am not looking to argue with you, and don't even really disagree with you, it's just that I'd be happy to see even a very basic system to prevent broken mapgens, and I'm worried even the simple ability to disable them might be a long shot.

[paramat]

Indeed 'biomes' is too specific, we will likely have more variety of mapgens with increasingly different ways of working. Just a simple blacklist or whitelist (whichever is better) of mapgen names is necessary.
Read game.conf and add the black/whitelist to that file.

zeuner what you write seems irrelevant, the main menu already knows what game is selected, and already loads information from that game, so it's possible for the mapgen selection formspec to know what mapgens to allow.

[zeuner]

@Ezhh: In this particular scenario, I disagree. Having the subgame
code deal with "bad" mapgen choices might encourage efforts for
compatibility on the subgame and the mapgen side, which would be
really valuable, and which would stress the sandbox characteristic of
the minetest platform.

original message follows:

That will help, though it's really not ideal. If something is
not usable, it should not be an option to begin with.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-344288504

[Ezhh]

@zeuner We will have to agree to disagree. A desire to not support a mapgen that is incompatible with the purpose or design of a subgame doesn't mean the subgame has made bad choices. If MT is meant to be a game engine, it should be possible for people to develop games without being tied to supporting every existing mapgen and any inconsistencies they have.

[paramat]

Having the subgame code deal with "bad" mapgen choices

No, that's messy, the mapgen should not appear in the mapgen selection dropdown.

[zeuner]

I'm not sure proactively blocking not yet known mapgens is a good
thing since you never know what the new mapgen will be like.

Checking for supported APIs seems to be an interesting thought,
though.

original message follows:

Hmm, this “discouraged mapgen” idea was probably too
esoterical, because there can be many different opinions when to discourage
(but not disable) a mapgen. Let's forget that for now. XD

I think hiding mapgens which are known to be broken in the subgame is
already good enough.

Well, I just thought: If you in the config file just name every single
broken mapgen by name, then this solution is not really future-proof. As
soon a new mapgen comes out, and it turns out to be broken in the subgame,
the user will again be able to select something which is broken. Unless the
subgame is updated.

Maybe a special mapgen name “biomes” can be added to the
config file. This special mapgen name is a shorthand for all mapgens which
only work if your subgame uses the Biome API. This is a very common use
case especially early in development, when you don't support the non-v6
mapgens yet (it's FAR easier to support v6 than to support the rest).

This is still not perfectly future-proof but at least it covers a common
use case.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-347578827

[paramat]

Yeah maybe the mapgen list should be a blacklist not a whitelist.

[Ezhh]

I was assuming blacklist from the start...

[zeuner]

If this gets implemented using [1], the subgame developers may decide
themselves how to manage it.

[1] https://github.com/minetest/minetest/issues/5332

original message follows:

I was assuming blacklist from the start...

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-348357829

[zeuner]

Thanks for the contribution towards a more generic sandbox game
platform.

original message follows:

Thanks for picking this up again.
I made a PR a long time ago, but I basically gave up on it (sorry!).

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-345137888

[zeuner]

@Paramat: But if there is no incentive for subgame developers to
provide comprehensive mapgen support, how will dead mapgen code be
prevented?

original message follows:

But then, if you consider a game runing on a game engine,
restricting the mapgens is fairly obvious, removing label, i'm
neutral.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-345051027

[paramat]

It's fine and acceptable for subgames to not support certain mapgens, doing so does not create dead mapgen code. Mgv6 is so different it can be very difficult to support that one. Subgames that are for use only in 1 mapgen are also fine.

[zeuner]

@Paramat: Ok, maybe not dead code as long as minetest_game is
considered an integral part of minetest rather than being separate and
interchangable with other subgames.

Still, for the sake of encouraging compatibility, I don't really
like it.

I wonder whether minetest_game (supporting different mapgens) can
serve as a reference for also achieving interoperability in other
subgames.

original message follows:

It's fine and acceptable for subgames to not support certain
mapgens, doing so does not create dead mapgen code. Mgv6 is so
different it can be very difficult to support that one. Subgames
that are for use only in 1 mapgen are also fine.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-349596417

[Ezhh]

@zeuner I don't consider MTG integral. I do consider it fully interchangeable. There is literally no point in making other games if they are not interchangeable. Producing another game, by definition, means not using MTG, so why should I need to support something that is contradictory to what I want to achieve with a game that has no connection to MTG?

[zeuner]

Hiding mapgen compatibility flaws leads to messiness of its own.

No doubt it's more work to support different mapgens, but it
avoids ending up with a lot of code which is badly interoperable
because it expects different mapgens.

[rubenwardy]

V6 doesn't support biomes, so it's impossible for subgames which are biome rich to support it correctly

[paramat]

as long as minetest_game is considered an integral part of minetest rather than being separate and interchangable

It's not integral, but is closely related because it has always been the 'official game', and is a base for many MT mods. It is separate and interchangeable because it is a game running on a game engine.

Still, for the sake of encouraging compatibility, I don't really like it.

We don't have to encourage compatibility, games are obviously free to support or not support any mapgen they want. Certain mapgens will be unsuitable for certain games.

I wonder whether minetest_game (supporting different mapgens) can serve as a reference for also achieving interoperability in other subgames.

It does already.

Hiding mapgen compatibility flaws leads to messiness of its own.

Mapgen incompatibility is not a flaw, and no-one is hiding it, we support it.

No doubt it's more work to support different mapgens, but it avoids ending up with a lot of code which is badly interoperable because it expects different mapgens.

Deciding to support a subset of mapgens inevitably results in a game not supporting the mapgens it doesn't support, and there's nothing wrong with that.
Forcing games to support all mapgens reduces the variety and possibilities of games, we are specifically asking for specialist games as alternatives to our very general and universal MTG.

[zeuner]

@rubenwardy: No doubt the mapgen choice may make the map look way
inferior. If it's not "v6", then maybe "flat". But the more
important question is: At what point does it affect the gameplay in a
significant manner?

[zeuner]

@Ezhh: But if minetest-game is fully interchangable with other
subgames, and those are not meant to provide full mapgen support, what
prevents the mapgen infrastructure from becoming an ever-growing heap
of potentially rarely used code?

If, on the other hand, all subgame designers were supposed to at least
take into account the different mapgens, they would become first-class
participants in the debate on what mapgens might deserve deprecation.

[Ezhh]

@zeuner You can't deprecate mapgens - servers are using them and there is no reason to. Different mapgens are simply suitable for different things, including suitable for different games.

Either way, I started work on this last night. No idea if I will actually get it good enough for a PR, but it's now in progress.

[paramat]

But if minetest-game is fully interchangable with other subgames, and those are not meant to provide full mapgen support

We are likely to always have an official game that supports all mapgens.

what prevents the mapgen infrastructure from becoming an ever-growing heap of potentially rarely used code?

Nothing wrong with that, our API is also a large amount of choices of which only a few are used by any one mod. Do you insist every mod uses all APIs? Nooo.

[zeuner]

@Ezhh: It is a common decision in software development to deprecate
features which are still in some use. Server owners may then decide
whether to stay on a bugfix branch still providing the features that
have been deprecated in the latest version, or to switch over to
features receiving more active development efforts, possibly making
some changes to their setups.

With minetest, a big issue would be that there is not yet a good way
to port an already existing map to a different mapgen, so I agree that
it's not an easy task yet.

However, being able to also drop less valuable features over time in
order to be able to allocate more developer time to the other features
is, in my opinion, a good reason to make decisions, so I disagree when
it comes to not considering something like this at all.

original message follows:

@zeuner You can't deprecate mapgens - servers are using them and
there is no reason to. Different mapgens are simply suitable for
different things, including suitable for different games.

Either way, I started work on this last night. No idea if I will
actually get it good enough for a PR, but it's now in progress.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest/issues/4768#issuecomment-351493849

[Ezhh]

@zeuner I did consider it. Mapgens should not be dropped. They all have uses and are in use (see paramat's comment). And even if there was call to drop any of them, it would be no reason not to have this feature.

It's of course ultimately not my decision to make, but I don't see a developer disagreeing with what I've said. Four separate developers actually reviewed and were happy with my approach to resolving this issue, as have been other community members who reviewed it.

I suggest that if you feel mapgens need to be deprecated you open a separate issue to discuss. This issue was for allowing subgames to control available mapgens, not for deprecating them and has now been closed.

[paramat]

If, on the other hand, all subgame designers were supposed to at least take into account the different mapgens, they would become first-class participants in the debate on what mapgens might deserve deprecation.

Forcing subgame creators to use all mapgens does not make them any more able to judge if mapgens should be deprecated, they can judge that anyway.
Besides, the 'deprecation of mapgens' debate is a non-issue currently, all of them are being used and all are valuable.
zeuner you're not making much sense in this thread, and seem to be overconcerned with non-issues.
Forcing game creators to support all mapgens is unenforcable and would be harmful for everyone, and would greatly reduce the number and variety of games.