When generating chunks, TerrainControl will usually generate ore as indicated, but will sometimes spawn very little ore, aligned in thin planes on the XZ axes, and will sometimes spawn almost no ore at all.

This has been tested mostly using CraftBukkit Beta Build 1.4.6_R0.3.
It has been tested mostly on a system running Java 7 update 11 (JRE).
It has been tested with 1024MB ram, and with 4096MB ram dedicated to CraftBukkit.
It has been tested using TerrainControl 2.3.6 and dev version 2.4.5.

In all cases, the test was done by slightly modifying a stock, vanilla TerrainControl configuration. The changes made are as follows:

• Increased LandRarity in WorldSettings.ini to 100, to decrease ocean frequency
• In all biome config files, set ReplacedBlocks:(1,0),(2,20),(3,0),(9,0),(12,20),(24,0)
• In all biome config files, delete all SmallLake resources
• In all biome config files, delete all UnderGroundLake resources
• In all biome config files, delete all Liquid resources
• In all biome config files, delete all Ore(GRAVEL...) resources

This has the effect of turning the surface to glass in most places, and leaving the area below mostly open air except where ore has been generated. It also disables most blocks that cause extreme lag due to gravity (water, lava, gravel, sand). It should leave Ore generation (aside from gravel) untouched.

Forum thread with more details:
http://dev.bukkit.org/server-mods/terrain-control/forum/47501-ore-generation-is-highly-erratic/#p17

Imgur album with documentation:
http://imgur.com/a/7qze8#0

I will be happy to continue testing in any way that the developers desire, and I will remain active in the referenced forum thread as well. I am creating this ticket because I believe this is a bug in TC, and would like to help in any way possible to get it fixed.

(Note1, when I mention 'top', I am referring to my images from the perspective that they are seen as in the isometric dynamic map view. The top half is equivalent to the region -z>x.)

(Note2, I discovered more things as I went along, so some earlier statements may be partially contradicted later. I suggest experimenting yourself with similar changes to those that I have done through the course of this comment.)

I can definitely agree that something is very broken here. Using a single biome I can get very similar, but also very different results:

1)
I ran a test using an entire world made from one biome whereby all the smoothstone was replaced with air and the surface and ground blocks were also set to air.

The specific resource queue used for the biome is

UnderGroundLake(25,60,2,5.0,0,50)
Dungeon(31,100.0,0,128)
Ore(DIRT,16,20,100.0,0,128,STONE)
Ore(COBBLESTONE,16,20,100.0,0,128,STONE)
Ore(COAL_ORE,8,20,100.0,0,128,STONE)
Ore(REDSTONE_ORE,3,8,100.0,0,16,STONE)
Ore(DIAMOND_ORE,3,1,100.0,0,16,STONE)
Ore(LAPIS_ORE,3,1,100.0,0,16,STONE)
Grass(DEAD_BUSH,0,4,30.0,SAND)
Cactus(LOG,10,30.0,0,128,SAND)
Liquid(WATER,20,100.0,8,128,STONE)
Tree(30,Tree,100)
CustomObject(UseBiome)

There seems to be 3 major areas of ore generation:
http://www.gamingmasters.org/attachments/wastelandsisscrewed-png.3625/
'Normal' generation: This is what you expect and is the much brighter area shown in the above image.
'Edge' generation: Ore veins only spawn on X value 15 in chunks. This is the blue area with a reasonable amount of green specks.
'Corner' generation: Ore veins only spawn on Z value 15 and X value 15 in chunks. This is the almost entirely blue area. (worldborder was used to fill a lot of the terrain out)

2)
In a second test with BiomeHeight:-4.0 and

Ore(COAL_ORE,3,4000,100.0,100,200,AIR)
Ore(REDSTONE_ORE,3,4000,100.0,100,200,AIR)
Ore(DIAMOND_ORE,3,4000,100.0,100,200,AIR)
Ore(LAPIS_ORE,3,4000,100.0,100,200,AIR)

All ores seemed to generate as expected, high up in the air.

3)
In a third test with values similar to the first, though using worldborder to generate all the terrain around x=0 y=0. This produced what I can only really describe as a smoother version of the first test's result. Seemingly correct generation (the majority of the ores) filled the bottom half almost exactly, the top left was only creating the ores when x=15(coordinate inside chunk) and the top right when x=15 and z=15.

