Closed TelepathicGrunt closed 2 years ago
I am leaving an update on my findings here and to clarify any confusion that came up when discussing this issue in the BetterX Discord.
Updated repo steps:
Of great interest (imo) in the log is this line:
Is there a reason BcLib is trying to construct dimensions with the builtin registry? The builtin registry only has entries registered at game startup. But worldgen json files in mods and datapacks are read by mc at world startup and put into the dynamic registry. The builtin registry will never have bumblezone's noise setting entry because mc puts that into the dynamic registry instead. I feel this may be a clue or a lead into this issue but I am at the limits of what I am able to troubleshoot.
Let me know if there's any addition troubleshooting steps that can be done or tests to do.
I am currently breakpointing in dev and it looks like with BcLib and Bumblezone on and with the affected world, the error is occuring on WorldOpenFlows$loadWorldStem line 115: RegistryAccess.Writable writable = RegistryAccess.builtinCopy();
.
If I make a mixin to loadLevel to call this.doLoadLevel(screen, levelID, false, false);
and bypass BcLib's wt_callFixerOnLoad mixin entirely, the world loads.
https://github.com/quiqueck/BCLib/blob/3fe928ed4f756b6046fac72d341527d0c512bc17/src/main/java/org/betterx/worlds/together/mixin/client/WorldOpenFlowsMixin.java#L35
So it seems the act of calling
WorldBootstrap.InGUI.setupLoadedWorld(levelID, this.levelSource);
WorldBootstrap.InGUI.applyWorldPatches(...)
WorldBootstrap.InGUI.finishedWorldLoad(levelID, this.levelSource);
is causing vanilla's RegistryAccess.builtinCopy() method to blow up.
After testing each method in my own mixin, it seems calling WorldBootstrap.InGUI.setupLoadedWorld(levelID, this.levelSource);
alone before this.doLoadLevel(...)
will break the RegistryAccess.builtinCopy() method. Something in setupLoadedWorld is not setting up the json noise settings properly or something. Hopefully this is good lead for you to apply a fix soon
Thanks for the report and the debugging you already did. I'll have a look
So maybe I should explain a few Bits :)
Firs of, disabling the doLoadLevel
-Code from BCLib will break existing worlds when the users have Datapacks or other End/Nether Mod's installed. You can also disable that part of the code when not using the BetterX World-Type as it will basically disable the Custom BiomeSources of our Mods.
For new Worlds you can disable them in the World Generator Settings. That way the world will not break, but it will miss some features some BCLib based Mods (BetterEnd/BetterNether and Enderscape) use. For an existing World, users can change data/worlds_together.nbt
to have the same effect. As I said, that would be (related to this issue) the same effect as bypassing doLoadLevel
.
New, the issue is part of the vanilla World-Preset Code. Whenever the game initialises the WorldPresets (i.e when opening the CreatWorld Screen or when loading an existing world) all Dimensions need to get initialised. Normally the Sequence is Load Datapack Registry -> Initialize WorldPreset. However, as you found, there seems to be an order dependant issue. Something is forcing the World-Preset generation too early, which means that it will fall back to the Built-In Registry (as it does and is supposed to di when you open the CreateWorld-Screen for a fresh world).
My guess is, that the initialisation of the Datapack-Registry starts. But before your assets are loaded, the game forces us to initialise the WorldPreset System somehow. Which leads us to initialise your Dimension, which in turn wants to read the noise settings from the Registry (which is not yet initialised properly and does not yet have loaded that part of the datapack). That however will generate an unbound stub in that registry for the noise settings.
When the game is then actually loading the dimension, it will not try to reload the data for your noise (as the registry already contains an unbound registry entry, which will result in this error Message: Trying to access unbound value 'ResourceKey[minecraft:worldgen/noise_settings / the_bumblezone:bz_noise_settings]'
So, the main issue is finding out, why the world preset is initialised before the datapack is completely loaded. Since this is not reproducible for all worlds, it maybe a three-way compatibility issue.
So, no Solution yet, but hopefully a bit of an explainer what is going on here. I remember that there was a similar issue with Promenade (#16). Maybe this is a similar issue, but with the noise_setttings registry (My code does not check if that get's changed while initialising the Generators)
Ok, the latest commit appears to solve the crash. However, it needs some testing to ensure that it will not break any other combinations.
Here is a compiled version with the patch included. Would be great if you (affected users) could also do some testing with it: bclib-2.1.1-Bumblezone-Patch.jar.zip
But as I said, please take a close look at other Dimension-Changing Mods as well as the generation of new terrain in your dimensions.
Hello! I'm the one that sent the world to grunt here, and it happened with every world I created. The generation seemed fine, outside of one weird hiccup with better end, but I'm sure there's always a chance of it happening. within it's own generation. And I can load my worlds without an issue with that patch. If you're curious, this is the one hiccup found
Thanks a lot for posting this. :)
Do you have any other End-Mods/Datapacks installed (for example BYG or Nullscape)? The corruption I was talking about should only happen if you do...
we do, actually. I do believe I recorded a video of my creative flight through the nether, and end. As I'm never really sure on what is corruption, outside of missing blocks, textures, or just chunk loading errors. My game tech savy side lies in ark, and I'm trying to learn more about the technical side of MC now that I have little left to learn on the other one. https://youtu.be/JcWPwh5akQk https://youtu.be/UuM30sB5GVU
Oh, sorry. I didn't think about explaining the kind of corruption in my reply :(
The corruption I was talking about is related to terrain generation. When the Chunk Generators / Biome Sources are change in an existing world. The Biome Distribution and Land-Creation code gets changed. So whenever the game generates new chunks those will have a different Biome than before and/or different terrain. This in our will result in noticeable chunk borders (straight walls exactly at the chunk border).
Sometimes you can test this with the /locate biome
command. Just locate any nether biome and teleport there. If the Biome in the F3 Screen is different from the one you were locating, then there is corruption going on in the background.
I hope this helps a bit. And thanks again for getting back. Very much appreciated :)
I tested one of the affected worlds with the new bclib jar above. After teleported around while using locate command minimap, there seems to be no corruption in any dimensions and all biomes matches up to their terrain. Tested overworld, nether, end, eldenring, and bumblezone. Better End and Better Nether was also on.
Thanks a lot for the feedback. The patch is now released with bclib 2.1.1. Please re-open the issue if there are any related problems.
What happened?
I am the dev for Bumblezone and I gotten this issue report. https://github.com/TelepathicGrunt/Bumblezone/issues/136
The issue is for a few select people on 1.19.2 (though not everyone), they are unable to re-enter worlds made with the Better Minecraft modpack on Fabric only. The crashlog stated this error at the top which lead to me getting the report.
Error: java.lang.IllegalStateException: Trying to access unbound value 'ResourceKey[minecraft:worldgen/noise_settings / the_bumblezone:bz_noise_settings]' from registry Registry[ResourceKey[minecraft:root / minecraft:worldgen/noise_settings] (Stable)]
Now here's the steps I did to isolate the issue to BCLib:
First, the error makes zero logical sense because it is saying it is unable to the_bumblezone:bz_noise_settings entry in the noise setting registry except the json file exists and is parsed just fine for majority of people with the modpack and is working just fine for everyone outside the modpack and other modloaders. https://github.com/TelepathicGrunt/Bumblezone/blob/1.19.2-Fabric/src/main/resources/data/the_bumblezone/worldgen/noise_settings/bz_noise_settings.json
So this makes me suspect a mod is at fault here. Either parsing the dimension json too early or breaking the parsing of worldgen json. Looking closer at the issue report, there was a linked latest.log file that showed far more info than the crashlog. In the latest.log, it stated the parse issue is happening in BCLib when it is trying to construct the chunk generators. Now I suspect it is BCLib that is the issue here.
at org.betterx.worlds.together.worldPreset.TogetherWorldPreset.loadWorldDimensions(TogetherWorldPreset.java:122) ~[bclib-2.1.0.jar:?]
https://mclo.gs/rhBWq9HNext step is I had an affected user send me their world that they are unable to join with 1.19.2 Better Minecraft modpack. I am able to reproduce the error when attempting to join that world with the modpack on. So to verify that BCLib is the issue, I disabled BCLib and the mods that relied on it. And I was able to enter the world with Bumblezone on. https://drive.google.com/file/d/19LenNH_AXZryoiV5NrD6YCQZyeZUpabt/view?usp=sharing
This shows that Bumblezone's json and setup is perfectly fine. Minecraft can parse it just fine and will always parse it correctly. But BCLib is making the chunk generator for Bumblezone too early(?) before the noise setting file is parsed and registered by Minecraft. I do not know the specific cause of this but hopefully this will help.
Also, if possible, please throw a try/catch in
org.betterx.worlds.together.worldPreset.TogetherWorldPreset.loadWorldDimensions
and add info to the top of the stacktrace that the error raised occurred in BCLib while creating chunk generators. That way for future chunk generator crashes when BCLib is constructing them, the crashlog will actually state the info so people can report the issue easier or for the other modder to know that their dimension is being constructed in a non-typical way.Thank you.
BCLib
2.1.0
Fabric API
0.60.0+1.19.2
Fabric Loader
0.14.9
Minecraft
1.19.2
Relevant log output
Other Mods