I love the idea of it spreading.

I like the idea of having to deal with it spreading.

I don't like the idea of it destroying a world.

Ahh ... I know. Edging.

The core of the wasteland contains CS. It spreads. But it spreads at different rates in different areas.

In the core, it will spread quickly if not completely removed.
In the outer region of wastelands, it spreads slower.
Outside of wastelands ...

Well, here's a problem. I would just say force rivers, beaches, or oceans around the wastelands, just like the current biome borders are done. But that doesn't work in Myst.

So what you need is for CS to move slowly outside of wasteland. Perhaps a function of distance from the wasteland. Enough that you can play "fight the CS" if you want, and don't have to worry about losing your world if you do not.

Decay is nice in Myst. But there are times that I want to play with landscapes, and I don't want decay. I have TF because I like the landscape as well as the new creatures and things; I don't want myst decay in it.

I made some unusual lands with Myst; I think much of the 1.7+ terrain fan-boys wants (not all) are satisfied with the unusual landscapes you can make there. But if I'm going for landscape, I don't want decay.

I can get lands with the EB biomes in Myst. I'm discovering that the generation in Myst is significantly different than normal overworld, and I may turn EB on in the overworld -- at least a test world -- to see what things look like there.

In other words: I don't want to have to disable wasteland for my world to be safe. And I want to, when I want to fight the wasteland, have it actually do something.

So it has to be that in the core of the wasteland, it grows quickly; in the outer regions it does not start but will grow, and outside it grows slower; the farther from the wasteland, the slower the growth until it is significantly slower than grass's regrowth rate (as you pointed out, dirt can't have any status stored, so the growth has to be slow enough for grass to dominate.)

Thanks for all of your help with this, @keybounce

Hmm ...

I'm beginning to think that the filler blocks in wasteland need to go back to CS instead of dirt.

I suspect that I can clean up a wasteland completely in just a couple of minutes, and never deal with CS again. And that's probably not a good idea.

So, another idea: In wasteland, or perhaps only in wasteland core, random surface grass/dirt/sand/sandstone will decay for no apparent reason.

In fact, that might be the defining point of wasteland core -- not that it starts with CS and wasteland does not, but that wasteland core cannot be made safe -- you have to make a two-wide or two-tall barrier around it.

What if fill were CS and top block was dirt? (And cs could cause decay even with buried beneath dirt.)

Ohh ...

And it fits nicely with the whole "spread under farmland", it spreads under farmland, dirt, grass, or mycelium.

Nice.

Ok, lets see about some rules:

1. It spreads underground faster in wastelands, slower in non-wastelands.
2. It will only spread from underground to a destination spot that is either exposed to sky on one of the sides or top, or is directly under a block that is exposed to sky.
3. In the wasteland, it will spread to sandstone/sand/dirt/grass underneath any block exposed to sky.
4. In non-wasteland, it will only spread to blocks underneath sandstone/sand/dirt/grass, not to underneath other blocks.
5. The whole "I can spread to a block that has sun exposure on any side", or underneath such a block, permits it to dry out a dirt/grass wall and pass through it. Two-wide water will still stop it. (Since it can jump 2 spaces, one-wide water will not.)

Faster spreading in Wasteland?

Sorry for the two week delay.

Yes, I think that CS should be nastier in wastelands. You want it to be hard to remove from wastelands, but able to protect other lands.

I do like the idea of a wasteland starting with dirt on top, and turning into CS.
I do like the idea that wastelands have CS all the way down to stone, while other lands next to wasteland will only get two meters of CS (and you can dig out some dirt to recover the land ... now if only there was a way to regrow grass without using torches and many game days.)

I'd like to suggest that rain have an effect here, too. Or, more specifically, varying effects.

First, in the "core" area, it does nothing.
In outlying areas of the wasteland, it can, slowly, convert CS to sand.
Further out, rain may cause CS to turn to sand, or infrequently, to dirt.

(Other thoughts: Possibly CS should not spread to biomes below a set temperature, due to it being too cold to dry out? Should there be a "Frozen Wasteland" variation, with Permafrost in place of Cracked Sand, that spreads opposite [in darkness and snow] and cannot go into warm areas? Maybe there could be a climate "sweet spot" that gets neither dried nor frozen?...unless it risks getting overgrown [kudzu?].)

Wow. @AnonTheMouse bring some interesting complexity. I can't wait to hear @keybounce thoughts...! ;)

Thank you!

On Sat, Aug 18, 2012 at 9:29 AM, Scott Killen [email protected]:

Wow. @AnonTheMouse https://github.com/AnonTheMouse bring some
interesting complexity. I can't wait to hear @keybouncehttps://github.com/keybouncethoughts...! ;)

Thank you!

—
Reply to this email directly or view it on GitHubhttps://github.com/ScottKillen/ExtrabiomesXL/issues/50#issuecomment-7845887.

Rain rehydrating cracked sand? I love it!

So what would the result be? Do we want rain to turn sandstone into sand?
Just imagine what would happen if it fell, and how many blocks should fall.

I think that rather than "it can't spread to cold areas", the rule should
be about the dryness of the biome and space. I like the idea that it
spreads faster in drier areas, and slower in wetter areas. But I also like
the idea that what it turns into when raining should depend on wetness.

Wetter areas, it is more likely to turn to dirt. Combined with slower
dehydration in wet areas, and you have a natural repellant to cracked sand.
Suddenly it can no longer destroy a server -- it is now safe for 24/7
systems.

Equally, when raining, CS cannot spread or dehydrate -- rain is "grass
grows, cracked goes".

I do like the idea of frozen wasteland. I like the idea that the block in
frozen wasteland spreads based on temperature, while the block in normal
wasteland spreads based on humidity. Right now neither is used normally.

So what biomes are "hot, wet"? Is that Jungle? It would be "immune" to both
...

Political and economic blog of a strict constitutionalist
http://StrictConstitution.BlogSpot.com

This message may have been spell checked by a laptop kitten.

I'm not sure I would have rain effect normal sandstone. There's not really a precedent for that changing back, while the hydration recipe for CS does make a logical consistency for it to do so. Also, the fact that natural sandstone mainly occurs at the lowest levels of sand suggests it is formed under a great deal of pressure, which again reduces the likelihood of it being permeable to rainwater. Plus, I personally think that the creatable building blocks, like Sandstone and the hypothetical Cracked Sand brick, should be left safe to work with.

So we have CS drying out the land, and the land not getting wetter until it is fully CS'd?

Hmm ...

The real issue is, "is this sand/sandstone because of CS?". If it is, we'd want rain to hydrate.

Right now, I can take a CS block, place it in the desert, let it dry out, and then with this idea let it get rained back to dirt. That will allow us to turn the desert into glass -- err, grass :-).

I think the best answer is:

