First off thanx for taking the time to keep a mod up to date that seems like a mountain of work. Secondly I didn't see anyone else directly ask this so do you have any intentions of making a 1.5.x version for all the sad people stuck on an outdated FTB server. Thanks a bunch for all your work.

Sure, you would just need to change the config so that replace block descriptor matches the IDs used by Underground Biomes. You might be able to use a regular expression for this. The changes will be pretty extensive though. One way to make this easier in the future would be to have BlockSet elements, like the BiomeSets.

But the replace descriptors are things like 'stone', 'sandstone' etc., will it work with IDs?

The IDs actually aren't a problem, Underground Biomes only uses 3 IDs for the different types of stone it generates.

What a great mod! I want to use it in on my server, but how do you config it on the server? It starts up as the "Vein" type of ores not "clouds" as i wanted. I tried to look in the config xml files, but i am not super awesome at xml, so i kinda drowned in text :|. Any help apriciated.

One way is to configure using the client, then copy the world over to the server.

has anyone got this working with simpleores? i'm drowning in text and my brain's absolutely fried

Would you please clarify what you mean by "working with"? COG should not prevent other mods from generating their ores. If you want to generate ores from SimpleOres using COG, it's best to start with an existing distribution, such as one in the MinecraftOres.xml file and modify it so that the block attribute (or OreBlock element) refers to the desired block (either by name or ID) from SimpleOres.

First: Thanks for reviving this mod . Really appreciate that.
Second: Is it possible, to make the mod compatible with the Forge Ore Dictionary? So it may can find custom-ores itself. Just a raw thought.

Thanks for the suggestion. Just to clarify, are you suggesting that ore dictionary keys can serve as block descriptors in the <Replace name=""> attribute, so that one could replace all ores of a specified type? That would be easy to implement and parallels the biome dictionary support that already exists. Maybe a <ReplaceType> element?

First: Thanks for reviving this mod . Really appreciate that.
Second: Is it possible, to make the mod compatible with the Forge Ore Dictionary? So it may can find custom-ores itself. Just a raw thought.

What do you mean, find custom ores?

Even if you could detect custom ores with 100% accuracy, there is no way to determine what the distribution of them should be.

If it generates with WorldGenMineable, you can make a vein- or cloud- based distribution for it.
If it does not, then there may be an intended reason for it generating differently

Regarding the problem of COG not generating ores in new chunks (only vanilla ore distribution exists), I have been able to replicate the problem by simply running in any direction and after 100+ blocks, all new chunks are vanilla ore and not COG.

Thanks for investing so much effort into diagnosing this issue. Have you played with the deferred population range setting? It can be adjusted during world creation. In the COG options GUI, enable debug mode and a slider appears. What happens if you slide this to zero? This seems to have eliminated the issue for me. When non-zero, COG defers population until some number of neighboring chunks have been generated. When moving fast, it seems to forget about some chunks. Would you please confirm? Thanks!

I had deferred population range set at 32. I have changed it to 0, and now most chunks do generate correctly, except sometimes the chunk I spawn in. Will continue to test.

Another anomaly I have come across, and this occurs even with vanilla COG configuration (i.e. not my XML configuration file), are water pipes that start 2 blocks above bedrock and rise all the way to 1 block above the surface. Some pictures in the spoiler. Don't know what is causing that. I have discovered that this doesn't happen in the desert, or rather sand and sandstone are not cleared to get the water to the surface, the water starts below the sandstone block. So it appears that if the block is stone or dirt, the water pipe clears the block and replaces it with water instead.

I don't believe that those water pipes have anything to do with COG, because I've noticed those popping up in my 1.5.2 worlds as well, and I'm not using COG there.
What other mods are you using during your testing?

I have this mod, Twilight Forest, an XRay mod, and Alternate Terrain Generation installed. I've been using the Xray mod to check the results of the ore generation, and unfortunately I only get vanilla ore clusters when I use the ATG worldtype. The two mods work fine separately, but will not mix.

