FOSS gamedev and creative worlds

It's rare for me to consider anything a bad decision in Minetest development... but such a thing has happened several days / weeks ago. I noticed that finite liquid was removed, as well as the weather system in minetest_game, the developers considering it too buggy and unsupported. I didn't consider finite liquid a feature anyone would miss, so I didn't find this important. But now I also found out that the entire temperature / humidity system, usable (and perhaps already used) by mods was also taken down with it! Luckily I didn't use it yet, but had plans to and there's a lot that could be done with it. Yes, I am pissed about this... but I'm making this thread for a constructive purpose.

I wish to call all developers, as well as users who want to have a say on the matter, to debate whether this removal was good and to what extent. As well as suggest reverting it if enough people agree it was not a good idea.

Personally I am against what happened... especially as I consider such feature removals a bad principle. Otherwise, I don't care about finite liquid myself... but would like the weather system back. At least the humidity and temperature system, even if freezing won't be added back to minetest_game without finite fluids. I planned and am planning to use these in my mods, and from my observations they were not buggy either. Having a temperature and humidity (which also influenced fog density) were great features and I see no reason for them to go!

What is your opinion? Should everything (weather & finite liquid) be added back, only weather, only finite liquid, or nothing? Are enough developers willing to re-add the code that was reverted, if myself and others still want them or announce our intention to use them? What were those bugs it was removed for, how bad are they, and can anyone still fix them?

I've had a chat about this on the dev IRC. Like I said there, the important part which is of use to mods is the ability to know the heat and humidity at a certain position, based on the heat / humidity perlin noise of the mapgen. I've actually made plans to use this ability long ago, as many of my ideas require knowing temperature / humidity at a location. Since this is a feature that existed in Minetest officially and got removed now, I think it's fair to implement a replacement. Unfortunately I'm not familiar with this area of the code myself, so I have to ask developers experienced with the mapgen and perlin to look into it.

But as far as I'm concerned, this is the only thing of high importance... Lua functions to know heat / humidity at position {x, y, z} from the heat / humidity map of the mapgen (in a way that works with both v6 and v7). If that's re-added, everything is fine by me and I no longer have any objection. If other people do of course, do post your thoughts here.

I agree with you MK. I think that the Finite water was rather important and will be missed. I know will miss it...

The problem as I see it is that the feature itself was good and users want it back, but the code was bad and developers who know what's behind the hood don't. Personally I don't know what those bugs were, but at least part of the feature should be re-added in some form. Especially because it was already there, and this is taking something away from the end user... not just an effect but also an useful part of the Lua API which is what bothers me most. Not being mean or anything... just what I think of the issue.

These basic lua functions for heat/humidity can be done very easily in a mod, so i can help out if you get stuck.
Basic v6 biomes forest and desert: biome noise for desert is temp noise.
However snow mod is very popular and almost standard, but that mod's biome noise also seems to be temp, but the 2 systems don't mesh, also it's biomes have a scale of 150 nodes which i feel is too small.
Personally i would go with the original biome noise as temp because it has deserts above noise = 0.4 which means 1/3 of land area, leaving 1/3 for each of forest and snow biomes, so snow biomes below noise = -0.4.
There is also a standard v6 noise for humidity, which locates jungles. So for mgv6 use these perlin noises:

(Apparently the dynamic weather system added another system of heat/humidity independant of these)
For mgv7 i'm sure hmmmm will provide functions for heat and humidity.

I never understood why those features were included in the first place. Much simpler feature suggestions were turned down due to their complexity.

My position on the removal of finite liquid and weather?

I didn't like finite liquid but others did. It was an option.

The removal of weather broke the "Snow" mod which would crash any world or server that used the "Snow" mod. Otherwise I would never have noticed the change.

(A side note: Splizard has since updated his "Snow" mod so the crashes due to the removal of weather no longer happen.)

Can you imagine what the reaction would have been if the update to Minetest had broke "Mesecons" instead?

The recent push to make more sub-games would benefit from having more options like finite water to better distinguish the sub-games. The culmination of "little things" that contribute to the whole does matter.