1. Rain will rehydrate CS.
2. Rain will rehydrate "dryable" lands that are next to CS, on the assumption that they dried out because of CS.
   2b: This will have a biome dependent limit -- won't get wetter than sand in the desert, won't get wetter than dirt in lands that don't have grass normally. This can be determined by the biome's surface block -- if it's grass, you go to grass. If it's sand, you go to sand. If it's something else (such as dirt or mycelium), you go to dirt. And if it's CS, ... well, actually if the idea is that wasteland has CS filler and dirt surface, that works.
   3: The rate of this depends on the biome/block temperature (Or humidity?)

So, the questions: Does biome humidity affect rate of CS spread? Should biome temperature affect the rate of rain rehydration?

In fact, let me add the idea of "hydration level" to cracked sand. This is exactly the same concept as farmland.

Rain increases hydration levels. If (as I understand) rain is an on/off flag for the whole world, then the rate should depend on the local humidity level -- high humidity levels go up faster, and dry areas (desert) does not go up from rain at all.

Water on the ground, at the same level or above it, increases hydration very fast. I think that unlike farmland, this should be a shorter range -- perhaps 2, perhaps 3. Or, perhaps it can be 4, but will not go through CS -- so if you have a CS block between you and the water source, you ignore that water source. (Might be computationally impossible.)

When the hydration level is high enough, CS has a chance to hydrate. The destination block -- Sandstone, Sand, or dirt -- depends on what the hydration level is when it decides to rehydrate.

So:
On block tick:

1. CS determines if it is raining, and if so, adjusts hydration.
2. CS determines if there is water nearby, and if so, adjusts hydration.
3. CS determines if the hydration level is high enough, and if it wants to "wait" (wait is more likely to happen if both not up to the "dirt" level AND either raining or water nearby). If not waiting, transform.
4. If you did not hydrate, and did not transform, then you need to dry out (no water, and you are still CS).

Result: You can re-hydrate CS with water on the ground or rain.
It is more likely to wind up with dirt in this case (water on ground) because it will likely take longer (and absorb more water) before it changes.

Ack, and of course, I re-read the earlier comments.

As I understand it, none of the other blocks in the sequence -- sandstone, sand, dirt -- have any concept of hydration levels. So while you could say that rain will update CS, SS, S into D based on proximity to CS, that isn't the same as storing hydration in the CS and using that to update what it turns into.

I think there's an answer somewhere between these two, but I don't know it/can't see it.

My main problem with involving Sandstone in the conversion range remains that it is too commonly used as a building material. I don't think that anyone wants to spend a whole lot of time importing tonnes of Sandstone (or worse, raw Sand to make Sandstone) just to have their epic fortress turn into a glorified dirt hut. While there is the "carved" Sandstone, it has a fundamentally different look, and may not always be suitable for the same design elements. The other alternative is working exclusively with slabs, which might work, but would make designing Sandstone structures unnecessarily tedious.

Thus why I suggested making a whole 'new' block. :)

I think that too many factors are being involved here. You have:

• Hydration
• Spreading
• CS converting to another block... or vice-versa.

They need to be addressed separately. And I also think that if you are going to include a 'spreading' and 'conversion', it should be optional - but separate options. Hydration is a neat idea. I could see complaints at a later date addressing these if people are playing casual or building something and not wanting to have to deal with the spreading or worry about blocks turning into different things. Having these two things 'optional' is key.

+Hydration <-----> CS conversion

+Spreading <-----> CS converstion

+Spreading <-----> Hydration

</br/>

Hydration <-----> CS conversion
Don't make this too complicated. You do not want to deal with a lot of questions on 'why' and 'what ifs' after it has been implemented. It needs to be exactly systematic so it is easy to understand or figure out on an adventure if people do not want to know ahead of time. This is a new thing that will draw a lot of attention because I have yet to see it in any other mods. So just be prepared for this.

Instead of relying on SS, you are going to have to make a 'new' block as to not interfere with SS. Sure, give it the same characteristics and a skin close to SS. But you are not going to want to mess with SS. It is too big in the game, and you are not going to want to confuse people - especially if they are going to involve other mods that tamper with the 'main' blocks of MC.

I like the idea of having a conversion from CS to a 'SS'. What about 'mud'? And it turns to 'mud' for 10-15min RL time and then back to CS during/after it rains? Maybe some spots turn to 'quicksand' and then stay that way?

If you go with the 'mud' - which is really neat imho - one could have the potential to farm in the CS wasteland. Add a water cube - like farming wheat - and it would 'hydrate' aka turn all blocks in a 3 block radius to 'mud' so you could plant on it. If you remove the water, the mud dries up and crops get destroyed.

Also, it would give people a reason to fine a wasteland and take CS with them. They could use to for decorative purposes in swamps, along rivers, or mob traps - referring to the 'mud' part of course.

I like this idea. A lot. It just needs a little more direction. I think using SS would be a mistake and too complicated because then you would tampering well-into other biomes and 'what-ifs'. It is used too often to be 'changed' easily by hydration variables involving water, humidity, and rain.

When it rains: The blocks that have 'spread' just simply turn back to the original state of the block. For the main part of the wasteland, it turns to mud.

Rain: Any CS that has be placed would turn to mud and then turn back into CS after a determined period of time.

Next to water: Any CS that has 'spread'/replaced any other block would simply ignore any standing/running water.

Next to water: Any CS that has been placed and is next to water or withing X blocks would recognize water and thus turn into mud until moved away from the water or the water has been removed.

EDIT:
Question - when you are going to have it 'spread', are you going to have it go ON TOP of other biomes that it spreads to? Or is it going to replace the blocks? Would you have it replace the surface blocks and like 5 blocks deep? Or just the surface blocks?

OK...so lets focus on the gameplay and rules of how it should behave...not the implementation behind the growth. We have several competing algorithms here. I also like @AnonTheMouse idea of Permafrost and find symmetry in it. I will be rewriting this soon.

This thread is getting a bit cluttered with competing ideas, so, each of you please give it some thought and sum up your ideas in a design doc (nothing formal guys). I will read them and pick the best doc, or merge the best ideas from them all. If more than one of you want to collaborate on one DD, so much the better!

The DD can be ideas from this thread, all summed up. Formatting doesn't matter as long as it is organized enough to be understandable. The DD should relate a system for both CrackedSand and Permafrost. Symmetry is valuable. A DD that considers usage of the blocks relative to the growth system will tie everything together.

The main drive behind this is that I am having trouble separating everything on this particular thread.

Please keep it highlevel, with as few specific implementation details as possible.

The best ideas will get credit. The final design will appear on our DD git: oneone-whakaaro where others can offer comments.

Cracked Sand currently has the capability to completely take over the entire world.

For those submitting specs, please PM them to me on MCF. Thanks!

I suspect that we may find the best thing to do is to open multiple idea / issue threads here -- it's like this one thread is now covering 4 or 5 different ideas.

I should have something written up in ... this is tuesday, wednesday is all booked, so I should have something up by friday night.

Oh, one more idea to toss out: Should cracked sand devour quicksand? Right now it does not.

Hmm ...

So after sand comes "Hardened Sand"? Behaves like Sandstone, but has a different block id. Sandstone does not decay, but hardened sand does.

