Request to reconsider removal of finite liquid & weather
- MirceaKitsune
- Member
- Posts: 939
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
Request to reconsider removal of finite liquid & weather
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 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?
- MirceaKitsune
- Member
- Posts: 939
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
Re: Request to reconsider removal of finite liquid & weather
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.
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.
- philipbenr
- Member
- Posts: 1897
- Joined: Fri Jun 14, 2013 01:56
- GitHub: philipbenr
- IRC: philipbenr
- In-game: robinspi
- Location: United States
Re: Request to reconsider removal of finite liquid & weather
I agree with you MK. I think that the Finite water was rather important and will be missed. I know will miss it...
- MirceaKitsune
- Member
- Posts: 939
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
Re: Request to reconsider removal of finite liquid & weather
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.
- paramat
- Developer
- Posts: 3700
- Joined: Sun Oct 28, 2012 00:05
- GitHub: paramat
- IRC: paramat
- Location: UK
Re: Request to reconsider removal of finite liquid & weather
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.
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:
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
For mgv7 i'm sure hmmmm will provide functions for heat and humidity.
Last edited by paramat on Wed Apr 30, 2014 04:58, edited 1 time in total.
Re: Request to reconsider removal of finite liquid & weather
I never understood why those features were included in the first place. Much simpler feature suggestions were turned down due to their complexity.
Re: Request to reconsider removal of finite liquid & weather
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.
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.
My blog: LazyJ's Minetest World
- PilzAdam
- Member
- Posts: 4026
- Joined: Fri Jul 20, 2012 16:19
- GitHub: PilzAdam
- IRC: PilzAdam
- Location: Germany
Re: Request to reconsider removal of finite liquid & weather
It was basically proller doing it on his own.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.
- MirceaKitsune
- Member
- Posts: 939
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
Re: Request to reconsider removal of finite liquid & weather
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).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:(Apparently the dynamic weather system added another system of heat/humidity independant of these)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
For mgv7 i'm sure hmmmm will provide functions for heat and humidity.
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.
- paramat
- Developer
- Posts: 3700
- Joined: Sun Oct 28, 2012 00:05
- GitHub: paramat
- IRC: paramat
- Location: UK
Re: Request to reconsider removal of finite liquid & weather
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.
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
If you get stuck trying to do this yourself i'll write the code.
- MirceaKitsune
- Member
- Posts: 939
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
Re: Request to reconsider removal of finite liquid & weather
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.paramat wrote: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 :)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
If you get stuck trying to do this yourself i'll write the code.
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?
- stormchaser3000
- Member
- Posts: 422
- Joined: Sun Oct 06, 2013 21:02
- GitHub: stormchaser3000
Re: Request to reconsider removal of finite liquid & weather
hmmm i have no idea why but how about adding rain and snow in shaders?
- paramat
- Developer
- Posts: 3700
- Joined: Sun Oct 28, 2012 00:05
- GitHub: paramat
- IRC: paramat
- Location: UK
Re: Request to reconsider removal of finite liquid & weather
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.
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
Code: Select all
local humid = 50 + hnoise * 31.25
It would be nice to have a thermometer mod with an item that when used printed temperature and humidity to terminal.
- rubenwardy
- Moderator
- Posts: 6978
- Joined: Tue Jun 12, 2012 18:11
- GitHub: rubenwardy
- IRC: rubenwardy
- In-game: rubenwardy
- Location: Bristol, United Kingdom
- Contact:
Re: Request to reconsider removal of finite liquid & weather
I don't think shaders work like that. iirc, they just modify how an existing entity looks.stormchaser3000 wrote:hmmm i have no idea why but how about adding rain and snow in shaders?
Two ways to add snow / rain:
- Particles (like current)
- Image Overlay
- MirceaKitsune
- Member
- Posts: 939
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
Re: Request to reconsider removal of finite liquid & weather
Thank you. A function like that is exactly what I was hoping someone would shed some light on!paramat wrote:For co-ordinates x, z use:likewise for humidity but with: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
'minetest.get_perlin' takes noise params in order: (seed, octaves, persistence, spread)Code: Select all
local humid = 50 + hnoise * 31.25
It would be nice to have a thermometer mod with an item that when used printed temperature and humidity to terminal.
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*.
- philipbenr
- Member
- Posts: 1897
- Joined: Fri Jun 14, 2013 01:56
- GitHub: philipbenr
- IRC: philipbenr
- In-game: robinspi
- Location: United States
Re: Request to reconsider removal of finite liquid & weather
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?
Code: Select all
ERROR[ServerThread]: Could not process soil information of node paragenv7:dirt
ERROR[ServerThread]: Could not process soil information of node air
Does this error have to do with this topic? Or is something else wrong?
- paramat
- Developer
- Posts: 3700
- Joined: Sun Oct 28, 2012 00:05
- GitHub: paramat
- IRC: paramat
- Location: UK
Re: Request to reconsider removal of finite liquid & weather
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.
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.
- MirceaKitsune
- Member
- Posts: 939
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
Re: Request to reconsider removal of finite liquid & weather
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.
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.
- Hybrid Dog
- Member
- Posts: 2835
- Joined: Thu Nov 01, 2012 12:46
- GitHub: HybridDog
Re: Request to reconsider removal of finite liquid & weather
PerlinMap is new?
- afflatus
- Member
- Posts: 362
- Joined: Tue Apr 01, 2014 19:47
- GitHub: 0-afflatus
- IRC: afflatus
- In-game: afflatus
- Location: Avalonia
- Contact:
Re: Request to reconsider removal of finite liquid & weather
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?
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:
Code: Select all
local np_temp = minetest.setting_get("mg_biome_np_heat")
local np_humid = minetest.setting_get("mg_biome_np_humidity")
That's as far as I've got with it. Am I anywhere close?
Grailtest is stirring ...
- paramat
- Developer
- Posts: 3700
- Joined: Sun Oct 28, 2012 00:05
- GitHub: paramat
- IRC: paramat
- Location: UK
Re: Request to reconsider removal of finite liquid & weather
Have you seen this? 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).
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).
- afflatus
- Member
- Posts: 362
- Joined: Tue Apr 01, 2014 19:47
- GitHub: 0-afflatus
- IRC: afflatus
- In-game: afflatus
- Location: Avalonia
- Contact:
Re: Request to reconsider removal of finite liquid & weather
Thanks paramat
What I'm actually trying to do is figure some way of reading the mapgen params rather than duplicating them.
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:Have you seen this? viewtopic.php?f=47&t=13278&p=194281#p194281
Yep I realised that soon after I posted this.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).
What I'm actually trying to do is figure some way of reading the mapgen params rather than duplicating them.
Grailtest is stirring ...
- afflatus
- Member
- Posts: 362
- Joined: Tue Apr 01, 2014 19:47
- GitHub: 0-afflatus
- IRC: afflatus
- In-game: afflatus
- Location: Avalonia
- Contact:
Re: Request to reconsider removal of finite liquid & weather
Mispost
Last edited by afflatus on Sun Nov 22, 2015 23:52, edited 1 time in total.
Grailtest is stirring ...
- afflatus
- Member
- Posts: 362
- Joined: Tue Apr 01, 2014 19:47
- GitHub: 0-afflatus
- IRC: afflatus
- In-game: afflatus
- Location: Avalonia
- Contact:
Re: Request to reconsider removal of finite liquid & weather
This seems to work in mg v7 ...
Although this probably isn't the right thread to discuss it.
Code: Select all
local temp_table = {}
local temp_string = minetest.setting_get("mg_biome_np_heat")
temp_string:gsub("%d+%.?%d*", function(c) table.insert(temp_table,c) end)
np_temp = {
--flags = "",
lacunarity = temp_table[9],
octaves = temp_table[7],
offset = temp_table[1],
persistence = temp_table[8],
scale = temp_table[2],
seed = temp_table[6],
spread = {temp_table[3], temp_table[4], temp_table[5]},
}
tempthr = -0.45
Grailtest is stirring ...
- Gael de Sailly
- Member
- Posts: 845
- Joined: Sun Jan 26, 2014 17:01
- GitHub: gaelysam
- IRC: Gael-de-Sailly
- In-game: Gael-de-Sailly gaelysam
- Location: Voiron, France
Re: Request to reconsider removal of finite liquid & weather
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 ?
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 ?
Just realize how bored we would be if the world was perfect.
Who is online
Users browsing this forum: No registered users and 9 guests