Yung's Better Caves / Dungeon Crawl Crash MC 1.16.1
DSMatticus opened this issue · 9 comments
We were having a weird, difficult to reproduce problem where every now and then the game would sorta "soft crash" while we were flying around in creative mode - you could still move around, but no new chunks would generate, no commands would work, no error messages in the logs, and the logs even stop printing, etc, etc. The game would freeze on exit and fail to save the world.
I finally managed to narrow it down to happening with just Better Caves and Dungeon Crawl installed, and I even found a specific location on a specific seed where it happens 100% of the time. Steps to reproduce:
MC 1.16.1, Forge 32.0.108, only mods installed are Better Caves 1.0 for 1.1.6.1 and Dungeon Crawl 2.1.0 for 1.16.1.
Make a new world using seed 81582219814001934.
Teleport to 2700 64 1300.
A couple chunks will generate and then nothing but void after that.
Neither mod causes this problem on its own. Bizarrely, flying to this location using creative mode also doesn't seem to cause any problems. We first found the bug flying around in creative mode, but it seems way less reproducible that way.
[01Oct2020 18:07:15.001] [Render thread/INFO] [net.minecraft.client.gui.NewChatGui/]: [CHAT] Teleported DSMatticus to 2700.5, 64.0, 1300.5
[01Oct2020 18:07:15.463] [Render thread/INFO] [net.minecraft.advancements.AdvancementList/]: Loaded 7 advancements
[01Oct2020 18:07:16.432] [Worker-Main-15/INFO] [Dungeon Crawl/]: Building Dungeon at (2449 / 48 / 1441), 5 layers, Theme: 0, 0
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Placing exit stairs in layer 0
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Finished basic generation of layer 0: Generated 3/3 nodes and 4/4 rooms.
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: There are 2 distant nodes
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Finished generation of layer 0
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Placing exit stairs in layer 1
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Finished basic generation of layer 1: Generated 4/4 nodes and 5/5 rooms.
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: There are 2 distant nodes
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Finished generation of layer 1
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Placing exit stairs in layer 2
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Finished basic generation of layer 2: Generated 1/5 nodes and 7/7 rooms.
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: There are 0 distant nodes
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Finished generation of layer 2
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Placing exit stairs in layer 3
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Finished basic generation of layer 3: Generated 6/6 nodes and 8/8 rooms.
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: There are 4 distant nodes
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Finished generation of layer 3
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Finished basic generation of layer 4: Generated 4/7 nodes and 4/10 rooms.
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: There are 3 distant nodes
[01Oct2020 18:07:16.433] [Worker-Main-15/DEBUG] [Dungeon Crawl/]: Finished generation of layer 4
[01Oct2020 18:07:16.434] [Worker-Main-15/INFO] [Dungeon Crawl/]: Created the dungeon layout for [157, 94] (2 ms) (142 pieces).
That's what the log looks like from the teleport onward. As you can see, it's not very useful. It's even less useful when you test Dungeon Crawl alone, it doesn't crash, and you see that it prints the exact same log. ¯_(ツ)_/¯
I'll be putting this issue up on the Dungeon Crawl github too, since I have no idea which mod is actually the problem here and both should probably at least be aware of it.
This was almost certainly a case of recursive generation on the part of Dungeon Crawl.
Better Caves will no longer support 1.16.1. If this issue persists with newer versions and you think it's a problem with Better Caves, please create a separate issue.
When you tested with only Dungeon Crawl, were you teleporting to the location, or flying there in creative mode?
I suspect this is a problem with Dungeon Crawl - I don't think there's ever been such an issue with Better Caves with any other mod. And I've actually experienced similar problems a few times when developing my other mod, Better Mineshafts, which is also a large structure mod. So I know from experience this problem can happen rarely with large structures incorrectly generating somewhere.
I teleported there.
It might also be worth mentioning that we were using Dungeon Crawl on its own without issue for way, way longer than it took us to find this bug once we started using both. I agree it's probably a structure generation issue that needs to be fixed on Dungeon Crawl's end (the fact that I can only consistently reproduce the problem by teleporting, even though flying to the exact same place is absolutely fine, makes me think it's the specific order the chunks generate in that sets up the crash, and that screams structure generation to me), but weirdly it really doesn't seem to be a problem Dungeon Crawl has on its own.
Yeah, that's exactly what I was thinking. I'm not sure what it could be either; perhaps they have pieces that check for surrounding terrain, and Better Caves produces underground terrain you don't normally see in vanilla (e.g. large open rooms). We'll need to wait and see what they have to say about it in xyroc/DungeonCrawl#42
Okay, I think I have a decent grasp of what might be going on:
The whole deadlock originates from a tripwire hook block (placed by dungeon crawl) checking its surrounding blocks to calculate a blockstate. See TripwireHookBlock#calculateState
for reference. This method calls World#getBlockState
for each adjacent block position to receive its nearby blockstates. According to the stacktrace, which i will paste below, one of those calls asked for a blockstate in a chunk that has not been generated yet, because the ServerChunkProvider
started a task to generate that chunk (ServerChunkProvider#getChunk
).
Looking around in the dungeon showed that there are in fact two tripwire hooks near the teleport destination that are right next to a chunk border. One at (2733 / 40 / 1280) and the other one at (2737 / 40 / 1280).
My theory is that the main thread was busy generating the chunk containing the tripwire hook(s), when suddenly TripwireHookBlock#calculateState
was invoked. Since one of the requested states in calculateState
was in a non-existing chunk, the blockstate request got parked until the missing chunk was generated. Normally, this would not cause a problem since the main thread would just generate the missing chunk and then continue with whatever was requesting data from that chunk, but this time the main tread was in the middle of generating another chunk: the one with the tripwire hook(s). So before generating the missing chunk, it needs to finish the current one first. The current chunk however requires the missing chunk to exist to finish its generation, resulting in a deadlock on the main thread.
Now, TripwireHookBlock#calculateState
was called during the execution of TripwireHookBlock#onReplaced
. This is probably where Better Caves comes into play, since Dungeon Crawl does never replace its own blocks. The cause of the onReplaced
call is World#setBlockState
. Could it be Better Caves doing some cave generation? As far as i know, carvers do their work before structure pieces get generated though.
The stacktrace of the main thread as mentioned above:
That's pretty strange. All of Better Caves' generation is done within the RAW_GENERATION
step of structure gen, and I assume your structures generate in a later phase.
Does Better Caves change the way spawner rooms (https://minecraft.gamepedia.com/Dungeon) generate to make them play nicer with the new caves? Does that happen late enough in worldgen to possibly cause an interaction between the two mods?
I ask because after checking out what's going in that area underground, I noticed that:
-
There are actually four tripwire hooks at (2733, 40, 1280), (2737, 40, 1280), (2733, 40, 1278), (2737, 40, 1278) - two parallel sets of tripwires in the same hallway. All four(!) hooks end up in different chunks.
-
Neither vanilla cave generation nor Yung's cave generation create caves that would intersect the blocks immediately around or between those tripwires.
-
Of the four chunks containing those tripwires, only teleporting to the chunk containing 2733 40 1280 deadlocks.
-
The chunk that deadlocks when teleported to intersects two spawner rooms when using Yung's cave generation, and is the only one of those four chunks to intersect any spawner rooms. There are no spawner rooms nearby in vanilla. To be clear, the spawner rooms are on the almost complete opposite corner of the chunk. They're not close. I don't think it's likely, but I'm putting it out there.
It doesn't influence the dungeons directly, but I believe dungeons may require air blocks in order to spawn, so it could indirectly cause an increase in dungeon spawn rate due to more air being exposed underground. In general, BC doesn't mess with any other structures directly.