4)
In the fourth test I used

BiomeHeight:-0.5 [my default value for this biome normally]

SurfaceBlock:0

GroundBlock:0

ReplacedBlocks:(STONE,AIR),(GRASS,ICE),(LAVA,ICE),(STATIONARY_LAVA,ICE)

Ore(COAL_ORE,3,4000,100.0,10,20,AIR)
Ore(REDSTONE_ORE,3,4000,100.0,10,20,AIR)
Ore(DIAMOND_ORE,3,4000,100.0,10,20,AIR)
Ore(LAPIS_ORE,3,4000,100.0,10,20,AIR)

This is where things got more interesting.

With the seed 6619741177147290683 (was random), at -150x -80z it looks like the ores are replacing the air blocks that would have been there if "ReplacedBlocks" had not been used as there is often air above the lava (which has been turned to ice). For some reason, this happened around the initial spawn of the map only. Outside of this area but in the top half of the map the ores seemed to generate properly.
http://i.imgur.com/bJuccjC.jpg
Moving over to the bottom half of the map, mostly on the left side, the ores are spawning as if blocks haven't been replaced, and they're spawning along Z=15 (in each chunk) as well. Then, mostly on the right side, the ores are again spawning as if nothing has been replaced, but also along X=15 (in each chunk). However this doesn't apply everywhere, as in some places, there doesn't seem to be any ores other than those that would spawn there if nothing was replaced.
http://i.imgur.com/wswO6hy.jpg
http://i.imgur.com/OJdMl8m.jpg (note, in this image, where the white text is saying about all the extra ore being on Z=15, that is not entirely true, as somewhere along the arrow, it becomes X=15 instead of Z=15.

5)
And now my 5th and final (for now) test:
Using the same config as before, but using:

BiomeHeight:-0.5
SurfaceBlock:0
GroundBlock:0
ReplacedBlocks:(STONE,AIR),(GRASS,ICE),(LAVA,ICE),(STATIONARY_LAVA,ICE)
Ore(COAL_ORE,3,4000,100.0,10,20,AIR)
Ore(REDSTONE_ORE,3,4000,100.0,10,20,AIR)
Ore(DIAMOND_ORE,3,4000,100.0,10,20,AIR)
Ore(LAPIS_ORE,3,4000,100.0,10,20,AIR)
Ore(LOG,3,4000,100.0,40,50,STONE)
Ore(NETHERRACK,3,4000,100.0,40,50,AIR)

I have used logs and netherrack to differentiate between what the plugin is seeing when it is trying to place these resources. If all of the stone was replaced with air before the resources were added, no logs should appear at all.