So what is the answer on the "ore mis-generation"? Is a deferred range of 0 the answer? From what I understand, in the 147 version, deferred range had to be big enough to hold any motherlode generated (apparently the veins/hints going off the motherlode were ok, don't ask me to understand it)

I have this mod, Twilight Forest, an XRay mod, and Alternate Terrain Generation installed. I've been using the Xray mod to check the results of the ore generation, and unfortunately I only get vanilla ore clusters when I use the ATG worldtype. The two mods work fine separately, but will not mix.

that wraps the entire MinecraftOres.xml (and the others, as well). If ATG uses a different generator name, this condition will evaluate to FALSE. This is the check that prevents ores from being generated in the End and the Nether. Then again, since ATG is apparently not open-source, there's no way for me to know for sure. You can try removing that condition and see what happens.

So what is the answer on the "ore mis-generation"? Is a deferred range of 0 the answer? From what I understand, in the 147 version, deferred range had to be big enough to hold any motherlode generated (apparently the veins/hints going off the motherlode were ok, don't ask me to understand it)

Well, I'm not convinced that it's broken. It's just that it's easy to get into a situation on the edge of generation where the chunk has not yet been populated. It may be that in 1.6.2 the chunk generation is a bit more constrained, so if one runs in one direction for a while, chunks on the edge of the path are not generated, and thus the chunks are not populated. This is why the setting is a debugging option -- it makes it easier to debug but should not affect gameplay too much, but maybe it is more of an issue now. Need to run around some to get some fresh air before mining

My understanding of the purpose of deferred generation is for replacing blocks placed by another generator. If another mod decides to populate a chunk after that chunk has already been populated by e.g. a <Substitute>, then there's no chance to replace the blocks. COG always runs last during chunk population, but I guess some mods go back and modify chunks after all generators have been applied. COG itself is unaffected: it generates the distributions ahead of time and populates them incrementally as chunks are generated. This could be wrong; the code is fairly complex.

that wraps the entire MinecraftOres.xml (and the others, as well). If ATG uses a different generator name, this condition will evaluate to FALSE.

Yea, and that also excludes twilight forest.

I've got configs that include twilight forest, only run substitute at Y's below ... 27? 28? (Low enough to not bother the large hollow hills with their central depression), and adjust to a lower frequency for iron/coal because there's still some generated up above. Not used since 147, don't know (yet) how that would work with this revival.

You might have better luck tracking the chunk provider name, by the way.

Well, I'm not convinced that it's broken. It's just that it's easy to get into a situation on the edge of generation where the chunk has not yet been populated. It may be that in 1.6.2 the chunk generation is a bit more constrained, so if one runs in one direction for a while, chunks on the edge of the path are not generated, and thus the chunks are not populated. This is why the setting is a debugging option -- it makes it easier to debug but should not affect gameplay too much, but maybe it is more of an issue now. Need to run around some to get some fresh air before mining

That ... made no sense to me. In order for a chunk to be displayed, it has to be generated and populated, right? ...

Oh, hold on.

Single player, or server?

The last time I did a lot in single player, was back in 125. And I noticed something strange in extreme hills.

Chunks where the tops were not visible -- chunks where the only "visible" sections were air -- would not be generated.

I'm not joking. I used external mappers, and could see holes in the generated chunks. If I went into creative, and flew up, then they would generate.

I've never seen that behavior in SMP servers. I don't know how/if this has changed since the 132 code split.

My understanding of the purpose of deferred generation is for replacing blocks placed by another generator. If another mod decides to populate a chunk after that chunk has already been populated by e.g. a <Substitute>, then there's no chance to replace the blocks. COG always runs last during chunk population, but I guess some mods go back and modify chunks after all generators have been applied. COG itself is unaffected: it generates the distributions ahead of time and populates them incrementally as chunks are generated. This could be wrong; the code is fairly complex.

That ... made no sense to me. In order for a chunk to be displayed, it has to be generated and populated, right? ...

Yes, however, it is still possible, of course, for blocks to be placed after the chunk has been fully generated and displayed. The deferred population is an attempt to get the last word and catch all blocks placed in the chunk, even after the generation of multi-chunk structures. Anyway, it sounds like this issue occurs even when deferred population is effectively disabled, so this discussion is probably irrelevant to the bug.

Pretty sure this is the known issue of an incompatibility with the Crayfish Furniture mod. Perhaps it adds a bunch of blocks (well, 4) named "stone". Sounds crazy but that is my only explanation without looking into it, which I might do if I find time. For now, a work-around might be to replace "stone" with "1" everywhere in the xml files.

Yea, one approach is to remove half of your mods, test, if it breaks, remove the next half, if not, add back half of what you left out, etc. Basically a binary search. If you figure out the incompatibility, please let us know. Thanks!

Alright, I got my 162 setup working. And, in multiplayer, I cannot get any cog veins to show up at all.

I verified that I was looking at brand new chunks.
I arrived into the area by teleport, and moved in a straight line from the arrival point (high speed, ocean).
I tried with deferred range of 32, and with 0.
I used unmodified, stock configs, in the overworld, with layered veins.

A mapper confirmed vanilla ore generation no matter what I tried.
/cog<tab> resulted in /cogEnableDebugging (good!). But turning it on, and asking it for WIREFRAME, resulted in nothing being drawn. I know that's odd -- last night, in previously explored chunks, I got wireframes to display (but obviously, not generate).

Hmm ... let me try cogPopulate ...

Ok, this is interesting:
Around spawn, I see all the wireframes.
If I /tp to -1500, 100, -1500, then I don't see any wireframes.

If I use /cogPopulate, then the veins populate properly.

Traveling out from 0,0, north west, I see the following (wireframeoverlay):
1. Redstone wireframes stop around -120, -120
2. Iron drops massively going north past -250 or so.
3. Diamond is not seen northwest of about -115, -115 or so

Interestingly, if I log out, and then log back in, all the wireframes show up as expected.

So the bottom line:
1. Cogpopulate works.
2. I cannot get chunk generation to work, at all.
3. Wireframes will not display properly at times, but appear to be fixed by logging out and back in.

Again: Unmodified newly made configs in a world that never saw this before (world was brand-new for 1.5.1).