Post your mapgen questions here (modding or engine)

[Sergey]

cave is natural with ores inside... a dungeon is a kind of undergrond crypt or temple underground which is supposed to be old burried buildings.

Oh! So dungeon is cuboid space with walls made of cobble stone?

[azekill_DIABLO]

yep. It's supposed to have chest, loots and mobs in it.

[v-rob]

How can I fix the lighting of multiple stacked realms, so that each realm acts like as if it were under direct sunlight, no matter how many realms are stacked above?

Well, you might have to make them above the normal map instead of below. If you do get shadows when you fly high enough, then generate clear, unbreakable nodes somewhat below the new realm. (It could be ignore if you can generate it. If it isn't ignore, then you should make it unplaceable to prevent people from ruining a world with them.)

Like this:

Realm-----------------------------
`
Invisible nodes------------------
`
`
`
`
`
`
Normal World-------------------

You can't generate the nodes making the shadow, and invisible ones can't cast a shadow. You can't get any problem unless people use noclip.

I don't think it's possible to have a realm below a certain level with no shadow.

[AspireMint]

Is it possible to generate desertstone instead of stone only above -10
and replace all dirt to dry_dirt, using valley mapgen? Oh and remove acacia tree (or better remove savanna).

EDIT: question 2
how to force mapgen to generate mese instead of dirt without using minetest.register_alias_force("dirt", "mese") ?

EDIT2:
"generate desertstone instead of stone only above -10"
Solved: http://dev.minetest.net/VoxelManip#Examples

[Wuzzy]

I have mapblock coordinate and need to know the real coordinates from that. How do I calculate the real coordinates? And how do I calculate real coordinates back to mapblock coordinates? This is important because some error messages which only give me the mapblock coordinates which are useless to me.

You can't generate the nodes making the shadow, and invisible ones can't cast a shadow. You can't get any problem unless people use noclip.

The thing is, the realm in question has to be below 0. :-(

[v-rob]

I have mapblock coordinate and need to know the real coordinates from that. How do I calculate the real coordinates? And how do I calculate real coordinates back to mapblock coordinates? This is important because some error messages which only give me the mapblock coordinates which are useless to me.

You can't generate the nodes making the shadow, and invisible ones can't cast a shadow. You can't get any problem unless people use noclip.

The thing is, the realm in question has to be below 0. :-(

But why? No one will know if you put it way up in the air.

[azekill_DIABLO]

F3

[AspireMint]

(added question 2 in my previous post)

[duane]

Is it possible to generate desertstone instead of stone only above -10
and replace all dirt to dry_dirt, using valley mapgen? Oh and remove acacia tree (or better remove savanna).

EDIT: question 2
how to force mapgen to generate mese instead of dirt without using minetest.register_alias_force("dirt", "mese") ?

It sounds like you're asking if the mapgen can replace those blocks by itself. As far as I know, it can't. It would be easy to do as a mod though. You just need to use an on_generated hook to examine each chunk and replace the blocks. Then copy the biomes from the registered_biomes table, clear the registered biomes, and reregister all but the savanna.

You could remove the savanna biome from the default mod in the minetest game, if you only want to change it on your system. You could also replace the node_top and node_filler entries from each biome to place anything you want in place of dirt. And you could replace node_stone with the stone you want, but it wouldn't be limited to -10 depth.

If you wanted to make the above changes in a mod, you'd just copy out the biomes, clear them, and reregister them with any changes you wanted. It might actually be simpler than that. I don't remember if I've tried just modifying the registered_biomes table directly.

[duane]

But why? No one will know if you put it way up in the air.

Then you can't dig down to them.

[AspireMint]

It sounds like you're asking if the mapgen can replace those blocks by itself.

yes replace, or better just generate it, no more modifying.

Ok, thank you, i will try.

[AspireMint]

(solved question 1 in my previous post thank you duane! :-) )

[v-rob]

But why? No one will know if you put it way up in the air.

Then you can't dig down to them.

True...

[Wuzzy]

How do I place schematic-based decorations which have a “base” (i.e. nodes which must touch ground level) larger than 1×1 and all “ground-level” nodes have to touch the ground, i.e. it must not “hang” over anywhere.

Decorations work great for trees. Fallen trunks already have problems as they sometimes hang in air. If I add very long fallen trunks they almost always overhang.
What if I have a big decoration with a base of 6×6? Like a stalagmite?

Is there any way this is possible with default decorations or do I have to resort making a custom mapgen?

[Byakuren]

How do I place schematic-based decorations which have a “base” (i.e. nodes which must touch ground level) larger than 1×1 and all “ground-level” nodes have to touch the ground, i.e. it must not “hang” over anywhere.

Decorations work great for trees. Fallen trunks already have problems as they sometimes hang in air. If I add very long fallen trunks they almost always overhang.
What if I have a big decoration with a base of 6×6? Like a stalagmite?

Is there any way this is possible with default decorations or do I have to resort making a custom mapgen?

You could place a 1x1x1 decoration that expands itself on LBM (or destroys itself if it would cause overhangs), though maybe that gets into the realm of custom mapgen?

[paramat]

Am I correct in these assumptions? I should probably work my way through the game code, but I'm too tired at the moment, so I thought I'd ask.

If I am correct, is there any way to tell what portion of the data is being used from each iteration of my on_generated, so I don't waste time on unused data?

Edit: By the way, when I set num_emerge_threads = 1 in my minetest.conf, the on_generated still gets called twice (because each core has two threads?). So, no help there.

Edit: After further checking, I figured out that a bug in my code was calling generate twice, so when I set threads to one, the on_generated only gets called once now. Set it to two, and I'm back with multiple calls. I guess I could just tell people to leave it at 1...

This will be stuff beyond my understanding, however perhaps number of emerge threads should not multiply 'on generated' and this deserves an issue at Github?

[paramat]

How can I use VoxelManip or whatever to make sure this realm acts like as if it were under sunlight, meaning the Overworld does not cast a shadow on anything below?
I already tried to set propagate_shadow=false in all of the realm's chunks but it didn't do anything.

I need to try this myself to check for a bug.
Are you using mgv6 or other mapgens? Please link to your code.

[paramat]

- Do I have to call update_liquids before or after I call write_to_map?
- How to I make giant v5/v7 caverns more common? I want to make them so common that they hard to miss. With current default settings you often need a lot of time.

Here's what i do, are you adding lua voxelmanip stuff to a core mapgen world?

Code: Select all

	vm:set_data(data)
	vm:set_lighting({day = 0, night = 0}) -- optional, depends on situation
	vm:calc_lighting()
	vm:write_to_map(data)
	vm:update_liquids()

Did you see this?

Code: Select all

#    Defines full size of caverns, smaller values create larger caverns.
#    type: float
# mgv7_cavern_threshold = 0.7

Adjusting that makes them bigger, but then you may want to scale the entire distribution down in size, to do that

Code: Select all

#    3D noise defining giant caverns.
#    type: noise_params
# mgv7_np_cavern = 0, 1, (384, 128, 384), 723, 5, 0.63, 2.0

reduce the 'spreads', the 3 numbers in brackets, the y value is smaller to squash them vertically.

[paramat]

As I recall, the game doesn't light anything below a certain altitude automatically. You can make lots of levels above altitude zero, and as long as they're far enough apart, shadow won't propagate.

No, shadows are always propagated downwards, but you need to start at the top and travel downwards generating mapchunks to propagate the shadow. Because the danger is there the 'propagate shadow' bool was added to stop shadows passing a defined y level.

[paramat]

then generate clear, unbreakable nodes somewhat below the new realm. (It could be ignore if you can generate it. If it isn't ignore, then you should make it unplaceable to prevent people from ruining a world with them.)

Like this:

Realm-----------------------------
`
Invisible nodes------------------
`
`
`
`
`
`
Normal World-------------------

You can't generate the nodes making the shadow, and invisible ones can't cast a shadow. You can't get any problem unless people use noclip.

I don't think it's possible to have a realm below a certain level with no shadow.

The idea is one way to do it, but not necessary since we have the 'propagate shadow' bool.
Your closing statement is incorrect.

[paramat]

How do I place schematic-based decorations which have a “base” (i.e. nodes which must touch ground level) larger than 1×1 and all “ground-level” nodes have to touch the ground, i.e. it must not “hang” over anywhere.

Yeah this is a problem we encountered with fallen logs (which is why they're so short).
I recommend searching for flat areas of terrain to place them on, then use 'place_schematic_on_vmanip()' instead of the decoration API. Use the 'mapgen object heightmap' in an on-generated function to find the flat areas, then create a lua voxelmanip to place the schemtics into.
Do this in a core mapgen, you don't need a custom mapgen.

Or add a tapering stone base to the bottom of the schematic and use the flag 'place_center_y' to place the centre of the schematc at ground level, then the tapering base adds a bit of terrain that looks natural as a support for the decoration.

[paramat]

Is it possible to generate desertstone instead of stone only above -10
and replace all dirt to dry_dirt, using valley mapgen? Oh and remove acacia tree (or better remove savanna).
how to force mapgen to generate mese instead of dirt without using minetest.register_alias_force("dirt", "mese") ?

If it must be -10 then use a luavoxelmanip, however if -32 is ok you can do that by re-registering biomes.
Your other questions can be solved by using a mod that depends on 'default' and 'flowers' and starts with

Code: Select all

minetest.clear_registered_biomes()
minetest.clear_registered_decorations()

then copy-paste all biome and decoration registrations from MTGame default/mapgen.lua and flowers/mapgen.lua and make your required changes to those registrations. This will all use engine code so will be as fast as core mapgen.
(will work for all mapgens except mgv6).

[paramat]

Wuzzy, this works, note the specified volumes in 'set lighting' and 'calc lighting'.

Code: Select all

-- Constants

local c_air = minetest.CONTENT_AIR


-- Localise data buffer

local dbuf

-- On generated function

minetest.register_on_generated(function(minp, maxp, seed)
	local y0 = minp.y
	if y0 > -512 then
		return
	end

	local x1 = maxp.x
	local y1 = maxp.y
	local z1 = maxp.z
	local x0 = minp.x
	local z0 = minp.z

	local vm, emin, emax = minetest.get_mapgen_object("voxelmanip")
	local area = VoxelArea:new{MinEdge = emin, MaxEdge = emax}
	local data = vm:get_data(dbuf)

	for z = z0 - 16, z1 + 16 do -- To clear lava
		for y = y0, y1 do
			local vi = area:index(x0 - 16, y, z)
			for x = x0 - 16, x1 + 16 do
				data[vi] = c_air
				vi = vi + 1
			end
		end
	end
	
	vm:set_data(data)
	vm:set_lighting(
		{day = 0, night = 0},
		{x = x0, y = y0, z = z0},
		{x = x1, y = y1, z = z1}
	)
	vm:calc_lighting(
		{x = x0, y = y0, z = z0},
		{x = x1, y = y1, z = z1},
		false
	)
	vm:write_to_map(data)
end)

[Wuzzy]

Wuzzy, this works

No, it doesnt.

I did a quick test by teleporting to X, -20000, Z in the minimal subgame. The wieldhand immediately indicated I am in darkness.
The light only seems to work close to X, -512, Z and when I start moving downwards from there. But not when I teleport to Y=-20000 directly.

Also, your code doesn't make sense. write_to_map can't take data as an argument, only a boolean (assuming that lua_api.txt is correct).

I need to try this myself to check for a bug.
Are you using mgv6 or other mapgens? Please link to your code.

I tried to make it work in all mapgens and failed in all of them so far. Or I just got poor results.

http://repo.or.cz/MineClone/MineClone2. ... .lua#l1758

This seems to work at first sight when you teleport to the End (Y=-27000). But as soon you move around, you will quickly encounter areas in shadow.

vm:set_data(data)
vm:set_lighting({day = 0, night = 0}) -- optional, depends on situation
vm:calc_lighting()
vm:write_to_map(data)
vm:update_liquids()

Ok, so it must be called after write_to_map. I wonder if the order is important. Is it bad when I call update_liquids before write_to_map?

Also, you did that weird write_to_map(data) thing again. o_O


More questions:

- How do I colorize Dirt with Grass based on the biome in which there were generated, assuming this node supports so-called “hardware coloring” (very strange name, by the way)?
- How do I know to which biome a particular position belongs to outside of on_generated?
- What is the preferred way to read the biomemap mapgen object? All I get is a flat array. I think I have figured it out, but it seems nowhere documented nor are there any converter functions. Have I overlooked something?
- Can I grab the v6 tree noise in Lua and use it to place decorations exactly in forests?

* The `on_generated()` callbacks of some mods may place individual nodes in the generated area using
non-VoxelManip map modification methods. Because the same Mapgen VoxelManip object is passed through
each `on_generated()` callback, it becomes necessary for the Mapgen VoxelManip object to maintain
consistency with the current map state. For this reason, calling any of the following functions:
`minetest.add_node()`, `minetest.set_node()`, or `minetest.swap_node()`
will also update the Mapgen VoxelManip object's internal state active on the current thread.

What happens if if use minetest.place_schematic?
Also, what should I do to prevent possible race conditions? For example, if I have two on_generated functions and both manipulate a VoxelManip of the same area. What to do if both functions are in different mods?

Is it true that on_generated functions can run in parallel?

[duane]

- What is the preferred way to read the biomemap mapgen object? All I get is a flat array. I think I have figured it out, but it seems nowhere documented nor are there any converter functions. Have I overlooked something?

I like your questions, Wuzzy.

The biomemap table is a flattened, two-dimensional array in the X-Z plane, just like the heightmap. It gives you numbers for each biome which correspond to the results of the minetest.get_biome_id function. I made a table of the numbers for each biome in the file scope of my mapgen.lua files, and used that to lookup the name of each position's biome. Here's an example.

- How do I know to which biome a particular position belongs to outside of on_generated?

I don't think there is a way to get the biome outside of on_generated. You'd have to either have a mapgen function (accessible to lua) that generates it again from scratch or store them all somewhere.

- Can I grab the v6 tree noise in Lua and use it to place decorations exactly in forests?

I don't understand. If you want to reproduce the terrain placement done by the mapgen, it should be possible in theory, if you exactly reproduce the steps in the C code, since it's based on pseudo-random numbers from a reproducible seed. However, that assumes that each chunk is generated in the same order, since chunks blend at the edges -- reproducing that would be more trouble than it's worth.

It would probably help if you got more specific about what you're trying to do.

Edit: There is a call-back from each decoration being placed. (See gennotify.) It might suck up more cpu time than doing the placement yourself, since it incurs overhead from C to lua with every single decoration.

Is it true that on_generated functions can run in parallel?

You've probably already read the posts I made about on_generated running twice for each chunk if you set the emerge threads to greater than one. Interestingly, I've noticed that parts of the same chunk were generated differently, presumably by different threads, when I used random numbers. (In this case, one type of building would generate from the ground to around Y ~ 25 and another from there to the top of the chunk.) That suggests that data from different threads is being combined somehow, at least in the Y axis.

I fixed that by making the mapgen do everything the same every time, so a given chunk on a given map would always turn out the same. I may try to backtrack my lua code and see if I can get that issue to come up again, but it would probably be just as easy to read the game code and try to figure out what's actually happening...