3.4.1.0 Biome Registry Crash
Alaberti opened this issue ยท 34 comments
*Mod Version: 3.4.1.0
*Forge Version: 2281
*Link to crash log (if applicable): https://pastebin.com/raw/8qGDK0WN
*Description: CTD during travel, using Open Terrain Generator (OTG) v17 with Biome Bundle v5 world pack.
OTG dynamically alters the biome registry when the world is up and running. What is happening is that Dynamic Surroundings discovered that the biome registry became inconsistent, attempted recovery, and yet still couldn't identify the biome it had a reference to. Best it could do is throw up it's hands and say WTF.
EDIT: I will add additional logging around the event to better identify the biome in question.
EDIT2: @Alaberti Can you post the client log? There should be more clues.
fml-client-latest.log: https://gist.github.com/Alaberti/75e9c5afe73c756d4901d89b7677199a
@PeeGee85Spil Question on OTG. IIRC the biome entries in the biome REGISTRY for normal vanilla biomes are replaced with object instances found in OTG. If that is indeed the case, are the instances in Biomes (eg. Biomes.PLAINS) also updated with these new references?
The reason I ask is that I am unable to explain the crash outlined in this issue. It looks like the normal recovery logic kicked in, but yet the biome that was returned via World.getBiome(pos) still could not be located in the biome registry. Digging into the code a bit getBiome() will return Biome.PLAINS if a biome could not be located (chunk not loaded, etc.) If Biome.PLAINS is holding onto an object reference that cannot be found in the REGISTRY it could lead to this issue.
Yes. Here is the pertinent entry from the log:
[11:26:31] [Client thread/WARN] [dsurround/]: Biome [Plains] not detected during initialization - forcing reload (class net.minecraft.world.biome.BiomePlains)
Reinforces my thought as to what is going on as mentioned to @PeeGee85SPil
I am putting in additional code to detect and handle the Biome.PLAINS condition. Will be in the next BETA.
Not entirely sure it's BoP. The registry reload logic was triggered twice. First time:
Biome [Savanna] not detected during initialization - forcing reload (class com.khorn.terraincontrol.forge.generator.BiomeGenCustom)
As you can see by the class name it was one of the OTG biome objects that triggered the reload. This was expected because of how the mod works.
The second one:
Biome [Plains] not detected during initialization - forcing reload (class net.minecraft.world.biome.BiomePlains)
The second one has a the regular Vanilla BiomePlains instance. The first trace tells me that OTG already kicked over and did it's thing with the registries. Of course, I could be entirely wrong and will leave it up to you since you had more dealings with BoP interaction.
In terms of your understanding the first is correct - World.getBiome() returns Biome.PLAINS and it cannot be found in the registry. That is my best assessment based on the call stack provided and assuming that OTG is functioning correctly where the registry is concerned. (I think it is based on the first trace.)
Is there a logging level that can be set to get fine grain trace of the OTG operation to see if somehow the Biome.PLAINS is not being replaced? From my experience the there is/was a bit of a snafu with 1.11.2 SRG naming where the SRG name was different in reality as compared to what was in the SRG file. This caused some problems in Dynamic Surroundings in the past. (Ignore - issue is for 1.10.2.)
(FYI - I have been running BoP and OTG off and on together and have not experienced any problems myself. I normally run with BoP - not necessarily a BoP world - in order to check my mod.)
Hey @OreCruncher, OTG replaces biomes in the registry but any biome returned via World.GetBiome() should be correctly registered. I see in the crash log that biomes o plenty is also installed, this may be causing problems (OTG biomes being replaced by BOP biomes or vice versa).
So if I understand correctly World.GetBiome() returns Biomes.Plains and that biome cannot be found in the registry, right? Or does World.GetBiome() return some other biome that can't be found in the registry, if so which one?
Also:
[11:22:57] [Netty Client IO #1/WARN] [advancedRocketry/]: Null biomes loaded for DIMID: 5
That is NOT supposed to happen :p
We are not using BoP on this pack. Here is the pack with modlist: https://www.technicpack.net/modpack/aeronautscreed.951222
It was the overworld using Biome Bundle V5. Occurred around a Savannah if I recall. We have a few other mods that add biomes: the aether, voidcraft, and the betweenlands. I have not deconflicted their IDs - I assumed (probably wrongly) they'd adjust. I will get that information to you after I get back from work this evening.
Hmm ok so I'm thinking, first of all world.getBiome() shouldn't be returning Biome.Plains, it should be able to find a biome that is actually registered. Did you get this error exploring an OTG dimension or some other mod's dimension? It would be very helpful to see which biome is actually being queried and cannot be found (so Plains is returned instead).
In OpenTerrainGenerator.ini you can set the log level to "Trace", this should add a ton of stuff to the logs, including information about biome registration and which biome got which id. These logs may not show up in the console btw, only when you open the logs with a text editor.
If we can find out which biome is being queried and if it's an OTG biome that would be a huge help.
And the fml-client-latest.log: https://gist.githubusercontent.com/Alaberti/12a48f4402824a165b642e47f8777484/raw/56b0ddb710af3133962fe0da18828293490f0daa/fml-client-latest.log
Both have the OTG.ini logging set to Trace. Hope they help.
@Alaberti I pushed a v3.4.2.0 version that should work around this issue. Give it a try and let me know if it works.
I got the same crash unfortunately. If you like, I can set up a carbon-copy of our server and give you the ability to freely play around with it; maybe being able to work in a live environment will help?
Actually posting the logs would help most. I have additional logging and what not that will give me an idea of where to go next.
Ok. I updated the JAR to fix the abstract method error. Apparently Java needs a method to be defined in the class implementing an interface and cannot rely on a base class that has an implementation. (For some reason the JAR runs fine in my sandbox but not in a standard release config.)
Ok. One more time: https://github.com/OreCruncher/DynamicSurroundings/releases/tag/v.3.4.3.0TEST
Added a fallback registry. If it cannot find it by identity it will look up via biome ID. Failing all that it will return a WTF biome in hopes things settle out. I would be interested in a client trace log whether it works or not.
This run DID NOT crash, so whatever you did has yielded a result.
Looked through the log and it looks good. Something for @PeeGee85Spil :
[18:31:09] [Netty Client IO #1/INFO] [Ad Inferos [proxy]/]: Nether Survival = false
[18:31:09] [Netty Client IO #1/INFO] [OTG/]: Creating world "Biome Bundle"
[18:31:09] [Netty Client IO #1/TRACE] [OTG/]: Unregistering biome minecraft:ocean
[18:31:09] [Netty Client IO #1/TRACE] [OTG/]: Unregistering biome minecraft:plains
[18:31:09] [Netty Client IO #1/TRACE] [OTG/]: Unregistering biome minecraft:desert
Looks like the registration for biomes occurs on a netty client thread. May want to post a scheduled task to the main Client thread. Maybe part of the issue Dynamic Surroundings is having is related to this.
Sorry for the long disappearances, I only have a few hours a day not earmarked for something or someone else.
No worries about the time - I understand how it goes. :)
This one is more interesting and unexpected:
[18:11:41] [Client thread/INFO] [dsurround/]: CLIENT: Executing script for mod [mcp]
[18:11:41] [Client thread/ERROR] [dsurround/]: Unable to process configuration script
[18:11:41] [Client thread/INFO] [STDERR/]: [org.blockartistry.lib.logging.ModLog:error:92]: java.lang.NullPointerException
[18:11:41] [Client thread/INFO] [STDERR/]: [org.blockartistry.lib.logging.ModLog:error:92]: at org.blockartistry.DynSurround.registry.BiomeMatcher$ConditionsImpl.<init>(BiomeMatcher.java:182)
What Dynamic Surroundings is doing is iterating over the Biome.REGISTRY map and looking at the registered ResourceLocation for a given biome. What this crash is telling me is that an entry in that map has a bad ResourceLocation return for getRegistryName(). Totally unexpected. I will have to do more digging.
Give this release a shot: https://github.com/OreCruncher/DynamicSurroundings/releases/tag/v3.4.3.0TEST
@PeeGee85Spil Do the replacement biome objects from OTG have the registry name set in the object?
Got this crash shortly after reaching the title screen: https://pastebin.com/XfL0qUZs. Was not able to get into game to test anything.
The official v18 is now available here: https://minecraft.curseforge.com/projects/open-terrain-generator/files/2419946. It contains a few more fixes than the one you have.
This may be fixed with v18. A dev version of v18 is available here: <outdated, see comment below>
Please give it a try and tell me if that fixes the problems.
*A few notes for this version:
Should fix a whole bunch of dimension related bugs, mostly when creating/deleting dimensions and relogging and/or restarting the server. May also solve some biome registration related bugs when used with other mods that add biomes. Portal mechanics have been overhauled, dimensions should work much better now and each world can have its own portal frame materials defined in the worldconfig.
If you test the release and use the Dimensions pre-set or create/delete your own dimensions using /otg dim -l, /otg dim -c and /otg dim -d you'll want to change the portal material for each dimension in the world config. Otherwise they will all default to quartz and you'll only be able to visit the first two dimensions via a quartz portal.
I will have test results for you this evening after work. Thank you for all the hard work you guys have been putting into getting this solved!
Pushed a v3.4.3.0 version with the fix. Feel free to continue using this thread for discussion.
@PG85 Haven't forgotten, expecting to have time to check this weekend.