So it goes (farm, grass, mycelium) -> dirt -> sand -> hardened sand -> cracked sand

Then, cracked sand and hardened sand can have a hydration concept to turn back into dirt or sand. And, ...

That still leaves the question: Should sand that is next to HS or CS turn into dirt?

A different idea: I'm agreeing that sand shouldn't be in the sequence either.

Grass dries to dirt, fine. Dirt dries to ... hard sand directly?

Dirt dries to hard dirt. Hard dirt dries to hard sand. Hard sand dries to cracked sand.

That would turn every block involved into new blocks. It would mean that people won't see their desert landscapes ruined. (Good? Bad?). It would mean that wasteland can spread everywhere but deserts ...

Hmm...

I don't know that I like that. I kinda like the idea of a "wasteland world" of wastelands and dry, sand-bottom oceans, where the CS is spreading everywhere and cannot be stopped, only slowed / limited areas protected.

I don't know the answer. It looks like two different issues/ideas.

More later.

Keybounce,

What you are proposing is the entire world be affect by wastelands. If so, this would have to be an 'expansion' of EB. Or an option. But having the entire world be converted would be a big task and would change the game-play for a lot of people. I know you are talking about 'surface' blocks - dirt, sand, grass ect... I would consider this a different mod then EB IMHO.

What I suggested in my post above, would allow this affect in EB, but on a more minute scale. =)

So, essentially as you mentioned, it IS two different issues.

@keybounce I'm looking forward to it!

Another thought...is QuickSand just overhydrated Cracked Sand? Can't wait to see the DD.

And I'm letting you know that I'll be monday at the earliest.

Two most-of-the-day trips with my mother to the doctors. And finishing up a lets play episode editing for YouTube.

Quicksand as nothing more than over hydrated cracked sand? Then what happens to overly heated permafrost?

... No, I don't like it. Dirt -> intermediate -> CS -> hydration -> quick sand, instead of dirt? No thanks.

No problem...I'll wait @keybounce
@AnonTheMouse is also having some delays and I am not yet near the feature adding stage.

Might I toss in my two cents? I've been thinking about it and this is what I ended up with:

	Saturated, X	Average Hydration	Dry, -X	Bone Dry, -2X
Stupid Hot	Bubbling Mud	Steaming Dirt	Dry Dirt	Cracked Sand
Avg. Temp	Mud	Dirt	Dry Dirt	Cracked Sand
Below Freezing, -Y	Permafrost	Permafrost	Permafrost	Cracked Sand

Spreading of Cracked Sand would be solely dependent on the soil drying out. Each tick without rain or a nearby Water block reduces hydration, below -X hydration Grass/Mycelium/Dirt decays to Dry Dirt, below -2X hydration Dry Dirt decays to Cracked Sand. Permafrost decays to Cracked Sand below -2X hydration. Any Dirt placed in the Desert outside of an Oasis would eventually become Cracked Sand without irrigation.

Pretty much everywhere that is too dry on Earth ends up looking a lot like Cracked Sand. Even on Mars the surface looks like this; it's cold & dry.

Cracked Sand decays to Dry Dirt above -2X hydration, Dry Dirt decays to Dirt above -X hydration. So rainfall and/or irrigating with Water restores Cracked Sand to Dirt.

Permafrost is what happens when soil does not rise above freezing for 2 years or more. Below -Y temperature Dirt/Grass/Mud would convert to Permafrost IF hydration is above -X. Permafrost Decays to Mud above -Y Temp and above X hydration. Permafrost decays to Dirt above -Y temperature, between X & -X hydration. Permafrost decays to Dry Dirt above -Y temperature & below -X hydration.

Dirt Decays to Mud above X hydration. Walking on Mud is dangerous, if the player stops moving they will sink at similar rate to Quicksand, however the player CAN rise. Tall Grass, Cattails & Sugar Cane can grow on Mud, but nothing else. Clicking on Mud with a Hoe will convert it to Farmland at appropriate saturation without the need for a nearby Water block. Mud would make up beaches, river banks & ocean/river beds where Dirt would be. This could incorporate MRDNRA's Mudflats suggestion, just have a biome climate of high humidity & average to hot temperatures. This would also effect the dirt of Swamps & Marshes.

Bubbling Mud & Steaming Earth could be what happens when a lava block is within X blocks of Mud & Dirt blocks.

Er, okay that was not so much two cents... um... TL;DR? Hopefully the table helps.

*edited to alter the progression of PF to CS
*added textures to table

One thing to mention, permafrost is actually any ground that remains below freezing for two years, according to Wikipedia. That would make all of Mars, and the Moon, Pluto, etc...giant balls of permaforst. This is one thing that makes permafrost such a good contrast to Cracked Sand. It is essentially an opposite condition which creates the same results.

Hm... true, I was thinking of it more as the substrate in Siberia where Mammoths are often found, which is pretty saturated. I think I'll adjust the chart so that Permafrost skips the Dry Dirt stage & goes directly to Cracked Sand. I'd like for for CS to be as least as likely to occur as PF, so this model give 3 conditions which result in CS & 3 conditions which result in PF.

Oh, I just remembered that Red Cobblestone + 3 Buckets or Water = 4 Clay Balls. So perhaps the hydration would work for Clay/Redrock too?

Thanks @Shavahi

An important question:

What's my light level shows temperature and humidity for each square separately.

So it is influenced by biome, but not rigid by biome.

Are you able to have landscape alter the temp/humidity? Can it be restored afterwards if the land scape is restored?

What I'm thinking of: Permafrost is basically frozen land that doesn't thaw. It reflects more light, so the infected area is colder. At the same time that CS causes nearby lands to dry out, PF would make nearby lands colder until they "Freeze" and PF expands.

Equally, if you remove the PF, would it be able to restore the old temperature? Or is that information lost?

Ok, I think I'll go with this basic idea: (There is a lot more being written up; this is just a quick intro if someone wants to run with this idea in a different direction).

Permafrost is deep cold plus some wetness.
Cracked sand is deep dry plus some heat.

Permafrost spreads by reducing the heat of nearby areas (reflecting more sunlight); it is curtailed by heat (torchlight). It cannot spread into dry areas no matter how cold. It is further stopped by the presence of sun (spreads at night).

Cracked sand spreads by reducing the water (drying out); it is curtailed by water. It cannot spread into cold areas no matter how dry. It is further stopped by the lack of sun (spreads in the day)

As a special case, CS can dry out sand [s]and sandstone[/s].
As a special case, PF can "deep freeze" ice blocks.

Temp/Humid s a biome functionality, unlike light level...there fore it cannot be altered by the landscape (or rather, it cannot do so effectively unless other temperature sensitive mods adapt compatibility...we should not rely on this)

I'm looking forward to your design doc, @keybounce

Please PM the design doc to me on MCF when you finish. Once I read it, I will have some questions and a proposal or two. I understand your time constraints and outside commitments (I deal with the same) so please take the time you need. The above was a good whetting of my appetite!

