Some semi-random thoughts on terrain generation
There's one thing that would be very great to have: a pre-simulator finisher. It's job would be to move floating sand and gravel to the ground and making water in the ocean stationary, except for the borders (so that the simulator doesn't get overwhelmed when a new chunk is generated / loaded and the water still flows where it should).
Reply
Thanks given by:
Some fun facts about WormNestCaves:
In each chunk, it sets 2990 blocks to air, on average; out of those, 2339 blocks on average are set multiple times.

Now, the question is: is it faster to iterate over all cave's definition points and for each point carve a sphere around it (current algorithm), or will it be faster to iterate over chunk's blocks and for each block calculate the distance to each of the cave's definition points?

I'm afraid I'll have to try that out in order to find out. And it's probably gonna be different results for different architectures - I think the latter will be much faster on ARM, because it will use much less memory access, which seems to be the bottleneck there. On IA-32 and AMD64, I expect both methods to be more or less comparable in speed. But who knows.
Reply
Thanks given by:
R981: don't forget to add that also to the ravines Smile
Reply
Thanks given by:
i created a death bushes finisher for in the desert.


Attached Files
.txt   Death Bushes.patch.txt (Size: 4.28 KB / Downloads: 220)
Reply
Thanks given by:
I tend to believe that those are "dead bushes", but screw this, death bushes FTW! Smile
On a related note: maybe someone mind writing code for setting ore sizes and appearance rates via .ini? I had noticed that those are actually hard-coded values already presented in source, so it should be easy. Would appretiate that.
Reply
Thanks given by:
hmm it could be dead bushes indeed :S
i found a "bug" (its not a bug but i don't know how to call it Sad)
in the presimulatur. becouse the presimulator generates the sand ontop of water and lava. not in the water/lava.
Reply
Thanks given by:
(11-11-2012, 02:01 AM)Taugeshtu Wrote: code for setting ore sizes and appearance rates via .ini?

It is on the "List of tasks easy enough for newcoming programmers":
https://forum.cuberite.org/showthread.php?tid=503

True, we don't have so many newcoming programmers, so I could do this, anyway Smile
I haven't sorted out in my mind yet, though, what syntax to use. Do we want to enable the orenest generator to generate other stuff, too? (imagine that - a vein of netherrack, or water, or cobwebs Smile ). If so, how to configure those additional blocks? I'm open to suggestions here.
Reply
Thanks given by:
Quote:Do we want to enable the orenest generator to generate other stuff, too?
HELL, YES!
A veins of air would be really awesomeBig Grin

On syntaxis:
[OreNests]
OreNestType=Air
OreNestMaxHeight=65
OreNestAmmount=10
OreNestSize=15
OreNestBiomes=Jungle (this one isn't necessary, but could be really nice, if done)
OreNestType=Netherrack
OreNestMaxHeight=20
OreNestAmmount=3
OreNestSize=50
OreNestBiomes=

So, in my mind it should be parsed like: (pseudopseudocode)
Code:
for (c = 0; c < NumKeys(OreNests); c++) {
  if (GetKey(c) == "OreNestType") {     // means we're parsing data for new ore type
    if (_ore_description != NULL) { RegisterOre(_ore_description); }
      _ore_description = new OreDescription( GetKeyValue("OreNests", "OreNestType") );
  }
  if (GetKey(c) == "OreNestMaxHeight" && _ore_description != NULL) {
    _ore_description.maxHeight = GetKeyValue("OreNests", "OreNestMaxHeight");
  }
}

So it will eat "sections" of keys and will arrange ore with specific types with given settings.
Reply
Thanks given by:
The ini files really should not have multiple values with the same name in a single section. And very specifically the order in which the lines appear must not be critical to the application, because the lines may be shuffled at any time.

Of course, MCServer has already broken the first rule, but I'd like to keep that breach to the minimum (currently only Plugins and Worlds). And we haven't breached the second rule at all. Actually we make it very important not to be broken - MCServer's parser already shuffles the lines, moving all the comments to the top of the section.
(11-12-2012, 01:07 AM)Taugeshtu Wrote: A veins of air

Otherwise known as caves Wink
Nicer syntax:
Code:
[Generator]
Structures=OreNests,...
OreNests=Iron,Gold,Air,Water

[OreNests_Iron]
BlockType=ironore
Size=8
Count=5
MaxHeight=63
Biomes=

[OreNests_Water]
BlockType=water
Size=12
Count=3
Biomes=Jungle,Swamp

...

Problems with the syntax:
- what if the orenest is declared in the [Generator].OreNests, but its corresponding section is not found?
- what is a parameter from the section is missing? What default to use? Especially for Size and Count
Reply
Thanks given by:
(11-12-2012, 01:12 AM)xoft Wrote:
(11-12-2012, 01:07 AM)Taugeshtu Wrote: A veins of air

Otherwise known as caves Wink

something like this would be cool: http://www.google.nl/imgres?um=1&hl=nl&s...1,s:0,i:72
Reply
Thanks given by:




Users browsing this thread: 37 Guest(s)