FOSS gamedev and creative worlds

Can these be generated in the game?

That would be amazing!

Yes if you know how do the code, right.

You can certainly take a bucket of water and dump it at the top of a cliff or ravine. It would be an interesting experiment to drop a few water sources at appropriate locations during map generation (fresh water springs, as it were) to see what happens. It would be very easy to do in a mod, but you'd have to try it and tweak parameters to make it work nicely and have the desired effect.

I just tried it using some code of flolands. The basic concept works, but it would be better to write it new.
Just get a 2D perlin noise, set borders like 0.4 to 0.5, find groundlevel (y) add air (y), again air (y-1) water (y-2) dirt (y-3). That works and is a start, but it would need a lot of tuning and more.

I've seen waterfalls before on early builds of Minetest.

Gambit wrote:I've seen waterfalls before on early builds of Minetest.

what versions?

There are certainly lots of underground waterfalls generated by default. One of the first maps I generated had a great cave near (0,0,0) with a huge waterfall in it. Made a great place to build stairs, tunnels behind the fall, overlooking windows, etc.

what about rivers?

Never seen rivers ever in Minetest.

Gambit wrote:Never seen rivers ever in Minetest.

That would definitely be a cool feature to see :D

It would be awesome with the finite liquid core feature.

I turned landup020 inside out to make canyons, adding water at sea level ... very glitchy but generates fast.

paramat wrote:

^ I turned landup020 inside out to make canyons, adding water at sea level ... very glitchy but generates fast.

hmmm looks really good but the glitchy part is worrysome :/

paramat wrote:

is that an oasis in the desert on the left?

I made a cool map before with just water :) since I added flamable=1 to, all the blocks but water, and lava.

Likwid H-Craft wrote:I made a cool map before with just water :) since I added flamable=1 to, all the blocks but water, and lava.

tell me you saved a picture i would love to see it o.o

What about having generation run a liquid that erodes the soil partially(to emulate millions of years of erosion), then turning the erosion off right as it exits the generation stage?

rarkenin wrote:What about having generation run a liquid that erodes the soil partially(to emulate millions of years of erosion), then turning the erosion off right as it exits the generation stage?

it would also creat canyons nice :D

rubenwardy wrote:It would be awesome with the finite liquid core feature.

Hmm. If liquid were finite you'd actually have to implement a LOT more stuff to get rivers: rain/snow, evaporation, etc. Or at least some kind of water SINK at the bottom of oceans to match the sources. Rivers are a lot simpler with infinite water sources, at least to start.

prestidigitator wrote:

rubenwardy wrote:It would be awesome with the finite liquid core feature.

Hmm. If liquid were finite you'd actually have to implement a LOT more stuff to get rivers: rain/snow, evaporation, etc. Or at least some kind of water SINK at the bottom of oceans to match the sources. Rivers are a lot simpler with infinite water sources, at least to start.

yeah but wouldn't that make frames drop for some low end computers?

Linxx wrote:

prestidigitator wrote:

rubenwardy wrote:It would be awesome with the finite liquid core feature.

Hmm. If liquid were finite you'd actually have to implement a LOT more stuff to get rivers: rain/snow, evaporation, etc. Or at least some kind of water SINK at the bottom of oceans to match the sources. Rivers are a lot simpler with infinite water sources, at least to start.

yeah but wouldn't that make frames drop for some low end computers?

Well, the bigger the ecosystem and the more parts, the more fragile it is going to be. As it is now, you'd have to load the section of the map with the source of a river before you load the section with the downstream end, or you'll get a raging flood at some point (which could be fun). But if you needed to load ocean and all the chunks in between in order to get some water to evaporate, blow in the wind, and then precipitate, you've got a much bigger set of areas you have to load and keep loaded. THAT would likely be a much bigger strain that what we have now, which is simply checking each water source and flow to see if it should spill into a neighboring node full of air (or dry up if there isn't something to flow into it in the case of flowing water).

Also, with finite volume tracking you're going to have a lot more chain reactions to deal with. Picture a water flow at the bottom of a mass of water. If there's somewhere for it to go, the node is not just going to have to move; some neighboring node is going to have to take its place, and then some other one take ITS place, etc. At the moment all that happens is that the flow creates another flow next to or beneath it, so the chain reaction only goes in "one direction" so to speak.

prestidigitator wrote:

Linxx wrote:

prestidigitator wrote:Hmm. If liquid were finite you'd actually have to implement a LOT more stuff to get rivers: rain/snow, evaporation, etc. Or at least some kind of water SINK at the bottom of oceans to match the sources. Rivers are a lot simpler with infinite water sources, at least to start.

yeah but wouldn't that make frames drop for some low end computers?

