Multi Map allows subgame devs/ mod devs/ mapgen devs to create multiple worlds or "extend the world area" by stacking them on the Y axis. As such it can be used to:

Virtually extend the world area by allowing the same mapgen logic to be called for multiple layers, albeit with a completely different noise hence creating different terrain. The world area extension is then faked by layering these extensions on the Y axis

Alternatively it can also be used to implement multiple worlds, each having its own type of terrain or mapgen logic. E.g. underground worlds, sky worlds, desert worlds, lava worlds, jungle worlds, alien planet worlds, all within the same game/ on the same server

Offer a consistent way of dealing with multiple layers by offering a map generator plugin system and "global noises", rather than having multiple mods doing things differently each time, each having its own noises, etc.

Basically, reclaim "unused" space on the Y axis and allow this to be done in the easiest way possible, provided compatible map generator plugins are available. If not, you will have to roll your own of course, but by sharing the plugin it can be reused easily by others via the multi_map framework

Solve some common problems such as shadows, underworld/ overworld lighting, relative to layer Y positions, etc. when dealing with multiple layers

Heavily inspired by paramat's floatlands, duane's underworlds, the desire of some in the community to have a larger world and to better use the Y space, multi_map is part mod, part map generator and part framework, and can be found here (modpack):

Warning!! Do not use this on existing worlds. Make sure you set the water_level to -31000 and mapgen to singlenode. Also, at this stage it is very bare bones and still requires a lot of work, especially on the map generator plugins ...

Pics or it didn't happen (mapgen used for the screenies is a modified levels mapgen by Mr. Mapgen himself, paramat):

+
"Pictures"

Two layers close together, cross section to show the cake like layering ;) Note the repetition of the ocean, each layer can have its own! Also note each layer's underground darkness as opposed to the overworld lightness:

Looking down at three layers, again each layer with its own ocean. Shadows are stopped from propagating using some trickery ;)

On the ground terrain of layer 19 close to absolute Y = 0. In the bottom right it shows the "zone" in which the player is as well as the Y coordinate relative to the current layer:

On the ground terrain of layer 20 called "Remote Levels Land". Note the type of terrain is the same yet the noise is completely different. Also note Y = 1932 on the top left, however Y = 44 relative to layer 20!

The bottom of the layer, showing some exposed impenetrable bedrock to avoid falling down to the level below:

List of planned and implemented features:

+
"Features"

The ability to create unique terrain per layer via global 3D or 2D noises, where the 2D noises are made unique per layer: Done

Optional "bedrock" layer provided by the framework or the abilty to set your own bedrock type layer: Done

Optional invisible impenetrable "skyrock" layer to avoid seeing the bottom of the next layer up: Done

Hooks for custom terrain generation logic per layer: Done

A few demo/ usable map generators: Only very partially implemented (levels, simple, testauri)

Optional mechanism for travel between the worls (i.e. portals), but of course it can be switched off and subgame developers can implement their own travel mechanism or integrate existing portal mods: Planned

Customizable number of layers and an optional zoning system allowing sane display of coordinates (e.g. coordinates displayed as "Zone: 6; Position: 10.5, 15.0, -18.4" where the Y is offset based on the zone to show "sane" coordinates). This will not change the debug coordinates of course, just something to show on the HUD: Done

Pushing zone information as parameter for terrain generators, e.g. allowing different map generator code per layer (besides the obvious changes one can do with the perlin noise parameters), different biomes and decorations (e.g. jungle zone, desert zone, etc.), etc.: Done

Pluggable decorators and ore generators, again with zone information supplied so it can be changed or tweaked per layer: Planned

I am seriously thinking about an (optional) mechanism to automatically teleport players from the edge of the world on one layer to the opposite edge of the next layer. This in order to effectively create "smooth" transitions and truly give the experience that the world is larger on the XZ axis. To this end I will investigate "mixing noises" of the two layers on the world edge to also support smooth terrain transitions: Considering/ planned, needless to say this is not trivial... Partially done, works for edges but not yet for the world corners

Last edited by Beerholder on Wed Aug 08, 2018 05:16, edited 4 times in total.