paramat has proven with his mapgen wizardry that weather can still be acheived through lua scripts. However, I wonder if future mods that utilize weather would beneift more if the engine provided weather cues (I don't know what the proper technical term for it is at the moment). One of the peculiar things about the "Snow" mod is that snow appears in and on top of jungle biomes. How to use the current mapgen perlin noises to correct that is still a mystery. Perhaps paramat would be kind enough to write about his techniques and know-how in a tutorial post or wiki page (it would be no small task, that is for sure).

Short days, long nights and vice versa (percpetion of seasons), light colored clouds, dark clouds (perception of fair vs stormy), thick clouds, thin clouds, slow clouds, fast clouds (perception of wind), snow fall, rain fall, autumn colored leaves falling, grass changing from green to yellow to white (perception of seasons), ground level clouds that are much more transparent (perception of mist and fog), finite water in deserts and on dry fields (perception of drought), infinite water in jungles and low-lands (perception of swamps or floods)... All of these things add to the immersion experience in a game. All of these things, to one degree or another, could be used to make sub-games much more unique.

Creating biomes is one thing, creating meteorlogical effects that suit those biomes is another.

One of the many things that preplex me is the temperature map. Admittedly I don't know much about it but the examples I've seen show different regions on a map of Earth. Ice caps at th poles, warm equator, and varying trasitions in between. All well and good except a Minetest world doesn't fit that. In Minetest worlds there are no poles and there is no equator so we will have to make them. Having weather options may make that possible.

mauvebic wrote:I never understood why those features were included in the first place. Much simpler feature suggestions were turned down due to their complexity.

It was basically proller doing it on his own.

paramat wrote:These basic lua functions for heat/humidity can be done very easily in a mod, so i can help out if you get stuck.
Basic v6 biomes forest and desert: biome noise for desert is temp noise.
However snow mod is very popular and almost standard, but that mod's biome noise also seems to be temp, but the 2 systems don't mesh, also it's biomes have a scale of 150 nodes which i feel is too small.
Personally i would go with the original biome noise as temp because it has deserts above noise = 0.4 which means 1/3 of land area, leaving 1/3 for each of forest and snow biomes, so snow biomes below noise = -0.4.
There is also a standard v6 noise for humidity, which locates jungles. So for mgv6 use these perlin noises:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

#mgv6_np_biome = 0, 1, (250, 250, 250), 9130, 3, 0.50
#mgv6_np_humidity = 0.5, 0.5, (500, 500, 500), 72384, 4, 0.66

(Apparently the dynamic weather system added another system of heat/humidity independant of these)
For mgv7 i'm sure hmmmm will provide functions for heat and humidity.

We discussed this on IRC yesterday. Currently there's no way to get biome heat / humidity at a given position... at least no easy one that doesn't require advanced skills at translating and extracting perlin noise, and works for both v6 and v7 (in my case I only care about v7, others could need v6 too though).

v7 does have a way actually... but it only works in the on_generate function as it relies on active / last mapgen object, meaning you cannot get heat / humidity at any position during any moment. hmmmm said he might implement a v7 specific way of fixing that, but I don't think that will happen soon so I'm not very sure.

This is why I still suggest a Lua function intended specifically for this purpose, which works with both v6 and v7 as well as any mapgen that uses a heat / humidity map that can be read. Optionally, I'd also like temperature and humidity to be visible in the debug info string (F5) like they were with the weather system, since that was also useful.

For mgv7 go to the minetest.conf.example file for your version of Minetest and use the default noise parameters shown there:

It's so easily done in a mod there's no need for engine functions :)
If you get stuck trying to do this yourself i'll write the code.

paramat wrote:For mgv7 go to the minetest.conf.example file for your version of Minetest and use the default noise parameters shown there:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

#mgv7_np_heat = 25, 50, (500, 500, 500), 35293, 1, 0
#mgv7_np_humidity = 50, 31.25, (750, 750, 750), 12094, 2, 0.6

It's so easily done in a mod there's no need for engine functions :)
If you get stuck trying to do this yourself i'll write the code.

I know about these parameters. But how can they be used to get actual heat and humidity per position in Lua? Especially considering that (if I understand right) humidity / temp maps are also random perlin noises which use a seed. I guess a smart Lua function can combine that setting with the value of the seed itself, and understand temperature at a given point.

