FOSS gamedev and creative worlds

I try to understand how mintest generates a map. A map consists of nodes. The next bigger unit is a block, containing 16x16x16 nodes. The largest units are mapchunks, containing 5x5x5 blocks or 80x80x80 nodes.

There are also sectors, but I never saw them used in code.

The mapgen generates the world mapchunk by mapchunk. If I register a generator with registered_on_generated the generator is called each time a mapchunk should be generated. He gets the world seed and two coordinates, often called minp and maxp.

The mg calls get_mapgen_object("voxelmanip"), which returns an vm object and two coordinates, often called emin and emax

My first questions:
Did I get that right so far?
The mapgen only stores the ID of a node as integer, params are optional. Is that correct?
What is the difference between minp/maxp and emin/emax? What do they mean?

If I understand this part I will continue with the next questions

burli wrote:Did I get that right so far?
The mapgen only stores the ID of a node as integer, params are optional. Is that correct?
What is the difference between minp/maxp and emin/emax? What do they mean?

Your understanding matches mine.

The minp/maxp refer to the limits of the chunk that's being generated. However, the system gives you almost twice as much data, to allow for placing big objects (trees) that happen to be on a chunk border. The emin/emax show you the limits of the actual space you're working with. However, using anything outside of minp/maxp means that you will be setting data in a chunk that hasn't yet been generated or was already generated, so it creates the potential for all sorts of complications.

When I created city blocks in Cityscape, I would constantly end up with pieces of trees that had been generated by the real mapgen at the edge of another chunk, even when I was overwriting every node in every chunk. The schematic code uses the overlap to make terrain look natural, which works wonderfully in a homogeneous world, but not so well when you want discrete pieces. My solution was to disable all schematics and place the ones I wanted manually with my code.

This is my first modification of a mapgen, trying to understand how they work. The bright lines are the borders of the mapchunks, 80x80x80 nodes.



Some of them are broken. Don't know why



In snow biomes only one of the lines are covered with snow.

The general description of how mapgen works is correct. However, as duane already pointed out, there are further effects. One of them is the overlapping with neighbouring mapchunks that has already been described. It is a 16 node wide "shell" around the actual mapblock and allows such structures as caves and dungeons to extend into the next mapchunk. Neighbours that have not been generated consist of "ignore" nodes, with only the caves and whatever else extends into them beeing set to air or other nodes.

A second effect - which might be the cause of burlis observations - is the so-called "mudflow". The borders between chunks are smoothed by dirt "flowing" around a bit. This usually affects a two-node wide strip. Old mapgens used to have one-node wide ditches at chunk borders.

In general, if you're writing a mapgen, be prepared to create reproducable chunks whenever mapgen throws coordiantes at you. Use procedural generation instead of pure randomness.

My mg_villages-mod is aware of both effects. Schematics for the houses are read as files and placed using voxelmanip instead of place_schematic. Some functions need to work on the entire mapchunk - including the outer shell that overlaps with neighbours. Mudflow withhin the village is detected and the dirt that flew in removed. Caves that digged through houses are filled with the house-material again. Even without that, nodes that have is_ground_content = false will not be eaten by mapgen caves. But that is not possible for all materials (some need to be removed by caves in other situations; imagine i.e. a house out of stone vs. stone underground), so automatic repairs are beeing done where needed.

burli wrote:This is my first modification of a mapgen, trying to understand how they work. The bright lines are the borders of the mapchunks, 80x80x80 nodes.

My advice, to really get a feel for it, is to go to singlenode while you're experimenting. That way, oddities like we mentioned above don't interfere. Once you've got a handle on how to generate terrain, then you can try to coordinate with the existing mapgens (though it's often easier to do it yourself).

Thanks for the explanation, Sokomine

How can I select Singglenode? Ist is no longer selectable in the current dev

burli wrote:How can I select Singlenode? Ist is no longer selectable in the current dev

You must change it manually. Create a regular world with any other mapgen, then open worlds/your_world/map_meta.txt and change the value of the setting "mg_name" to "singlenode".

> How can I select Singglenode? Ist is no longer selectable in the current dev

See https://gist.github.com/paramat/feb2361da106371652ad

Thanks for your help. Now I have another question.

In which order the mg generates the map? Terrain first, then plants and caves last? Because some cavegens generate some ugly bugs like flying plants or strange water flows if they cut the surface

burli wrote:In which order the mg generates the map? Terrain first, then plants and caves last? Because some cavegens generate some ugly bugs like flying plants or strange water flows if they cut the surface

Usually terrain first, plants last (afaik). The screenshot looks as if a cave ate through the already generated area of a neighbouring mapchunk. But I thought that the problem with floating plants has been taken care of?

> The screenshot looks as if a cave ate through the already generated area of a neighbouring mapchunk.

Yes this, you can see a straight mapchunk boundary, so the large cave has overgenerated into a previously generated neighbour mapchunk and removed the terrain from under the plants. Unavoidable bug. Plants are of course only ever placed on specific nodes.

You can see order of mapgen in 'makeChunk()' https://github.com/minetest/minetest/blob/master/src/mapgen_v5.cpp#L242

Sokomine wrote:My mg_villages-mod is aware of both effects.

Can you show me the code for this, please? Will take a look how this works, especially the mudflow.

burli wrote:Because some cavegens generate some ugly bugs like flying plants or strange water flows if they cut the surface

The version 6 caves are, I suspect, especially vulnerable to this because they're generated randomly. When you use noise functions to generate terrain, the same data is available to all neighboring chunks.

It's not impossible to fix, but I doubt it would be worth the effort. You'd have to replace every use of random functions with noise and add code to generate at least part of the caves in every neighboring chunk... or you could figure out some way to rewrite the whole mess using just noise and somehow make it look the same.

math.random is used 44 times in your lua v6 cavegen. Would be a callenge to replace them with a noise. Especially there are totally different ranges used

The thing is, I really like the v6 caves. v7 caves are to rare and much to often to steep to make fun.

Hmmm....