Well, the bigger the ecosystem and the more parts, the more fragile it is going to be. As it is now, you'd have to load the section of the map with the source of a river before you load the section with the downstream end, or you'll get a raging flood at some point (which could be fun). But if you needed to load ocean and all the chunks in between in order to get some water to evaporate, blow in the wind, and then precipitate, you've got a much bigger set of areas you have to load and keep loaded. THAT would likely be a much bigger strain that what we have now, which is simply checking each water source and flow to see if it should spill into a neighboring node full of air (or dry up if there isn't something to flow into it in the case of flowing water).

Also, with finite volume tracking you're going to have a lot more chain reactions to deal with. Picture a water flow at the bottom of a mass of water. If there's somewhere for it to go, the node is not just going to have to move; some neighboring node is going to have to take its place, and then some other one take ITS place, etc. At the moment all that happens is that the flow creates another flow next to or beneath it, so the chain reaction only goes in "one direction" so to speak.

well lag is still an issue no matter what then haha

Linxx wrote:is that an oasis in the desert on the left?

The area of water in the desert on the left is a natural spawn.

Concerning the glitches, they were my fault which is good news because i know how to fix them. I'll refine this and release it as a mod.

Linxx wrote:

prestidigitator wrote:

Linxx wrote:yeah but wouldn't that make frames drop for some low end computers?

Well, the bigger the ecosystem and the more parts, the more fragile it is going to be. As it is now, you'd have to load the section of the map with the source of a river before you load the section with the downstream end, or you'll get a raging flood at some point (which could be fun). But if you needed to load ocean and all the chunks in between in order to get some water to evaporate, blow in the wind, and then precipitate, you've got a much bigger set of areas you have to load and keep loaded. THAT would likely be a much bigger strain that what we have now, which is simply checking each water source and flow to see if it should spill into a neighboring node full of air (or dry up if there isn't something to flow into it in the case of flowing water).

Also, with finite volume tracking you're going to have a lot more chain reactions to deal with. Picture a water flow at the bottom of a mass of water. If there's somewhere for it to go, the node is not just going to have to move; some neighboring node is going to have to take its place, and then some other one take ITS place, etc. At the moment all that happens is that the flow creates another flow next to or beneath it, so the chain reaction only goes in "one direction" so to speak.

well lag is still an issue no matter what then haha

Nope, it would be easier to implement with finite water. Proller (the developer for the c++ core version) is working on erosion.

Infinite water may be easier to mapgen, but it would not by as effective, although it is faster.

http://forum.minetest.net/viewtopic.php?id=4901

it works i am using it and it ads some great variety to the terrain. im using it with the "snow"biome mod and the plantlife and moretrees mods. looks amazing.

what if when water was on top of dirt for a while it turns into mud, then eventually into clay, then after a long time it dissapears, that would be an easy way to simulate erosion, and a good source of clay. Also, rock could erode into pebbles, then gravel, then sand, then dirt.
The erosion pattern would go like this: (assuming it was part of a mod called "erosion")
default:stone
erosion:pebbles
default:gravel
default:sand
default:dirt
erosion:mud
default:clay
air (which would then be filled with water)

The only problems sre that it would cause minetest to be slow, becuase there is so much water, and also, everything would eventually be eroded away completely, without anything to replace the destroyed stuff.

Simple solution to that is to make such a thing only work with flowing water - there is far less of that than of standing water. A single ABM that checks what is around the water node and takes the appropriate transformation action shouldn't be heavy at all. I suggest a different pattern of erosion depending on whether you're looking at the node *under* the water versus nodes next to it.

For example, skip the clay step and go straight from mud to air for nodes underneath the water, only making clay in nodes that are adjacent to the water.

That way the only thing that erodes is rivers, which would be very rare compared to lakes.

I'd suggest it should take no less than, oh, 8 to 10 days of real time to go through the entire erosion sequence, if that's possible, and maybe 2 days of real time to get from dirt to air.

Good idea, because flowing water would erode faster than non-flowing water.
anyway, here are the updated steps:
Non-flowing water:
(no erosion)

next to flowing water:
gravel
sand
dirt
mud
clay
air
(stone and pebbles are not eroded because I don't want rivers to get too wide)

under flowing water:
stone
pebbles
gravel
sand
mud
air

(no dirt step because dirt would get wet instantly at the bottom of a river)

There needs to be a limit, though, because if there isn't, then water will erode all the way to the bottom of the map eventually. Maybe a depth limit, like water can't erode below -50, but a depth limit for erosion is unrealistic, so maybe have water not erode stone and make the dirt layer thicker.

Best compromise might be to add, say, a 20-node deep layer of some other material between the stone and dirt, such as that blended dirt+cobble block from the usesdirt mod, followed by a 5-node layer of cobble and then regular stone below that, and add those nodes to the erosion chain, leaving stone out.

This might be doable with that "sheet" ore type that was recently introduced to the engine, which would mean super-fast generation of such landmasses since Lua wouldn't have to do the hard work.