If the resources were added before the stone was turned into air, I should see lots of logs and the occasional few pieces of netherrack where ravines and caves should be (as I haven't turned them off).

What happens is, that upon teleporting to x=0 z=0 (a completely not generated area), the top half is almost entirely netherrack with the occasional log lying along Z=15 for that chunk and the bottom half is almost entirely logs with the occasional netherrack with a reasonable amount lying along Z=15 for that chunk. When travelling up from here, more netherrack is generated, and when travelling down, more logs are generated. It get's more interesting when teleporting to a position higher up, moving down will generate more logs, until you reach the netherrack from the area below. If you had teleported back to x=0, z=0 and moved up toward the new area you generated, you would generate more netherack, until you reach the bottom of the second area you generated, which is filled with logs.

This leads to one possible conclusion: The ore population differs depending on the direction in which the chunks are created.

Here is an image of travelling left from my perspective in-game, white is the path I took, green is the direction I'm looking (if that matters): http://i.imgur.com/p2pVB2Q.png

Here is an image showing how the direction of travel greatly changes the distribution of ores generated: http://i.imgur.com/k7u0XlT.png

Conclusions: the direction being travelled in when the chunks are generated changes the outcome of the generated chunk. My best guess, is that the chunk is being populated with ores at the same time as it is having its contents replaced with other blocks as opposed to blocks changed first then ores are added, or vice versa. Somehow resulting in the last line of the chunk to be generated (usually Z=15) having its ore added before it has its block replaced (or the other way around if you're travelling in the opposite direction). The one thing I don't know, is how the times when X=15 have occured (and I have no idea how the times when it's been both X=15 and Z=15 at the same time have occured)

Hopefully some of the information here will be useful in tracking down the actual cause of this bug. I will attempt to look through source code tomorrow, when I'm more awake (I wouldn't count on anything, I'm still very new to java and making bukkit plugins). All I know that is certain, is that something is really not working properly. 😕

Saw your thread on the forums. I wonder what's causing this. I can't find any obvious bug in the ore file.

Hmm may you try to regenerate ( with WorldEdit ) this bugged areas with show screens ?

@rutgerkok ~
This makes me want to learn how to compile java so I could fiddle with those variables and test.

@Wickth ~
I'm not sure what you mean by "with show screens," and I'm an extreme novice with worldedit. As in, I just now installed it for the first time ever.

I did attempt several quick regenerations, and what I can tell you is that it seems to result in ONLY "empty" ore areas, even where there had previously been heavy ore placement.

I tried to search for "worldedit show screens" and didn't find anything helpful. If you tell me how to do that, I would be happy to oblige and get you better data.

Oh sorry, this was my bad english :(

I meant "make screenshot after regeneration"

Ah! I apologize, I just assumed this was a WorldEdit option I didn't know about (because, like I said, SUCH a noob).

I did document my //regen attempts with screenshots, and I will upload them tonight to my Imgur album.

I can tell you the result though: no matter where I performed the regeneration, it resulted in almost no ore. Just like in my "empty" screenshots from the original album, there was significantly less than a cluster of ore for each chunk - like, maybe one BLOCK of ore for every two chunks, or so.

Anyway, I'll upload that data in about 10 hours when I get off work.

Sorry, delays again. I've created a new imgur album to keep the results of the tests apart. That album can be found here: http://imgur.com/a/JSbJ7#0.

Although I am not fluent with Java, I can interpret code fairly well and I agree that there's nothing obvious about the oregen file. I'm curious if instead the issue could be whatever it is that kicks off the oregen process.

But, what I'm most curious about is whether you experts have the same issue.

In any case, I remain available for whatever testing you'd like.

Could it be that ReplacedBlocks is the problem? After removing all the ReplacedBlocks, the problem disappeared. Edit: Saw another area with less ores 😦

For TC 2.4.5, here's my download: https://dl.dropbox.com/u/23288978/terraincontrol/doskei.zip

@rutgerkok Well in the second test I didn't find ANYWHERE within the boundaries of the WorldBorder pregenerated area that were missing ore - what I saw was 100% correctly generated. I'm thinking that...

a) replacedblocks contributed to the results significantly, and that
b) there obviously is still a bug (even with replacedblocks it SHOULD work), but it may be possible to mitigate the effects

I'm going to get back to building my world, but I will periodically pause development, generate a largish world with worldborder, and explore it in MCEdit. If I find a reproducible way to trigger the bug without using replacedblocks, I will post here and in the forums. Meanwhile if you have any suggestions for things you'd like me to try, I'm more than willing.

Thanks a bunch!

@rutgerkok - since you're not using replacedblocks, how are you doing your test? I definitely acknowledge that could be part of the problem (though after your edit, it seems less likely - still, worth checking). I am only using replacedblocks because I don't know of another good way to test this in-game.

Now that I write this, though, I CAN think of another way. Here's my next test:

• set BiomeHeight in all biomes down so low that the "surface" will be around block 20 or so
• change all the ORE(... resources to spawn in AIR instead of STONE

This should allow me to see the ore that is generated clearly without using replacedblocks. The only catch is that I will have to assume this works the same way as it would if the ore was replacing stone.

Anyway, my testing methodology could definitely be part of the problem, and I'm open to alternative ideas.

I'm using MCEdit to view the world in a x-ray view. (Show... --> Hidden ores)

Roger, I shall try that myself.

I did go ahead and update to CB 1.4.7 R0.1, and TC 2.4.7 to match. I set biomeheight to -3.75 in all biomes (using worldheightbits 8). I replaced Stone with Air as the source block for all ores.

First run tests with the config are already interesting. I'm seeing almost no "thin" zones. Every once in a while one spawns, but if I try to fly through it I get stuck, and if I exit and reload invariably it turns out it wasn't thin after all.

There ARE some truly empty chunks, but they are rare.

I'm now running a second test, using a world I just created, and filling it out to 2096 with worldborder. I'll report back when I've got results.