The mod idea is promising - but I'm missing something. How would I register a new layer from my Lua mapgen using this mod? Increasing the variable `multi_map.number_of_layers` by one sounds quite dangerous since it might offset all other registered layers.

Krock wrote:The mod idea is promising - but I'm missing something. How would I register a new layer from my Lua mapgen using this mod? Increasing the variable `multi_map.number_of_layers` by one sounds quite dangerous since it might offset all other registered layers.

I must admit I haven't had a chance to document this properly yet, sorry about that :( But it's most def a valid concern Krock. I'll give a couple of scenarios with examples (and copy that to the wiki):

Increasing number_of_layers by one should not be a problem, as it will stack on top of other layers. But as with changing normal parameters for other mapgens, there are some destructive operations. E.g. suppose that I have the following in init.lua in multi_map_generators:

This is still fine, as an additional layer of the simple singlenode generator is just added on top, unless you had visited this layer 1 before with e.g. fly/ noclip in which case it would break for the areas already visited or require you to regenerate the area. However, if you were to change the layer height to 21:

This would most def be destructive to existing worlds, and the layers will start to misalign. There will be a sharp 80 node high border in the singlenode world (as well as in the bedrock/ skyrock in the layer below). And if you had even more layers, it would cascade to the layers above, getting more and more misaligned with each layer.

Other things that would be destructive is to change the generator plugin for a layer, e.g. change the levels mapgen to something else, changing the start chunk. One more that is upcoming is "noise mixing". This allows a layer to wrap to the next, and does so by mixing its noise with the noise of the next. Add automatic teleportation and you "wrap" from one layer to another, as if the world does not end at the world border.

Anyways, was there any particular scenario you had in mind that could break things unintentionally using the mechanism I devised? Would it maybe be better if I write a multi_map_meta.txt with the settings in the world directory? Or is it the current lack of documentation and did I just forget to add big warning signs for changing certain settings on existing worlds? I must admit that the use of this mod requires careful planning ahead.

For me it was simply not clear on how I could register a new map layer. I imagined there could be an API to register a layer with an unique identifier and a custom thickness. The multi_map mod would then check the world configuration and insert a new layer where's free space in the world when the layer didn't exist previously. Or it would return the minimal/maximal coordinates of the layer directly so that they could be used in on_generate to calculate where the new "sea level" of the layer is.

I'm continuing to keep a close eye on this project. Beerholder mods are always above and beyond impressive :)

Quick question: Is there any reason this multi-map concept couldn't eventually be implemented as a C++ mapgen wrapper? It seems like an essential feature. And being integrated into the engine, you could certainly overcome some of the notable obstacles (like the global F5 coordinates, the bedrock in the sky, etc.). Of course, that might also require changing the client-server protocol, but I'm not sure.

I realize you've already invested a lot of time on this, so I don't want to sound like I'm pushing you in a different direction. Just genuinely curious is all!

sorcerykid wrote:Quick question: Is there any reason this multi-map concept couldn't eventually be implemented as a C++ mapgen wrapper?

Actually, this could most definitely be implemented in C++! To be honest, I started working on a subgame, so I just started writing it in Lua. C++ did not even cross my mind...

I should probably iron things out in the Lua version first as my C++ is still a bit rusty ;-) and some of the logic is sort of mind bending, kinda like the Inception way with the layer wrapping I am working on now O_o