But again, this goes way beyond my skills. If someone can write the Lua function for that it would be appreciated. If anyone figures it out also, especially for both v6 and v7, I suggest adding the function to builtin (I can do that), so individual mods won't have to add large seed / perlin translators to use this feature. Other developers agree with that?

hmmm i have no idea why but how about adding rain and snow in shaders?

For co-ordinates x, z use:

likewise for humidity but with:

'minetest.get_perlin' takes noise params in order: (seed, octaves, persistence, spread)
It would be nice to have a thermometer mod with an item that when used printed temperature and humidity to terminal.

stormchaser3000 wrote:hmmm i have no idea why but how about adding rain and snow in shaders?

I don't think shaders work like that. iirc, they just modify how an existing entity looks.

Two ways to add snow / rain:

• Particles (like current)
• Image Overlay

paramat wrote:For co-ordinates x, z use:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

local tperlin = minetest.get_perlin(35293, 1, 0, 500)
local tnoise = tperlin:get2d({x=x,y=z})
local temp = 25 + tnoise * 50

likewise for humidity but with:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

local humid = 50 + hnoise * 31.25

'minetest.get_perlin' takes noise params in order: (seed, octaves, persistence, spread)
It would be nice to have a thermometer mod with an item that when used printed temperature and humidity to terminal.

Thank you. A function like that is exactly what I was hoping someone would shed some light on!

I still don't fully understand it though; minetest.get_perlin is obviously the function to get the noise map, but why these precise parameters, given the seed is always a random one per map? As in, why such a rough number as 35293? And how are temperature and humidity precisely stored there? tperlin:get2d({x=x,y=z}) leads me to think that x is the node placement noise and z is the temperature noise, or something like that? I assume 25 + tnoise * 50 is just an offset to convert to C*.

I dont lknow if this is related to this topic, but I have been getting error messages with BlockMen's build saying:



I got a heck of a lot of those messages that had to do with air and a bunch with the others....

Does this error have to do with this topic? Or is something else wrong?

MirceaKitsune, 'minetest.get_perlin' doesn't create a perlin map, that just sets up the parameters to be used. Perlinmaps are a new feature used in voxelmanip mapgen and are flat arrays of 80*80 or 80*80*80 noise values calculated in bulk.

The seed 35293 (and all seeds in noise parameters) is actually a 'seed offset' or 'seed difference', so the actual seed used by temperature noise is: world seed + seed offset, this directly links and fixes the temperature and humidity noises to the world they operate in, seed offset 35293 in world with seed 23 will always have the same temperature distribution.

The x and z in 'get2d({x=x,y=z})' are simply the map co-ordinates for the node column you want to find temperature for, the result is a single noise value.

Yes, get2D() gives a noise value roughly between -1 and 1, so the last line of code converts that to -25 to 75 C. The 31.25 is used with humidity because humidity noise has 2 octaves with a persistence of 0.6, which results in a noise value varying between -1.6 and 1.6 (1.6 * 31.25 = 50). Temperature noise has 1 octave which means the noise varies precisely between -1 and 1.

Thanks for the info, that is good to know. If nothing better is added, I will likely use these functions.

Still, I would suggest adding them to builtin instead, so everyone who wants to get temperature / humidity in a mod will have easy access to this code and won't have to search for a formula similar to the one you posted (unless they read this thread). That would also allow it to be maintained with the hard-coded mapgen systems, such as new mapgens or any changes that might happen to the perlin noise mechanism.

PerlinMap is new?

I haven't filled in the questionnaire because I don't want proller's weather system back.
However what we do need is a decent perlin noise tutorial that focusses on the minetest implementation.

What I understand of perlin noise is based on paramat's explanations and painfully slow trial and error. I'm still confused about how offset and scale work - and how that relates to spread. Does scale multiply the result and then the offset applied to the scaled value? Does a spread of (1000, 1000, 1000) result in 0.001 sized steps or does it spread the result out over 1000^3 nodes?

Immediately I'm trying to work out how to get a more varied density for decoration placement, so plants clump together more with bigger spaces in between. I'm guessing this might be achievable using a low persistence, with maybe a negative offset. Is the threshold 0?

