4aiman wrote:In my "fork" of Nore's mg mod I'm making flat area for each building. I copy the nodes there were and copy them up to 10 times. If there were no nodes below for 11 or more meters, then I use default:cobble as a basement material.
Ah! I took a similar approach at first - caching some nodes and copying them up if the area was too low. That approach however proved to be non-working under the circumstances that exist at mapgen time. That is, it did work. To a degree. But...those "copies" of buildings burried below the village where really really odd :-) I'll explain later on, but: this approach can't be recommended.
4aiman wrote:This way I always have the same nodes that were there before my "manipulations". Look at the picture:
That I aim at to a degree as well - and it does work. The default:dirt and default:dirt_with_grass withhin the buildings is replaced by whatever ground node the biome comes with. If it's for example desert sand, then there will also be one more desert sand below, and below that there'll be desert stone. And similar for other biomes where I know the structure of (i.e. dark red baked clay on top, orange baked clay below for one ethereal biome). I do not keep plants or "hills". The area around the village is a bit special and filled up with wheat, cotton or the occasional grass/dry shrub. This is intentional for my villages - I want them to have diffrent vegetation there. Seems you have other preferences :-) However, keeping the original plant might under some circumstances be a good idea. Especially if the ground cannot be turned into soil and is therefore left alone by my mod.
4aiman wrote:As you can see, all the buildings are on their own altitude.
Buildings need to be spaced further appart for that to work. By default, there's only one block between two buildings. That's not enough for any significant height changes. But that can be configured.
4aiman wrote:structures try to adapt to biomes, thus using desert stone in desert instead of cobble
As explained, that happens in mg_villages as well. Ethereal required some special adaption there (=the mod needed to be told which nodes may be considered dirt with grass replacements).
4aiman wrote:memorizing villages positions
Same here, although that is mostly for further usge. The /vmap command shows a map of villages.
4aiman wrote:loot in chests
Coming soon, but as I said, that needs to be adapted anyway :-)
4aiman wrote:flying villages
I've limited villages to the ground chunk in order to speed up mapgen. As long as there are no two villages abvoe each other, there's nothing which ought to prevent flying villages. They may need a diffrent terrain blending algorithm as there's no terrain to blend into. Perhaps that part could be left as air.
4aiman wrote:water-villages (those right above the water with channels instead of roads)
Impractical. Leaving water and entering a house will become tricky for players. And those poor mobs which might want to run around there would drown!
4aiman wrote:basesments for every building (so those do not hang in the air)
Hmm, I used to construct platforms for the random_building houses. Terrain blending IMHO looks nicer and works better. People have to get to the front door somehow. Basements as such are of course possible. Some of Taokis houses have them. The ones from Nore are mostly too small to warrant a ceallar.
4aiman wrote:potentially, underground villages
Might range from incredibly difficult to almost trivial, depending on what exactly you have in mind.
4aiman wrote:The thing is, LVM is too buggy, does not consider decorations, fail to save structures from mapgen's caves, collides with other LVM usages (one may want to use only ONE LVM if he/she wants consistence, since LVM copies a part of a map and then writes it back, no one can really tell which LVM would be the one to "win" and preserve it's changes), does not set is_generated flag (so mapgen may not know there's something already generated!), takes more memory than minetest.set_node() etc etc...
I'm using the LVM version that is available in the on_generated call - same as Nore did. By now, it works pretty well. And after some talk with Hmmm and Paramat, I managed to understand mapgen sufficiently to undo most of the cavegen griefing and mudflow spam. The combination of voxelmanip, schematics and set_node was too much, but with voxelmanip alone, I'm quite satisfied with the result.
The essential point about mapgens is that they have to be reproducable. When a chunk (usually 80x80x80 nodes) gets thrown at your mapgen, it always has to answer with the same result. A misplaced plant here and there may be less critcial, but plain random cannot be used. It all has to be created using some form of pseudorandom functions.
What is beeing worked on in on_generated is not only that 80x80x80 nodes area (or diffrent with diffrent minetest.conf), but an area slightly larger - usually 111x111x111 nodes. That is, 16 nodes are added at each side and overlap with other mapchunks. This overlapping is used for cavegen and mudflow. Even if the area in that "shell" hasn't been generated yet, it will afterwards contain nodes that are air (where a cave from this chunk extends into its neigbouring chunk and a future cave will be). When we get a mapchunk in on_generated and work on it (place our villages inside), that is fine so far - the caves in that chunk have been generated before the on_generated function has been called, and our flattening algorithm will make sure that there won't be any open caves left on the surface for visitors or mobs to fall in. So far so good. Now a neighbouring chunk is generated. 16 of its nodes will overlap with our already generated chunk - and cavegen will happily eat holes into the houses (unless they consist of material where ground_content = false) and spill mud on whatever will be in the way. Using is_ground_content=false for all building materials for the houses - effectively creating copies of all the nodes in order to be sure - would be possible but also spam the server with nodes. What we can do in order to get rid of the undesired caves and mudflow is to not only generate the central 80x80x80 nodes, but also those in the shell. In order for that to work, we have to make sure that the area is generated exactly the same each time it needs to be generated.
That approach above will restore the buildings. There might still be holes left below/next to the buildings. In such a case, the information about what type of node was "ground" there may have been lost (cavegen ate the ground node). In such a case, I'm still searching for a possible ground node (perhaps it can now be found on the cave's floor) and use fallbacks if nothing suitable is found. This approach is not 100% reproducable (diffrent input, diffrent output) and may lead to parts from previous buildings beeing considered as new ground. That's not particulary nice, but acceptable. Some diversity for villages is ok.
Mudflow is eliminated by removing nodes which are suspected of beeing mudflow (dirt, dirt with grass, sand) and which are located above the village ground. Those are set to air. After the repair of holes from cavegen and elimination of mudflow, the houses are placed again. See also mg_villages.repair_outer_shell
place_schematic ought to be avoided in this particular case. It is a very practical function, and in effect I had to recreate what it does. The function place_schematics loads and forces creation of not yet existing chunks when necessary. This may lead to a chain reaction if buildings in your village reside on the border between chunks. Doing everything through LVM is much cheaper in this case.
4aiman wrote:But the only thing I really want to figure out is how one can use perlin noises to get a number of positions to spawn vilages that are not connected.
PS: It's true, that there is this kind of a code within Nore's mg and therefore my villages, but I don't understand it. Anyone care to explain?
I didn't change that basis. The positions for the villages are determined by Nores code. Perhaps Nore and/or Paramat can explain how it works in detail :-)
Hope my explanations of mapgen help you a bit.