This is the Log:
Log: https://gist.github.com/Lanse505/a34e92e4205f69de343e

It only seems to happend when either both or any of the Reactorcraft/Electricraft addons for Rotarycraft is installed.

P.s This is Override Related.

Forge Log: http://paste.ee/p/mSwBn

Yeah, there's no way to know which metadatas are valid. Only way to fix it is for @ReikaKalseki to catch invalid calls.

Okey I'll open a ticket over at Reikas side with this then ^^. Thanks for the quick response Boni :)

For Reference;
http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1291655-reikas-mods-tech-worldgen-civilization-and-more?page=1185#c23995

I fixed the harvest level thing for v9, so overriding the blocks is neither necessary nor desirable. That said, please explain what is trying to be done.

Also, I have some 70+ places I would need to check the array size, few of which I actually remember, making that approach, unfeasible due to the fact it would take something like a year to find all of them. On top of that, it will mask actual issues I do not want hidden, including some mod that is screwing with the metadata of worldgenned blocks at gen time (and is the cause of two issues in CC, one in ElC, and four in ReC).

My general policy is that sanity checking is actively harmful in cases where the check can only fail if something has gone very very wrong. (Examples: Null world in world generator, or checking if block at pos is this in block methods, or vanilla items being deleted (and NPE on reference), all of which have generated crashes due to some other mod). It clutters up the code - often to an absurd degree - and leads to deeper issues going unfixed for longer (or even forever).

It actually only calls getHarvestLevel for meta 0-15. If I remember correctly the MC/Forge block implementation has an array of size 16 set. I assume you're changing the array size? I'd say it's reasonable to either leave it at size 16 (even though most blocks don't use all of them) or check beforehand there since it's more or less in the API contract.

For what that stuff actually does: It goes through all blocks and detects if they require a tool to harvest, and if so, it checks which levels are needed for all metas. If it finds something it prints it out into a block-harvest-dump. Then it reads the actual config (which can be built from the dump) and sets the harvestlevels according to the data (block:meta combinations). Last it checks if the changing of the harvestlevel was successful (this only creates a warning, not a crash of course).

In which case, as of v9, this crash is not going to happen, because as per #176, I rewrote that system and no longer override the getHarvestLevel() function.

But more generally, I have an enum of ores and everything passes back to that enum (except the harvest level, which now allows overriding on ores that permit it). That is where the OOB comes from.

It's basically the blocks fault because MC does not provide a way to obtain valid metadatas. 1.8 fixes that, at least. :)

getSubBlocks would probably work for you.

getSubBlocks is clientside only. ;)

Oh...