Similar to #461 (not sure if considered duplicate issue)
But different biome missing.
And no EB mode

Following the instructions there

Crash log

Key line:

Description: Ticking entity
java.lang.RuntimeException: No realistic version of biome 146

Biome Dump

Key line:
146,Storage Cell,-75.25,1.0464097,0.1,0.1,0.2,"COLD, PLAINS",appeng.spatial.BiomeGenStorage

Looks like it is Applied Energistics;
AppliedEnergistics2.cfg tells me:

...
spatialio {
    D:spatialPowerExponent=1.35
    D:spatialPowerMultiplier=1250.0
    I:storageBiomeID=146
    I:storageProviderID=-11
}
...

Seems particularly weird though, in that the Applied Energistics2 spatial storage should never occur in the overworld. (I think. Not sure never got in AE2)

Editting the AppliedEnergistics2.cfg to disable spatialio, stops the bug.
(But also disabled spatialio... Oneday I might want that)

Also see #455, specifically #455 (comment)
Biome IDs 128-167 should be avoided as much as possible when customising biome IDs if using the vanilla biome layouts.

I'm not sure that's the issue here though because it does look like a dupe of #461, and again, rockhounding is in the stack. It would be nice to know what GlobbyPotato's code does, but the source for his mod is nowhere to be found.

@oxinabox If you remove Rockhounding, does it still crash? Also, can you try re-assigning biome IDs such that IDs 128 to 167 are avoided (as well as 255, which should never be used).

Let us know how it goes.

@Haggle1996,

From RTG's MCF thread under Known Issues:

No realistic version of biome X - A lot of people have been experiencing crashes that contain this
message: "java.lang.RuntimeException: No realistic version of biome X", where X is a biome ID.
This crash is usually caused by either a biome ID conflict of some sort, or by a mod that adds a
biome which RTG doesn't support. Here are some things you can do to help prevent this crash
from happening:

* When configuring biome IDs, try to avoid using IDs 128 through 167, as these are reserved for
vanilla's 'mutated' biomes and can cause strange behaviour even when mutated biomes are disabled.
(You should also avoid ID 255 if possible.)

Haggle1996/RevolutionPack#212

Of note, Biome 146 is the default value provided by AE2 for it's spatial storage. As AE2 is one of the most common mods ever (and oldest), I have to assume if it were a problem, someone else would have reported the issue a very long time ago.

@Haggle1996, if ./config/AppliedEnergistics2/AppliedEnergistics2.cfg doesn't exist upon initialisation of AE2, then it will automatically select the next available ID without taking into consideration that it should avoid 128-167.

So, if you load AE2 by itself, it will chose ID 40; If you load it with BoP and you give BoP IDs 40-123, then AE2 will choose ID 124.

In your case, ID 146 was the next available ID when AE2 was initialised at the time it created the cfg file. This can only mean that you also had other biomes registered to (normally) available IDs in the range of 128-167 (eg. 128, 136-139, 141-145).

If you have already exhausted IDs 40-127 in your setup, then you should manually set I:storageBiomeID to an ID in the range of 168-254, or free up some IDs in the range of 40-127 so that AE2 will automatically choose an ID in that range. (You will have to delete AppliedEnergistics2.cfg to have it autochose a new ID, so manually setting it is probably the best solution.)

Note: Although using some of the available IDs in the range of 128-167 might not cause an issue, there is always a potential for one to arise, which is why they should be avoided. From my own experience through testing RTG, IDs 146 and 150 are the most prone to causing a crash.

@Zeno410, after having just looked into the pack, yes, it has ClimateControl-0.4.beta39.jar. I had assumed the vanilla biome layouts, which was the previous case of these crashes, but if CC is in use, you'd know better than anyone why this is happening.

Would making a realistic version of the Storage Cell biome help? I mean, obviously we wouldn't want to place the biome in the Overworld, but when the 'unused' biomes from vanilla were crashing (Extreme Hills Edge and Frozen Ocean), we created realistic versions of those in the code to prevent it from crashing, even though they're still never placed. Do we just need to do something similar here?

The issue is not finding space for IDs, it's that tens of thousands of players are using my pack, and I hesitate to make a breaking world change.

Well, in that case, I'm not sure there's an easy solution.

If left the way it is, anyone using your pack runs the risk of this crash if biome 146 is ever selected while the server is generating new chunks. Normally it would be a mutated biome (of ForestHills, I think), but since the storage cell is set to 146, RTG will throw this exception.

You could change the ID that the storage cell uses to prevent this crash from happening, but that would probably break any storage cell that anyone has made prior to the change, and might cause AE2 to throw an exception.

In the latter case, you could always create a test world with the storage cell biome set to ID 146. Create a spatial storage, then exit the game, change the ID, reload the world, and see what happens. Worst case: AE2 throws an exception trying to access the spatial storage; Best case: Game doesn't crash, but spatial storage is likely ruined.

Haggle, aren't you using CC? CC shouldn't be having the +128 problem