I need feedback from anyone on this.

I'm doing a re-write of Permafrost from the view that it is nothing more than coldness, spreading by freezing, and lowering nearby temperatures.

Please comment

So, if Permafrost is nothing but coldness, independent of moisture, what is it like?

Well, the first thing is: Water is harder to freeze. Water actually takes more effort to freeze because of the water-ice transition.

So PF spreads differently when the temperature is over 32.

What is the spread of PF? I'm still going to go with the idea of "It's making it colder next to it". Somehow, it has to be making the regions that were warm enough to thaw into conditions where it can go into deep freeze.

So, I'm going to go with a strange idea: "Ice Layer".

I don't have a good idea on how they would form. But the presence of an Ice Layer on top of a block acts to reduce the heat level for the purpose of spreading PF. In sufficiently warm areas, the ice layer cannot stay around long enough for PF to spread. PF exposed to heat (including the sun) will thaw; PF covered by Ice will not. But the ice itself might.

So the basic ideas here:

1. PF can spread into cold areas.
2. PF somehow causes ice layers to form on neighboring blocks.
3. A block covered with ice (layer or block) is treated as colder for the purpose of PF spread.
4. Sunlight plus ambient temperature can melt ice layers. This requires a non-ice neighbor. A large patch of ice acts as a reflector, preventing melt. The more non-ice neighbors, the faster. The hotter those non-ice neighbors, the faster. The wetter (and above 40 degrees) of those neighbors, the faster -- warm water is the best anti-ice we know of.

So we have the following operation:

