I've noticed this in Highlands and Extreme Hills. I specifically disabled all vanilla ore generation so I could manage it with COFH, but emeralds are still spawning like crazy.

In rtg.cfg, if you have B:"Generate Emerald Ore" set to false and there's still emerald ore in your world, then it's some other mod generating it.

Is that Enhanced Biomes stone that I see? If so, it's EB generating the emerald ore. Furthermore, EB is probably generating all of the other vanilla ores on top of COFHCore, so you might have twice as much vanilla ore than what you want. This is an EB bug; That mod's ore gen can't be disable, unfortunately.

Just re-opening this so it can be seen as a known issue. There is actually something we could do to resolve this, but it would mean manually decorating all of EB's biomes - not something we'll probably get around to for quite some time.

I'm not using EnhancedBiomes, I'm using UBC and Biomes O Plenty.

Thanks for verifying that, I'll hunt through my 100 mods to figure out which one has gone emerald rogue.

You are setting the config field in RTG, right? Disabling standard oregen probably doesn't stop emerald generation, because emerald ore is not actually generated as an ore.

This is a UBC issue, so I'm closing it here.

Actually it doesn't seem to be an issue in UBC either. If "Generate Emerald Ore"=true, I see emeralds in Extreme Hills, If "Generate Emerald Ore"=false, I don't. The only issue I can find is that the generatesEmeralds flag is wrong for HLCliffs and HLSnowMountains, which I'm fixing.

RTG handles emerald gen as well - or at least, it's supposed to - but I'm wondering if it's not working anymore after recent changes to decoration etc.

I might re-open this, just until we can confirm that emerald gen is still working. (Warning: if anyone decides to look into this, it's a bit of a mine field (think legacy rDecorate()-type madness.)

I'll be doing some testing tonight and will update this issue with the results.

I am setting the config field in RTG. But even if I hadn't, why would there be that many emeralds? They're supposed to be rare.

Pink - I notice that the emerald de-gen goes to all the spots that would be made emerald and turns them back. This is going to fail with a non-vanilla emerald generation, or even if something affects the RNG, because the emeralds will be in different places.

Hmm, I haven't looked into this yet, but iirc the de-gen is checking the actual block to see if it's an emerald ore... that should be RNG-proof, right? If there's a better way to do it though, I'd be up for trying it as the current approach is quite expensive if emeralds are disabled.

[Sticky note for later] There's also EB ores and other non-vanilla emerald ores to consider.

The problem is that if a different block has been changed, either due to a different algorithm actually being used, or to a RNG glitch, RTG will never check to see if it's changed back.

@Zeno410 I still don't understand how RTG's current de-gen wouldn't work because... it loops through every single already-generated block in every single chunk, checking to see if it's an emerald ore, and replacing it with stone if it is. How would a different algorithm or an RNG glitch affect that process?

The only way I can see it not working is if some emeralds get generated after rRemoveEmeralds() is executed, but... it's the last thing we call in the decoration process, so... ¯_(ツ)_/¯

If I'm still misunderstanding, you might need to take a look at this one, or at least help me see what the problem is because I don't know any other way to remove emeralds, or stop them from generating in the first place. With other non-standard ore gen (dirt and gravel, for example), we can just remove those generators from the biome's decorator (we use that approach in a few biomes already), but.., emerald ore gen doesn't live in the biome decorator - it's just floating in the BiomeGenBase's decorate() method. There's isn't even a Forge event that we can hook into as it's not technically an 'ore' (which is ridiculous, but don't get me started on that one 😞 )

Having said all that, I just finished testing emerald gen/de-gen in snapshot 1, and everything seems to be working fine, so not sure this particular issue is RTG-related (although I'd still like to tweak our emerald de-gen if you're certain it's failing under certain circumstances).

@Yazzeh Have you been able to figure out why so many emeralds are generating? If you can narrow it down to a few suspect mods, I could help with the investigation.

OK, explanation: A mod places emerald. This could be anywhere, depending on the mod - even if they use the vanilla routine, if there's even one extra call to the RNG everything moves. RTG will then come along and remove emeralds from all the places vanilla would have put it - but only those places. The mod-placed emeralds are elsewhere, so they're not affected.

Maybe it's changed or I misunderstood it, but the removal system I saw reran the emerald generation and only changed the emeralds in those blocks. In any case, clearing the entire chunk won't do, because generation starting in the chunk can spill into adjacent chunks, and if those chunks have already been cleared then the emeralds will stay.

You could clear into adjacent chunks to a far enough distance if those chunks have already been made.

Edit: you can't clear all adjacent chunks because that will throw you into an infinite extension chunk generation loop. Maybe the delayed decoration system would protect you from that but I'd hate to rely on it like that.

@srs-bsns How did you remove everything except the ores? I'd like to investigate further as the test I did on snapshot 1 seemed to be working for me, but I was only checking one block, so... it probably is broken. :/

@whichonespink44, I just used Veinminer with most vanilla blocks added to the blocklist for pickaxe, and these config settings:

    I:limit.blocks=20000
    I:limit.blocksPerTick=100
    I:limit.radius=64

Sorry, but I still don't get it. The emerald removal system loops through every coord in every chunk, uses world.getBlock(), and replaces emerald with stone if it finds one. It doesn't matter where a mod places the emerald - if it's placed before the removal routine runs, it will get replaced. If it's placed after the routine runs, sure, I can see how it would miss it, but... if it gets placed before it runs, then I just don't see how an RNG glitch would affect that process. The removal routine doesn't even use the rand it gets passed.

The only way I can see this happening is if either:

1. Our method is broken, or
2. Some other mod isn't using the proper method to generate ores and is generating emerald after our method runs.

But I'm going to have to go with the former, because the test I just did with just RTG (latest) and all ore gen turned off produced this result:
[eroneous image]

Disregard this post, I'm dumb.

Confirmed RTG's emerald DE-gen isn't working, which might be contributing to this particular issue, but it certainly isn't generating extra emeralds... it's just not removing all of the ones that it generates itself.

So...

I'm going to leave this open, but I'm changing the milestone to 1.1 as it's not a priority at the moment, but I'd still like to sort it out if we can.