That would be good for an option, perhaps even defaulted to true. Pack makers need to know if something's wrong with their packs (you wouldn't want something going out where a critical biome never generates).

Maybe a numeric "patch biome" option, with the default = 1, so somebody could switch it if vanilla biomes are disabled. -1 would mean no patching.

When can I get the bits? :)

@Zeno410 So where exactly would the patching need to take place? I'm assuming it needs to happen before it even gets here, correct?

I'm doing some config stuff at the moment... if you can point me in the right direction, I can get this setup before we drop 0.6 tonight. (If it's not as simple as it sounds, no worries.)

Could it be possible to, instead of throwing an exception, just use the RTG version of the vanilla plains biome (ID=1) whenever an unknown biome is encountered? This way the server won't crash and ruin everyone's day, and RTG also won't try generate biomes that have no place in Dim 0. And in addition to this, have the server log the event as an error so server operators know that there is an issue.

This might solve more crashing issues like this than with just the AE2 storage biome.

No worries - I've already started putting together 0.6 anyway, so it'll have to wait for 0.6.1 (sorry @Haggle1996 !! )

It's okay. We'll kill you later. :D

Given the monumental task of integrating CC and RTG, mostly all I can do is sing your praises.

No, that's exactly where the patching goes. If it doesn't find an acceptable Realistic biome, it returns the patch biome, or throws an exception if the user has patching off. So it's just changing that and putting in a config for it.

Hmm, now that I think of it, we need another exception if the patch biome isn't acceptable either. Still pretty routine.

On third thought, there might be some other issues which would have to be resolved with similar patches. I don't have time to look, though, as I'm struggling with CC issues. But you could test it with TF biomes stuffed in all the +128 slots and the vanilla generator.

@Zeno410 I've done some work on this, and I think I've covered all the places where the patching needs to happen. Also added a config option as you suggested. The default 'patch biome' ID is 1 (vanilla Plains), but if the user sets it to -1, the game will crash as it did before, with the same messages that it threw before the patching was implemented.

You can take a look at how I implemented it on the biome-patching branch: https://github.com/Team-RTG/Realistic-Terrain-Generation/compare/dev...biome-patching?expand=1

I tested it by installing AbyssalCraft and RTG, which normally crashes due to "No realistic version of biome X", but with the patching enabled, it generates Plains instead and seems to work alright.

Let me know if you can see any problems with it. If everything looks good, I could create a JAR file with the changes and maybe @Haggle1996 and/or @srs-bsns could give it a test drive before merging it into dev ?

I just did a quick test with it and it seems to be working fine.
First I started with 0.6.0 to make sure it was crashing, (because, you know, scientific method!,) then I recreated the same world with https://github.com/Team-RTG/Realistic-Terrain-Generation/tree/biome-patching built from source and the world generated fine.

Only thing is though, did you add any logging to log the missing biome as an error for the sake of server operators/mod pack maintainers? Because I didn't see anything in the log file, other than the usual:

[10:43:12] [Client thread/TRACE] [RTG/RTG]: Sending event FMLPostInitializationEvent to mod RTG
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Darklands (100) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenDarklands
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Abyssal Wastelands (101) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenAbywasteland
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Dreadlands (102) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenDreadlands
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Purified Dreadlands (103) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenAbyDreadlands
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Dreadlands Forest (104) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenForestDreadlands
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Dreadlands Mountains (105) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenMountainDreadlands
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Darklands Forest (106) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenDarklandsForest
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Darklands Plains (107) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenDarklandsPlains
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Darklands Highland (108) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenDarklandsHills
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Darklands Mountains (109) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenDarklandsMountains
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Coralium Infested Swamp (110) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenCorSwamp
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Omothol (112) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenOmothol
[10:43:12] [Client thread/WARN] [FML/RTG]: WARNING! RTG could not find a realistic version of Dark Realm (113) from com.shinoow.abyssalcraft.common.world.biome.BiomeGenDarkRealm
[10:43:12] [Client thread/TRACE] [RTG/RTG]: Sent event FMLPostInitializationEvent to mod RTG

There should probably be a separate logging entry at the ERROR level so people will know that RTG tried to gen a biome that it can't and that something is broke and needs fixing. :)

Only problem with logging it at the point of patching is that the patching happens on a chunk-by-chunk basis, which results in a massive amount of log spam. The only thing for server operators & mod pack authors is the option to turn off biome patching in the configs.

Not sure what else we could do, but I'm open to suggestions before merging it into dev

Yikes. Well, I'm no fan of log spam. I can't think of a good alternative at the moment either.

I'd say just merge now as-is.. some form of logging can always be revisited in the future.

Cool cool - should be merged shortly.

It looks good to me. I would go ahead and put it into the dev branch.

My thought is that anybody who wants to see problems should turn off patching. It's a defective world if patched, we just want people to be able to play if it's a tolerable defect, which will include most cases of the mutated biome problem.

Ok, closing this as the biome patching will be available in the 0.6.1 release on Sunday.