We already have minetest.generate_ores() and minetest.generate_decorations() so generating biomes in an LVM is good to have. However it will be more complex to implement, maybe even too complex to be worth it, i don't know. I also don't know how to code this.

Feature creep: include an altitude adjustment parameter.

It could be handy for Multimap for obvious reasons, but even my own lua mapgen of floating islands was coded to use the biomes from ground level to avoid all the islands ending up in an alpine biome, so both my use cases would have benefited from a parameter like this.

A workaround if there's no altitude adjustment parameter could be to edit the biome table before calling generateBiomes(), then restore it immediately after, but that assumes no concurrent chunk gen.

Could it be this way?

• minetest.generate_biomes(vm) generates biomes based on biome noise parameters
• minetest.generate_biomes(vm, temp, humid) with temp and humid 80x80 lists of climate values, will determine the biomes based on these parameters
• minetest.generate_biomes(vm, biomemap) with biomemap a 80x80 list of biome IDs

That said, I haven't looked in details into the code and I have no idea how this could be achieved, or not. Just proposing.

There's a related issue where biomemaps currently aren't ever calculated in chunks that the C++ mapgen doesn't create stone/water in, and a generateBiomes() lua function would necessarily solve that too.

I'm very interested in this feature, and I've started thinking about it and coding some stuff. This is going to be part of my projects for the second covid lockdown!

After looking closely at the code, I can imagine several strategies:

• Creating a new Lua object (a bit on the style of LuaVoxelManip) that encapsulates a MapgenBasic instance. It could be used to generate biomes but also caves, and decorations/ores. The advantage compared to minetest.generate_decorations and minetest.generate_ores is that it could generate them consistently with biomemap, which, for what I know, is not possible for now. I started drafting some code today (far from working).
• Making MapgenSinglenode an instance of MapgenBasic instead of Mapgen (because it has generateBiomes and dustTopNodes) and creating functions in script/lua_api/l_mapgen.cpp that bind MapgenBasic::generateBiomes() and MapgenBasic::dustTopNodes() to Lua. Would probably work only for the latest chunk generated.
• Creating a new mapgen derived from singlenode (a singlenode_plus or like) that is specifically designed to generate biomes/decos/ores over user-generated terrain, and can be triggered by Lua.

What do you think about this?
I'm probably not experienced enough to do all the code alone, so feel free to give advice or join me, especially for what's about the Lua binding API that is still obscure to me.

Treer,

Feature creep: include an altitude adjustment parameter.

Please no =) In the past i went in this direction twice and both times later realised it was a mistake and had to revert it.
Biomes should simply be registered to have the desired result, they should apply consistently everywhere. This might require a little more work from a modder but it is actually less headache and complexity overall.
Having little pockets or world where biome definitions act inconsistently is just wrong.

Gael-de-Sailly,

It could be used to generate biomes but also caves

I think this is low priority and probably not worth doing, as Lua mapgens that generate terrain usually want to generate caves too. Caves are basic terrain and the point of Lua mapgens is to have the freedom and flexibility to generate terrain how it wants.
A Lua mapgen wil not be slowed down much by having to generate its own caves as opposed to using C++ cavegen.

The advantage compared to minetest.generate_decorations and minetest.generate_ores is that it could generate them consistently with biomemap, which, for what I know, is not possible for now.

I am not sure this is worth the effort. Those functions currently do not function with the biomemap, but are meant to be used in a different and specifically designed way.

I have no objections to a simple-as-possible minetest.generate_decorations and i support that, but i am unconvinced about such a complex approach as you describe.

It seems to me that Lua mapgens usually want to have as much freedom as possible to do stuff different to the engine, with simple and limited-capability helper functions like 'generate decos/ores/biomes' optionally added.
I disagree it is important to have the ability to create a terrain surface in a Lua mapgen and then have everything else run as a C++ mapgen.
Mapgen parameters are so powerful we can already flexibly customise core mapgen terrain.
Those talented enough to code Lua mapgens usually want to do as much as possible in Lua and want that to act differently to engine mapgen.

So to be clear, i support the simple initial request, but not your suggesitons.

So to be clear, i support the simple initial request, but not your suggesitons.

The thing is, for what I've seen, there doesn't seem to be an easy way to achieve this initial request, without, in one way or the other, building specifically a whole MapgenBasic instance to be exposed to Lua.

If we do this effort to expose MapgenBasic::generateBiomes() to Lua, there will be little extra work needed to give access to other member functions of MapgenBasic like generateCavesRandomWalk(), so I was saying this could be done, but we don't have to do it.

Generating custom terrain while using the standard biome system can be wanted to test original mapgen concepts that can't be reproduced using standard mapgens, but to keep them compatible with mods that register biomes, plants, etc.

I started coding again in this direction and today I got something that works on my lua_generate_biomes branch.

I tested it on a modified version of Paramat's lvm_example. It has some problems at chunk borders but I think they are due to my Lua code.

I tried to stick to the lightest possible changes but I still had to tweak some class definitions a bit. My approach creates a temporary instance of MapgenBasic, the same way minetest.generate_ores does with Mapgen.

There are still some things that need to be changed or tested before opening a PR but I will surely do it. I'd already be interested to know whether you like the concept or not.