So yeah, when I iron out the bigger design of this mod (e.g. Krock's comment made me think whether there should be a per layer height instead of a global one for all layers), have a reference implementation in Lua, something that works, some more feedback, I should most definitely investigate porting this to C++.

I like the idea as it could potentially also solve some memory and performance problems that I am worried about. The noise mixing especially concerns me, as it requires sets of noises (base terrain, mountains terrain, temperature, humidity, caves, etc.) to be duplicated at the border (and they might even have to be tripled at the world corner ... O_o) LuaJIT might not like that ... ... ...

Hi all, I will be traveling for 3 weeks starting Wednesday. So a small update before I leave:

Documentation, documentation, documentation. I spent a lot of time writing documentation. Every day a little bit, and now I have 50 articles in the wiki. Then again, there was a lot to document and it was badly needed for a mod like this. Right now most if not all things you'd normally have to deal with are documented. And some of the things you should not need or even touch are documented as well

The levels mapgen has been fully ported now (it was only done partially sort of, not using all the multi_map features)

Layer wrapping works, but *on world edges only* :-( Next major challenge will be to mix and mirror noises at world *corners*. That I will look into when I am back. P.s. if you link a layer to itself, it does actually wrap you around to the opposite edge :D

Bedrock and skyrock can now be specified globally and per layer

Some fixes such as miscalculations, but I also removed the "nolight" parameter as I thought it would not be necessary. This broke the lighting I had worked so hard on to make it work, whoops ... O_o

Code updates haven't progressed as much as I would like and my todo list is getting longer instead of shorter -_- Guess writing the documentation and prepping for travels took most of my time. But in the meantime please always feel free to comment, give it a testrun, give feedback etc. It'll just take a while before I reply ;-)

DrFrankenstone wrote:Valleys mapgen adjusts the temperature and humidity, this leads to oasis or greenery following rivers, and some mods are tuned for it.

<snip>

Is it worth attempting to get lua humiditymap objects writeable, so multi_map API can affect biomes?

I should look into this, but this concerns the noises provided by core/ C++ mapgens. It would be logical then to also do the noise blending in C++ but that is opening a whole can of worms and would only be applicable when porting multi map to C++. From a Lua perspective, writing the humidity map would not make sense.

Multi map does not write the maps is blends but only gets the two maps from opposite sides and returns the weighted averages. For the humidity map that would mean one would have to call a wrapper to get the noise, allowing multi map to decide whether the humidity map itself is returned, or a blended version. Unfortunately that means changes to mods making use of e.g. the core's humidity map :( To write the map might mean too much back and forth between Lua and the C++ map, impacting performance.

I did have a look at the Lua version of the valleys mapgen, I could try and make a multi map compatible version of that. But regardless, the engine's noise maps (humidity, temperature, etc.) are all food for thought :)

This mod seems to be answering exactly what I needed!You have added LOTS of documentation, which is wonderful! BUT, I'm stupid, and having trouble following the documentation, sorry.

So when the wiki says "The layer would be 20 chunks high"What exactly does that mean? will it be 10 chunks (800 nodes) of dirt, and then 10 chunks (800 nodes) of air?Is there a way, (or are you considering adding a way), that I could specify: I want layer 0 to have 62 chunks (4960 nodes) of dirt and then 3 chunks (240 nodes) of air???And I want layer 1 to have 10 chunks (800 nodes) of dirt and then 20 chunks (480 nodes) of air?

<edit>Ok, after further study, I see: This means that every layer has the same height So, I can still work with this, but is it critical to the design, or would it be possible to build up a table of layers, so that they do not all have to be the same?

Why? I have a dream that I was playing with before you came out with this wonderful mod, where I would have multiple underground realms under y=0, and multiple above ground realms above y=0. for this to work properly, I need to be able to turn off the bedrock on the below ground layers, and they need to be drastically different ratios of rock to air from the above ground layers. I can explain in more detail if it matters.

<edit 2>AHA! I think I'm catching on. I can do whatever I want within a layer, this much rock, this much air, just by customizing the map gen function I use for that layer, is that correct?

/trying to drum up more excitement and interest in this awesome multi_map concept!

Having now played with multi_map, I reckon it could provide its own biome registration functions and biome lookup functions made in the image of Minetest's ones, rather than having generators use the C++ ones. That allows landscape generators to be separate from the game/world content of each layer, more mods could be converted, and it allows the noise blending tricks.Alternately, if we could get the MapgenBasic::generateBiomes() c++ function exposed to lua (for great biome speed), we could use minetest.set_mapgen_setting("mg_biome_np_humidity", ..., true) etc to change the biome noise seeds whenever the layer changes. Beerholder - do you have any plans or imaginings for multi_map.register_biomes_and_decorations() or similar functionality? Should I play with the idea?

And texmex - shadow worlds... nice idea! I'm pretty sure it's possible without even specific support from multi_map by some hacks like:

If it is possible to generate 2 or more exactly the same map layer then i'm thinking a map with time travel scenario like if you know chrono series. The coordinates may reveal the trick but the game may be more interesting like stronger mobs at the other layer. Or may be the same schematic while fresh at one layer but griefed in the other layer.