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).
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.
I tend to believe that those are "dead bushes", but screw this, death bushes FTW!
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.
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 )
in the presimulatur. becouse the presimulator generates the sand ontop of water and lava. not in the water/lava.
True, we don't have so many newcoming programmers, so I could do this, anyway
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 ). If so, how to configure those additional blocks? I'm open to suggestions here.
Quote:Do we want to enable the orenest generator to generate other stuff, too?
HELL, YES!
A veins of air would be really awesome
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.
11-12-2012, 01:12 AM (This post was last modified: 11-12-2012, 01:18 AM by xoft.)
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
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