I also want to get snowdrift and biome_lib compatible with mapgen. Snowdrift is relatively easy and I guess biome_lib could use the same compatibility function. At the moment I'm using hardcoded noise params, but that will break if different params are used in mapgen. The function first needs to retrieve the mapgen params:



This probably needs to work outside of on_generate, so that temp and humidity can be retrieved for specific nodes during play. The code above returns a noise params string, which can't be given directly to minetest.get_perlin() IIUC and there is the added complication that biome_lib, like splizzard's snow mod uses inverse values, so the result would have to be * -1. Would it work to use a negative value for 'scale'?

That's as far as I've got with it. Am I anywhere close?

Have you seen this? https://forum.minetest.net/viewtopic.php?f=47&t=13278&p=194281#p194281

Offset and scale are applied to the raw noise value, which itself varies between roughly -2 and 2 (depending on number of octaves and persistence, for 1 octave the raw noise variation is -1 to 1, for 3 octaves 0.5 persistence the raw noise variation is -1.75 to 1.75)

The raw noise value is created first, then it is multiplied by scale then has offset added to it.

With decorations you use noise to create a varying 'fill ratio', the threshold for decorations to appear is therefore 0.
Offset 0 results in 1/2 area covered by decorations, a negative offset will reduce that proportion.

Snowdrift is already auto compatible with latest mapgen, however i recently changed the mgv5/v7 biome system so you need to edit lines 43 to 53 to match the biome API temp parameters, and also change the 'tempthr' to -0.45 (for compatibility with latest MT dev).

Thanks paramat

paramat wrote:Have you seen this? https://forum.minetest.net/viewtopic.php?f=47&t=13278&p=194281#p194281

I have now. Actually I did read it a while ago, but I couldn't remember what the post was called and clearly used the wrong search terms.

paramat wrote:Snowdrift is already auto compatible with latest mapgen, however i recently changed the mgv5/v7 biome system so you need to edit lines 43 to 53 to match the biome API temp parameters, and also change the 'tempthr' to -0.45 (for compatibility with latest MT dev).

Yep I realised that soon after I posted this.
What I'm actually trying to do is figure some way of reading the mapgen params rather than duplicating them.

Mispost

This seems to work in mg v7 ...


Although this probably isn't the right thread to discuss it.

About weather :
commit 4ec4672 completely breaks some standard groups (hot, melts, snow) for a year. The deletion of these groups (and also the weather functions) is a big step backwards for mods compatibility. Mods try to redefine it how they can. For compatibility, it could be better.
The discussion is one year old but is NOT closed !

And just a silly question : what is finite liquid ?

Liquid that disappears when spread out far enough, for example, if you poured a bucket of water at the edge of a cliff, it would fall and dissapear.

Gael de Sailly wrote:About weather :
commit 4ec4672 completely breaks some standard groups (hot, melts, snow) for a year. The deletion of these groups (and also the weather functions) is a big step backwards for mods compatibility. Mods try to redefine it how they can. For compatibility, it could be better.

I agree that there was no need to remove these groups as they are useful outside of proller's weather system. The weather functions were removed AFAIU because parts of the weather system were broken and no longer maintainable. The idea of removing the whole weather system is to keep the code base clean, so that someone could step in and create new weather functions without having to worry about compatibility with deprecated code.

So far no-one has stepped in to create a more suitable system.

And just a silly question : what is finite liquid ?

I think this is because the general implementation of water doesn't reflect natural physics very well; "source" nodes should provide an infinite source of liquid, "flowing" nodes should really be finite, but I suspect the issue has been fudged because water doesn't really flow in MTG, it grows instead. Have a look at paramat's implementation of river water, which has a limited spread to prevent flooding.

It is all rather sub-optimal IMO. It would be necessary to model the entire water cycle more accurately in order to get weather and climate to work right, as they are inextricably linked in real-life.

In short, the old weather system is dead; bemoaning it is useless.
Who is up for developing a new weather system?

Most of it can be done in Lua and I'm sure engine changes can be pushed through if we take a unified, generic approach which would satisfy the KISS-heads.

For weather, there should at least be a way to draw effects for each player, ie. snow, rain, etc.
And maybe cloud colors?