1. On the surface, ice spreads out as a layer. It acts as a heat reflector. PF forms in the ground underneath the ice, and spreads out.
2. In warm areas, in day light, ice will melt. In doing so, it melts from the outer edge inwards, acting as a natural barrier to the spread of PF -- just like night plus torches lets grass recover and delay the spread of CS.
3. If enough ice melts, it will reveal PF, and expose it to the sun -- letting the PF thaw into the original block.
4. Water can be covered with ice as a result of PF. If that water stays covered long enough, it can freeze into an ice block. This in turn lets the PF spread downward; this should be slow.
5. Directly opposite this (# 4), the rest of the water will be warm enough to restrict ice.

What I see as the balance between 4 and 5 (ice on water): right now, I think ice blocks forms on water below 12 degrees. As PF invades, the existing ice blocks would become spreading PF ice, and ice layers would form on top of the ice blocks (deeper freeze), until it reaches the outer layer. Now we're into warmer waters, that will get ice layers, be considered colder, and then get ice below it; this will spread out until it reaches water warm enough to prevent spread.

Alright, this is very preliminary. Consider this a "not quite draft 0" stage.

I like the ideas here...but in reality , ice often insulates and it can be relatively warm below the ice and out of the elements.

What about cloud cover inhibiting ambient temperature & sunlight level? Smog (from fires, torches & mods which heavily rely on burning fuels), fog, volcanic ash clouds & nuclear winter? (I'm sure there's at least one mod that has uranium & nuclear reactors)

So it wouldn't be the permafrost itself that would cause the spreading, it would be the environment. So any dirt block anywhere can become Permafrost if the temp stays low enough for long enough. The permafrost would just require a lot of energy/effort to covert it back to dirt/whatever.

Ice insulates? What will you say next, make a small hut out of ice? Make a giant hotel out of ice? Insulates? Baah.

Alright, need some other mechanic for reducing the effective temp of neighboring blocks to let them freeze ... grr.

(Yea, you're right. I forgot about it, but there is an Ice Hotel that gets rebuilt every year.)

I think that's basically what we're all shooting for, Shavahi. In practical terms, though, there's not much influence of player actions on the environment, besides moving blocks around. Temperature is considered relatively fixed. So the infectious nature of Permafrost becomes more of an abstraction, representing an area of cold that literally drains the heat out of its surroundings. There's a limit to how much heat it can suppress, hence why it would be unable to spread into certain environments, but otherwise effects a lasting change on the local climate that can be difficult to artificially reverse.

In my mind, Cracked Sand is harder to stop the spread of, but easier to get rid of once it's there, while Permafrost would be the reverse...not able as easily to get into an area, but hard to remove once present.

OK, I need something clarified here. Scott, you've said that there is no concept of Temperature and Humidity outside of the biome itself. What's My Light Level is able to display a T and H value per block that does not purely depend on the biome.

I see ocean and extreme hills, mostly at 50/50, sometimes at 40/80.

I see a beach, mostly at 50/50, sometimes at 80/90 next to a jungle.

I see river that is 50/50 or 80/90

I see forest that can be 80/90 or 50/50

Then I see 200/0 in a forest!

Then, a foresthills at 200/0

Then a foresthills at 80/90

Then a forest at 120/90
Then 50/50
Then river at 50/50

Then river at 120/90
Then swamland at 120/90
Then swapland at 50/50
Later, swapland at 20/30
Then ocean at 20/30

I see beach at 20/30 and beach at 50/50

Desert at 20/30 ... and it's a good sized desert at 20/30 everywhere.

Elsewhere, a desert that is 50/50 over a large portion, and 200/0 in the area by the village.

In ice regions, there's an even bigger variation.

A taiga that can be 80/40, or 200/0 (both with ice in the water -- so much for thinking it was temperature based), or 50/50,

Etc.

So What's My Light Level is reporting large variations based on nearby biomes.

So: Is there a per-block concept, or is WMLL going crazy?

Oh! I love that idea @keybounce, if possible you could use a similar mechanism with CS, turning blocks dull grey-brown & having them unusable.

Scott, would you be able to store a complete "subblock", and restore it later? If Permafrost could infect stone/cobblestone/stairs/slabs/anything, and later restore them to their normal state ...

Equally, are you able to "blue tint" an existing block in drawing? So for example, if a stone block were to freeze, could you draw it with a blue tint? If a lever were to freeze, could you draw it with a blue tint, make it non-switchable (since it's now a permafrost block that just looks like a lever), and later restore it to a lever if broken or thawed?

Funny you should mention that, Key. I actually was working on almost exactly that (though to a lesser extent) with my concept. I figured that for most blocks, damage values should be able to give the appearance of a "frozen" block, the same way as each damage value of wool uses a different texture. Similarly, the engine should be able to recognize the DV on a frozen block, and convert it back to the associated block type when it "thaws". It's also definitely possible to have a block drop as something else when broken, as several standard blocks exhibit this behaviour. Going into things like levers might be tricky, though, since that would take something with a specific model, as I understand it.

@keybounce Regarding WMLL...I've not used the mod, but maybe it is reporting biome coloring information? Obviously, as you said, whatever it is doing, it is not reliable...it makes sense that it is coloring, as when biomes border one another, minecraft extrapolates in between color values...You can see this in the leaves of a tree that that straddles the border of two biomes, or grass that does the same. (Each uses a different color map)

Regarding subblocks...I think I could make the permafrost effect destroy vanilla blocks in ways that are recoverable and mod blocks in nonrecoverable ways, providing that the mod author has not adopted support for the permafrost feature in their mod. If they do use the API and adopt permafrost compatibility, Extrabiomes would call their hook when it needs to affect the block...the othe mod would then handle what happens...this allows lots of opportunity for modders here. The "blue tint" may not be done...but if it can, I can hear the first request..."Open it up for texture pack authors to change the color."

@AnonTheMouse Yes...this would require a lot of work...but it might be doable...more practically, if blocks recovers to a similar block type, of which there were only a few types, it would be much easier. In this scenario, things like levers and redstone (and maybe even pistons and lamps) would just be destroyed outright by the permafrost...never to recover.

Well, I found out from iPeer: WMLL's temp and humidity are based on stuff that is now out of date, has not been updated/maintained as minecraft updates (not his code being out of date; Mojang's stuff hasn't kept up. They apparently stopped doing anything with it themselves). It wasn't smooth enough to be the leaf/grass color information. WMLL is no longer even reporting them as of the most recent update.

Ok, so blocks with sufficiently complicated subtypes -- levels, dust, etc -- can't be stored and just get destroyed. What about stairs? They have all their meta data in use to store orientation and upside down, so they are as complicated as they get -- and it's reasonable to have them freeze without being destroyed.

(Not to mention the whole rotatable wood logs that will freeze in place).

So is freezing arbitrary complicated blocks DOA?

Alright, a different idea. We know that blocks can have "containers" -- chests, furnaces, etc, that can store arbitrary blocks.

Can a "permafrost" block have a container, that stores the original block -- and then when the client needs to display it, use that original block information for the display?

That's not as silly as it sounds. Risugami wrote "Shelfs" for single player. It basically does this -- and it alters the appearance based on what is contained in it. But it fails in multiplayer and 132 because it has no extra data until you interact with it.

Do you have a way to solve that -- to get a block whose appearance depends on sub-information -- to display correctly without player interaction first?

If so, you solve this AND shelfs multiplayer.

If not, well, we need to know what can be done with freezing blocks.

ATM, what about only freezing "basic" blocks -- smooth stone, gravel, sand, dirt, farm, grass, mycelium? Should we freeze ore blocks? I envision that a frozen ore block -- if we could do it -- would mine with a stone pick or better, and drop a frozen ore block. Smelt a frozen ore block, and recover a normal ore block. This is both a silk touch work-around, and a way to mine stuff out of stone that normally would require iron.

I'm assuming that frozen stone requires stone to mine, not wood.

What else would make sense to freeze? Cobblestone? Mossy stone? Silverfish blocks -- would they freeze as ordinary blocks with the silverfish dead? Wood logs? Wood planks? I'm assuming leafs would die. Slabs? We've got a huge number of slab types now ...

Scott, if there is no ability to do any sort of sub-block, if all we can do is have a single "Permafrost" block ID, how many different subblocks/subtypes can be distinguised? How many different images can we have? (Implies how many block types can be defrosted out)

... wondering if frozen pistons would just break ...

The container idea has potential...

Simple metadata allows variations. Tile entities can contain whatever data we want...tile entities are used for containers, but also things like Redpower microblocks that have many many subtypes in a few block ids. Containers and redpower microblocks use the same extended storage technology...which is necessarily a resource hog.

So, potentially we could store the information needed to recover the orgianal block. All we need to store is blockID and metadata. The tricky part is what to do about blocks that have tile entities already associated with them...placed chest have an inventory, but a chest itm in your inventory does not. If we only store blockID & metadata, then the recovered chest is empty.

All of this, you can imagine, gets exceedingly complicated the more mods interact...and longer to code, and harder to program...In such a case, CS & PF threaten to take over the mod itself... ;)

Would it be prudent to use thaumcraft decay as a precedent?

Another thought that occurs to me: Frost
Frost would be a "cover" block, and a symptom of Permafrost. Like vines, it would "grow" along objects, though only in the presence of Permafrost. While it can be removed by thawing, it will not melt away until the Permafrost in the area has dropped below a certain level. Meanwhile it has two key differences from vines. First, it is solid, and can block access to things behind/under it. Secondly, it is hard to remove, taking an amount of time equal to wood or stone to break (it should either have no associated tool, or use hoes, due to the need to scrape and pry to remove it). If allowed to form spontaneously on all sides of things like buttons, levers, and pressure plates (tripwires should be unaffected), this could be an effective means of creating an "inconvenience" feature, as players would have to "de-ice" things before they could use them.

I'm thinking that, perhaps, we are looking at too broad a scope. The real question (although I think the container method may prove an elegant solution) is how many blocks need to be freezable? For example, there are already conditions under which a chest cannot open, such as a cat sitting on it, so is there a way to trigger that behaviour? Do chests even need to freeze? With redstone, is there a good reason for low temperature to break it? If so, does it need to break break, or can we just prevent/limit the signal travelling somehow? For example, can Permafrost emit a negative redstone signal, thereby inhibiting any other signals sent?

Not familiar with it, can't comment. Brief explanation please?

Ohh, recursive meta data. Not only does a chest contain a bunch of items, but any mod might have a bunch of items -- like shelf. So any block could have meta data, and you'd need to walk each item's meta data, and any of those items in turn might have meta data (like an age linking book), and any of those might be more data (imaging a bag, a mini storage item that holds 4 stacks, but can be placed inside a chest -- then you'll find a chest, recurse it's contents, find a bag, need to recurse that ... ouch).

Ok, I think a simple answer to the recursive issue is this:

Any block that you can interact with will "freeze" as an unchanged block that you cannot interact with.

So a chest is unchanged, but permanently frozen shut.
A crafting table is still a crafting table, but unusable.

That should solve all issues with containers.

The question is: Does that solve linking book stands with a book on it? Does that solve Tome bookshelves containing age books?

If it does, then we're probably past the worst issue.

For redstone devices, how about: They cannot change state. They "Freeze" in their existing state/position. No change in circuit status happens. This is the only way I can think of to solve the question of "What state is an inverter in?". You can't just say "Redstone is off", or you have to deal with a torch that isn't lighting dust, or just what is the state of a torch connected to an unpowered block. (Or what happens to a torch connected to a powered block when the power freezes off yet the torch has to stay off.)

Note that this means a clock type circuit will freeze in a single fixed state, and might be in an invalid state on defreeze. Someone might actually design a circuit around detecting frost/thaw that way.

I was thinking it might spread up from the ground, but essentially yes. Grant you, I am not saying that Frost should replace Permafrost, but it could do some things that a block proper cannot. So, some blocks would become Permafrost, while others would simply be iced over and inaccessible.

Hmm ...

So frost would simply grow horizontally and downwards in permafrost regions. And, frost could spread next to frost.

If I understand correctly, this means that frost would replace air blocks, basically acting as a spreading ground cover. It doesn't so much replace/alter ground blocks as just make it hard to reach them.

... let me know if I understand this correctly... thinking of caves and ravines ...

@keybounce Problem with disabling blocks is you must replace the block with a disabled version, unless the block supports being disabled...locked chest was a different block from chest. So..I could (I think) make a block that takes on the appearance of another and this would work except for blocks that have custom renderers, like book stands. The penalty would be large resource use, because each disabled block would really be another instance of the same block...and the block would have to keep track of all of its instances and the coordinates of each and what it is supposed to look like at those coordinates, including the text string denoting the path to the texture file and all of this must survive the saving process and mod deinstallation (when the texture file disappears--normally causing an NPE)

Edit: Just like the Secret Rooms mod does...!

Whatever our solution, it needs to not require a ton of new development...as there just isn't the resources. We need to simplify...

Also, regarding Thaumcraft, I was hoping one of you would install it and see how its taint affects blocks from other mods...I think it has no effect...but I'm not sure. There may also be a video or two...

So I am thinking we have the following pair of mechanics.

1. Frost. Frost spreads at ground level, over the ground. It is a full block, it goes on the surface over existing blocks. Frost has a very low chance to form on top of an existing frost block; the more frost blocks on the top of a pile (normally; see caves/ravines), the less likely it will get another block on top.

Frost spreads when there is no sunlight. Tall piles of frost can start to melt when exposed to the sun or "hot" light (torches, jack-o-lanterns, but not redstone lamps or glowstone). Between the reduced chance to grow as the pile gets taller, and the melt in sunlight, there is a stable point.

In permafrost biomes, the chance of piling up is higher; this means the frost pile will be taller in permafrost, and shorter in normal biomes.

Frost only spreads horizontally, to air blocks. It can spread up, to go up a hill, but at a reduced chance, and only if that upper block has a snow layer on it.

Frost has a very small chance to spread snow layers on the neighboring blocks.
Frost is more likely to spread to a block if it has snow.

Frost will melt faster in hotter biomes.

Frost basically represents an accumulation of snow, combined with the idea that the snow is going to reflect heat, cooling the area, to permit more snow.

Finally, frost will not spread in dry biomes.

In short, the rules:

1. Frost spreads more in colder biomes, and wetter biomes.
2. It spreads taller in frost biomes.
3. It tends to spread snow around it first.
4. It tends to spread slower up a hill.

Caves/ravines:

Frost blocks are affected by gravity. If frost would spread horizontally, and that horizontal spread is over air, the frost block falls down. This permits ravines, depressions, caves, etc, to start being filled in.

• If Possible: Give frost a 45 degree slant/fill. So a cave that goes down at an angle will have the entire entrance start to be covered with frost.
• If not possible: Just let the mouth entrance freeze over, and then let frost spread normally down there.

Frost is removable with either shovel or hoe.

1. Permafrost:
   Frost that is touching a basic block -- any of the surface blocks (grass, mycelium, dirt, sand, sandstone, gravel), stone, cobblestone, mossystone, chiseled stone, or any of the ore blocks -- will freeze that block.

6 surface blocks.
4 types of stone.
6 types of ore

That's 16 blocks (4 bits). That's one block ID. It fits nicely.

Freezing a silverfish block will kill the silverfish and result in a plain block of that type.

A frozen block is mined with an iron (???) or better pickaxe, regardless of the original.
A frozen block can be smelted to recover the original block.

In this model, there is no "Permafrost" block. There is spreading frost, and frozen normal blocks.

Q: Should it be iron? How about stone? How about gold? Normal stone can be mined with wood; how much harder should frozen stone be?

Note that a frozen surface block is no longer mineable with a shovel.

acck, forgot clay. Recount:

Grass, mycelium, dirt, clay, gravel, sand -- the 6 surface shovel blocks.
Stone, sandstone, cobblestone, mossy stone -- the 4 normally seen stone pickaxe blocks.
6 ore blocks

This still gives 16. It means that chiseled stone won't freeze. It means that the two special types of sandstone won't freeze. It means that the cracked sequence blocks won't freeze. Farmland will freeze as dirt in this model. Grass and mycelium can be frozen and harvested; this will permit people to move these materials without silk touch.

Special note: If the idea is that frost is a piling of snow, and it makes neighboring areas snow by reflecting heat, then one idea to consider is actually making more than one level of snow layer. Maybe have three deeper layers of snow, and when a 4th layer of snow would be placed, turn it into a frost block.

This would actually result in the following:

1. Snow falls normally. Snow can fall on snow. Once 4 layers of snow are in one spot, it becomes frost, and neighboring blocks can snow even if they would not normally snow.
2. Ravines/caves: If you are next to a frost block, then no matter how far down you are, if you are exposed to the sky, you can gain snow.
3. Snow expanding up the hillsides becomes normal behavior in this model.
4. Frost does not spread inside caves. The whole "snow/ice is an insulator" idea now takes over. The cave mouth will be covered, but the inside will not spread.

Note that using a shovel on a deep pile of snow will generate more snowballs.

In this model, you still have sunlight and heat lights melting snow and frost. Additionally, you have the vanilla model that any artificial light 12 or better prevents snow from forming.

Result: A very different model and spread than cracked/dry blocks. Different effects, with a potentially desirable outcome -- being able to grow freeze-dried grass and mycelium for transport/replanting. And, harder to harvest ores (requiring twice as many smelts.)

Note also: That model does not have room for mod ores. It might be possible to support 16 mod ores with one more block, but it's also likely that there are a lot more than 16 in some mod packs/complicated addons.

@keybounce @AnonTheMouse Once you guys get this worked out, please put it on the wiki on oneone-whakaaro. If you wanted to go ahead and put it up, there is a section for DDs in progress...create a new page, link from the main one in the appropriate place and then work on it there if you like.

@AnonTheMouse @keybounce I sent Anon's proposal two both of you for comment by PM on MCF...if you have not received it, please let me know and I will resend

I'm not sure on full-block frost. Might look a little wonky, but what about having it increase by slabs? One advantage there would be the ability to create even more irregular terrain.

As to the frozen blocks, are you taking red rock and its variants into account? What about quicksand? It might be easier to do two types of "freeze" block, one for soft blocks, and one for hard (stony) blocks.

(Also, have you gotten to look at my version of the proposal yet?)

Baah, Anon is right, I did not take into account all the new blocks.

Scott, here is a big question: If we want Permafrost biomes to be defined by blocks freezing, how many blocks can you handle freezing?

Assume we won't worry about blocks with interactions, tile data, entity data, containers, facings (stairs), etc.

Just the idea of making ordinary ground that much harder, harder to dig, harder to work with, etc. What is the block budget?

Anon, I did see your proposal. But I didn't have enough information/knowledge to even begin to understand it enough to comment.

Before I could, I had to write up a proposal myself for the idea of spreading coldness, get it shot down, learn more about the limits of what could be done, etc.

I think I'm now ready to go back and re-read it, and understand it/comment on it.

Oh: Layers, slabs, etc: Roughly speaking, a layer is 1/4th of a block (I suppose I could go in and actually count the pixels next time I play), a slab is 1/2 of a block, etc. Hence the idea of "4 layers of snow = one frost block" as a way of letting permafrost pile up.

We need a generic way to handle block effects for vanilla blocks, whether they degrade to something else in an unrecoverable way or something else...as far as block budget...blockIDs are semi precious, and using them increases cost of using the mod...so If we could do this in one block id (or even have cs and pm share an id, that would be the best...design as if additional blocks are a luxury that we may not have...an consider it as a very real contingency.

You guys can keep this here if you like...but the semi private wiki was made for you guys to do this and hide some of how the sausage is made, if you want to take advantage of it...This thread cannot be used as the final result as it is much too unwieldy.

Alright, I just realized: I have no idea what the actual T/H's are for biomes. Since I now know that what I had been relying on is inaccurate, where can I get a chart of what the actual vanilla and EB biome figures are?

@tahg made this chart.

Also, I think it would be nice to use the wiki to keep track of what parts of the design you guys have agreed on...I have no idea where we stand...

Scott, would you rather we continue this back-and-forth here (which I like, it gives a sense of order to the ideas), or on the wiki (which makes more sense, I think, for what we've come to an agreement on).

@AnonTheMouse : Here is my comments on your design idea now:

ATM's design ideas:

Limitation (Speed): Permafrost spreads slowly, perhaps a third the speed of cracked sand. This is to compensate for the lack of a transitional period and the wider number of block types able to be converted.

The lack of a transition is a non-starter. There has to be some sort of "in progress" indication.

I was playing around with cracked sand. The idea of being able to fight back CS; that grass -> dirt could be reversed kept it interesting and fun. The idea that night time plus torches would allow the grass to recover, to hold back the sand, was huge.

I also keep in mind the idea of a server that is up 24/7, that never unloads because people are playing all the time. You know, the 30-100 person servers.

You're not going to expect everyone to want to fight these things. In fact, I realized -- and pointed out -- that someone could harvest CS (at the time I thought you needed silk touch; I did not realize it was that trivial to get), dig up some land in the wilds outside an enemy claimed zone, put CS underground, one block below the surface (til the surface into farmland, plant wheat, and sit back), and just watch CS spread into the enemy base causing all sorts of "fun".

The point is, the idea of "rain naturally rehydrating to put a limit on the spread" was key. Something has to be able to both restrict the spread, or have a "fight back", as well as recover the land after it spreads. What we don't want is anything that can become an unrestricted decay block outside of a Myst age. (And a variant of CS/PF that does not stop might make a great Myst instability idea).

Hydrated farmland has a transition of dry farmland. Playing around with grass/mycelium borders gives dirt as the transition block. Etc.

As a player, I don't like the idea of "poof, no warning". I really dislike the whole "til the dirt into soil, it is hydration level 1 instead of 2", which results -- very often, sadly -- in the soil turning back to dirt before I can get the seeds in the ground.

So some sort of transition is going to be a must for the players. I've been looking at layers, at alterations to the air blocks prior to altering the ground blocks, etc.

Hazard (Depth): When there is no adjacent block for Permafrost to spread to, it will begin to spread downwards. The maximum depth it can travel depends on the temperature of the biome (perhaps ranging from seven blocks in core regions to only three in the warmest areas. Underground permafrost will not automatically be reached by methods that may thaw the surface, and can spread upwards to retake the surface if the conditions there change. Permafrost will represent a different challenge from Cracked Sand in this way, as it will be easier to prevent, but harder to be permanently rid of.

This was probably the hardest for me to understand before, although now I think I understand it, and really dislike it.

Cracked sand, outside of the wasteland, is basically a surface condition -- extreme dryness that dries out the nearby land, dryness that spreads on the surface. Dryness is the spreading factor; the cracked blocks is the outcome of that dryness.

Permafrost is the spreading of deep cold. Frost spreads, and causes coldness nearby, allowing more land to freeze, and spread coldness more and more. That's like a spreading ice sheet. That's like an ice age.

To say that the coldness, once established, spreads downwards, slowly? Fine. No problem.

To say that the frozen blocks then spread once the coldness is gone? No.

The spreading coldness is the cause, just as the spreading dryness is the cause. The frozen blocks is the outcome, just as the cracked blocks is the outcome.

This means that the key feature of permafrost blocks -- just like a cracked block -- is that it is the source of what makes other things cold -- hence why I've been looking at ice layers, snow layers, spreading frost blocks, etc. It spreads coldness, which in turn causes freezing.

But get rid of the coldness factor, and there's no more spreading freezing. There may be blocks left that did not thaw, but those are not a source of additional "make it cold", they are merely "have been made cold". Like leftover sandstone after getting rid of CS.

Limit (Light): Permafrost spreads best in darkness, when temperatures would be lower. Higher light levels decrease its spread speed, down to nothing at light levels twelve and above, and lower levels can increase it up to its maximum rate. Weather will not have a direct effect on Permafrost spread, but may exacerbate it due to diminishing light levels.

The funny thing about light and heat. Skylight does not equal heat in this game; "burn light" (the "bl" factor on F3) does. Existing freeze effects, such as snow/ice, are curtailed by BL levels of 12 or better -- hence the diamond around torches. Now, whether these should be broken up into heat sources/non head sources (example: redstone lamps, glowstone) or not isn't a big issue. As much as I like it, it goes against the established game rule of "any artificial light is hot".

Should skylight have an effect? Using real life as an example, spreading ice reflects the skylight reducing the heat absorption -- so skylight does not heat up or stop ice.

Hazard (Cold Stone): Although they cannot be converted directly to permafrost, Cobblestone, Stone, and Mossy Cobblestone may be converted to "Cold Stone" variants, with a frosted appearance and the ability to spread permafrost. Cold stone cannot be collected, but instead drops its "normal temperature" form. Cold stone requires higher temperatures to thaw then permafrost, but also only forms in colder areas, so that fringe zones may lack it entirely.

We've been discussing something very much like this, with frozen stone/etc blocks coming out of the spreading frost conditions. I definitely like this idea.

Trees should lose their leaves.
Planted crops should wither/break.
Water that is touching either Permafrost, Cold Stone, or and Ice block within five blocks of one of the same should convert to ice. (If necessary, this could mean creating a new variation of ice that is harder to melt, in which case it could simply spread through water as Permafrost spreads through ground.
Optional (Sinking): One of the real-life difficulties of Permafrost is the danger that structures built on it will cause the ground below them to thaw, leading to the structure sinking. Possibly, this effect could be simulated in Minecraft, requiring structures built on permafrost to be placed on fence-block "stilts" if over a certain size, or 0-N blocks of permafrost beneath each square of the building (where N is the maximum permafrost depth) will despawn, dropping the blocks above them into the created hole in a manner similar to Mystcraft decay.

These I saw the first time, and mostly agree with. I like the idea of leaves going poof, of wood logs freezing, of plants dying, etc. I don't think we have the block budget to freeze 4 types of logs with 6 facings each -- that's 24 blocks (heck, it's 12 blocks in vanilla's three facings). There's even more, actually -- Bunyan adds three woods, EB adds 1 (2?), other mods add other woods -- iick, figure at least 10-12 wood types. Even 16 wood types with facing -- no, you just cannot afford the block budget to freeze wood.

I don't like sinking in normal worlds; maybe as a Myst decay mechanism. Even if the idea is that you thaw out the ground below, the result should be that block just melts. Now, if you built on a frost block, have it fall down, fine. If you built on ground (dirt, stone, etc), and it thaws, it just goes back to normal without falling.

I have put up on the wiki what I think we have agreed on.
https://github.com/ExtrabiomesXL/oneone-whakaaro/wiki/Permafrost-ideas-back-and-forth-hashing

Ok, I think there are problems with that chart. See my version (resorted) here:
http://pastebin.com/U4aNMzyx

First: Savanna is just like desert -- 200% temp, 0 humidity. Is that accurate?

Second: Mountain taiga is defined as 0 temp but taiga hills rain. Accurate? Meaningful?

Third: Snow Rainforest is defined as Taiga Hills temp, but a number for rain (not a biome based rain). Meaningful?

Beyond that, just the following given numbers instead of relative to an existing biome:
Birch Forest .4 .7
Temperate Rainforest .6 .9
Lush Redwoods 1.1 1.4
Rainforest 1.1 1.4
Redwood Forest 1.1 1.4

That chart isn't useful. Not really.

First, it does not include vanilla stuff.
Second, it lists some stuff in terms of vanilla stuff with modifiers. Which is more accurate -- modified vanilla, or absolute numbers?
Third: Meadow: default: What does that mean?

One more note:

Forestry assigns biomes to ranges for temp and humidity: see enumTemperature and EnumHumidity.

Our numbers were chosen so that each biome would end up in the correct category for Forestry's purposes while retaining the colors that were chosen for it by the original Extrabiomes team. For this reason...the temps make sense when viewed by categorized ranges, but not necessarily when viewing the individual numbers. (In fact @tahg chart was done for texturepack authors ro know how to alter the foliage color and grass color textures.)

Hmm. The info from Forestry seems the most useful to establish a baseline. Is there any way to move this whole discussion into the 11W issues, though?

So the next question: Are you able to examine all the biomes registered with the system, and determine which blocks are "surface" / appear in that biome, and determine which ones are shovel blocks and which ones are pick-axe blocks?

Can you do so in a way that is consistent -- the goal here is to get two blocks of frozen blocks. For example, could you determine that grass would be shovel:0, dirt shovel:1, mycelium shovel:2, etc, in a consistent manner? Such that redstone might be pick:6, red cobblestone might be pick:7, etc -- all in a consistent way?

The goal is to keep the block budget for frozen blocks to two block ID's each with 16 subtypes. One for the stuff that originally was shovels but is now frozen, and one for the stuff that was originally pick-axe but is now frozen. We know, as AnonTheMouse pointed out, that mods will add this stuff -- you add red stone, red cobblestone, and I think red clay. (Hmm, just had a typo. So what happens if I take that red stone, and grind it up into dust?). Other mods might add something else. But if we store a block as block ID 227:8, we need to make sure we have the same mapping to original block after thaw.

Can this be determined dynamically, to adapt to mods that people add? Or do we have to have static lists?

(/em goes and reviews forestry ...)

The more I think about it, the less I understand what the values are supposed to represent.

Take humidity/rainfall, for example. It can't actually be humidity -- oceans have too low a value, and in general the numbers are too high (30% to 40% is the normal range).

As rainfall? If 50% is "normal" rainfall, then it becomes possible to say that you have higher than 100% -- a rainforest might have 4 times the normal rainfall for 200% here, and we see several biomes in EB that are over 100%.

Temperature? As a percentage? Err ... wha?

It has been a while since I have probed through the temperature code...I'll look tonight...but basically, @tahg chart is correct and drawn straight from our source code.

As I recal;, Temperature and humidity are represented by a float in the range of 0 to 2.0. For color picking, these values are clipped at 1.0...So a desert at 2.0 temp and another biome at 1.0 temp have the same foliage + grass colors.

Meadows value of default means that it takes whatever temperature minecraft assigns to biomes as a default, which is the what also happens with vanilla plains, as I recall.

We did not focus so much on temp and humidity until we integrated forestry. To my knowledge Forestry is the first mod to really utilize these numbers and does so for logical spawning of beehives.

Our numbers are set relative to vanilla biomes as much as possible, to reduce maintenance should minecraft change the ranges that they use. For instance, Mountain taiga is vanilla taiga hills at a higher elevation...therefore humidity is the same (which is why there is similar vegetation), but temoperature is lower due to elevation.

There is not a large amount of play in these numbers because in the vanilla game these are mainly used for color choice...wise or not.

Keep in mind that there is no guarantee that what we call humidity and temperature are actually humidity and temperature in Mojang's code...only that someone on the MCP team thinks that this is what these are based on some loose associations. While almost exclusively used for color picking, the temp number is used for dealing with snow and the temp number roughly tracks to what seems logical relatively for vanilla biomes

I would say don't let this be a red herring...

Ok, so as I understand it then, all we would need to worry about is how to freeze vanilla blocks. Then anyone that adds new blocks (such as those new clay and stone blocks, or that sinking sand block) would worry about freezing their own stuff and we don't have to. Right?

That makes it much easier.

If that's the case, then we have 16 blocks to worry about, and we can freeze all the vanilla surface and stone type blocks. That's enough for frost/deep freeze to be a factor, and small enough to not be a block count problem.

Then, once we get that going, someone else (you :-) can worry about freezing red stone, or red clay, or quick sand, or cracked sand, or tin, or copper, or ...

Now, forestry. I tried to understand it. Really. The forum thread describes it pretty simply -- machines that can grind up a landscape, churn out fertilized soil, plant trees, harvest the wood, drain the soil, and chew up fertilizer in the process. Plus the need for fuel, a power factory, etc. Works with chests, can work with pipes, but doesn't need them. All fine and dandy. Might even be worth using.

But there's nothing in that description that really says anything about everything else. So lets look at that overview graphic that is supposed to help you keep the mod straight ...

err ... omg this is ginormous.

Reading the description at http://www.minecraftforum.net/topic/700588-forestry-for-minecraft-trees-bees-and-more-1500-updated-27082012/ just tells me about the harvester/planter/fertilizer issues, the new mineral for fertilizing, the engine, etc.

The picture at http://forestry.sengir.net/wiki/index.php?n=Main.Visualization ... has about 3 times as much stuff as that.

And the wiki ... eek, needs a "start here" document.

Alright, I've set up a new issue on 11W, so we can keep this one free of things that don't need to be public just yet.
ExtrabiomesXL/oneone-whakaaro#2

@AnonTheMouse you can create an issue there and link back to this one. To linkyou just type: #50

@keybounce this is doable, but I am going to let mod makers handle their own blocks through the API.