SavedMachineData missing dim workaround is incomplete (Chunkloading Crashes / Dimension not found)
sfPlayer1 opened this issue ยท 10 comments
We're currently running into a 1.16 era problem where dimensions don't load, reason yet to be determined and most likely unrelated to CM. The workaround in CompactMachines 4.0.0-alpha.6 at
doesn't appear to deal with initializing
SERVER_DATA properly, which will lead to the following NPE a bit later:
net.minecraft.crash.ReportedException: Exception ticking world
at net.minecraft.server.MinecraftServer.updateTimeLightAndEntities(MinecraftServer.java:854) ~[?:?]
at net.minecraft.server.dedicated.DedicatedServer.updateTimeLightAndEntities(DedicatedServer.java:291) ~[?:?]
at net.minecraft.server.MinecraftServer.tick(MinecraftServer.java:786) ~[?:?]
at net.minecraft.server.MinecraftServer.func_240802_v_(MinecraftServer.java:641) ~[?:?]
at net.minecraft.server.MinecraftServer.lambda$startServer$0(MinecraftServer.java:232) ~[?:?]
at java.lang.Thread.run(Thread.java:832) [?:?]
Caused by: java.lang.NullPointerException
at com.robotgryphon.compactmachines.data.CompactMachineServerData.getInstance(CompactMachineServerData.java:42) ~[compactmachines:4.0.0-alpha.6]
at com.robotgryphon.compactmachines.block.tiles.CompactMachineTile.getMachineData(CompactMachineTile.java:261) ~[compactmachines:4.0.0-alpha.6]
at com.robotgryphon.compactmachines.block.tiles.CompactMachineTile.doChunkload(CompactMachineTile.java:280) ~[compactmachines:4.0.0-alpha.6]
at com.robotgryphon.compactmachines.block.tiles.CompactMachineTile.validate(CompactMachineTile.java:61) ~[compactmachines:4.0.0-alpha.6]
at net.minecraft.world.chunk.Chunk.addTileEntity(Chunk.java:409) ~[?:?]
at net.minecraft.world.chunk.Chunk.addTileEntity(Chunk.java:399) ~[?:?]
at net.minecraft.world.chunk.storage.ChunkSerializer.readEntities(ChunkSerializer.java:402) ~[?:?]
at net.minecraft.world.chunk.storage.ChunkSerializer.lambda$read$2(ChunkSerializer.java:133) ~[?:?]
at net.minecraft.world.chunk.Chunk.postLoad(Chunk.java:457) ~[?:?]
at net.minecraft.world.server.ChunkManager.lambda$null$25(ChunkManager.java:582) ~[?:?]
at com.mojang.datafixers.util.Either.lambda$mapLeft$0(Either.java:162) ~[?:?]
at com.mojang.datafixers.util.Either$Left.map(Either.java:38) ~[?:?]
at com.mojang.datafixers.util.Either.mapLeft(Either.java:162) ~[?:?]
at net.minecraft.world.server.ChunkManager.lambda$func_219200_b$26(ChunkManager.java:569) ~[?:?]
at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:642) ~[?:?]
at java.util.concurrent.CompletableFuture$C
For better testing, could you provide the version of Forge, and, if using a modpack, any other mods that you're using? The dimension code has been modified in newer Forge versions, so I might be able to recreate if I can match the mod environment.
This is on Forgecraft 1 with currently Forge 35.1.28, there are tons of mods and the world itself needs to be a certain way for it to actually stop loading dims.
The root cause for dims misbehaving outside your workaround is very intractable. So far I've only been able to superficially narrow it down once by bisecting the world save - clearing the tickets section in world/data/fluxnetworksdata.dat made your dim load normally again. So somehow fluxnetworks trying to load certain chunks breaks everything? Currently we have another instance of this problem, i.e. crashing as above in the workaround path and dims not having loaded normally to start with. It isn't fluxnetworkdata.dat's tickets this time, I haven't been able to investigate yet though (I want to automate bisecting first..).
This time it looks as if your dim is missing from the minecraft:dimension_type dynamic registry entirely?
async sampler registry list dimension_type
mining_dimension:mining: 5
minecraft:overworld: 0
minecraft:overworld_caves: 1
rats:ratlantis: 6
appliedenergistics2:spatial_storage: 4
minecraft:the_end: 3
minecraft:the_nether: 2
This is a nasty thing to investigate, the vanilla code is such a mess.
I can try working at this one, but I'll note that it looks like Forge 35.1.32 and 35.1.35 both add some logic around custom dimensions. Flux networks would be good to add to my dev environment for the energy testing, so I'll see if I can't recreate with that and some other chunk loading mods.
Thanks, I just upgraded to Forge 35.1.36 - doesn't seem to act differently. The last start crashed the same way through a different invocation, likely not meaningfully though (dim wasn't created through the normal path, probably already using the fallback before the below invocation).
java.util.concurrent.CompletionException: java.lang.NullPointerException
at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314) ~[?:?] {}
at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319) ~[?:?] {}
at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:645) ~[?:?] {}
at java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478) ~[?:?] {}
at net.minecraft.world.chunk.ChunkTaskPriorityQueueSorter.func_219083_b(SourceFile:58) ~[?:?] {re:classloading}
at net.minecraft.util.concurrent.ThreadTaskExecutor.run(SourceFile:144) ~[?:?] {re:classloading,pl:accesstransformer:B}
at net.minecraft.world.server.ServerChunkProvider$ChunkExecutor.run(ServerChunkProvider.java:506) ~[?:?] {re:classloading}
at net.minecraft.util.concurrent.ThreadTaskExecutor.driveOne(SourceFile:118) ~[?:?] {re:classloading,pl:accesstransformer:B}
at net.minecraft.world.server.ServerChunkProvider$ChunkExecutor.driveOne(ServerChunkProvider.java:514) ~[?:?] {re:classloading}
at net.minecraft.util.concurrent.ThreadTaskExecutor.driveUntil(SourceFile:127) ~[?:?] {re:classloading,pl:accesstransformer:B}
at net.minecraft.world.server.ServerChunkProvider.getChunk(ServerChunkProvider.java:130) ~[?:?] {re:mixin,pl:accesstransformer:B,pl:runtimedistcleaner:A,re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A}
at net.minecraft.world.World.getChunk(World.java:167) ~[?:?] {re:mixin,pl:accesstransformer:B,pl:runtimedistcleaner:A,re:classloading,pl:accesstransformer:B,xf:fml:observerlib:coremodmethod,xf:fml:astralsorcery:sun_brightness_server,pl:runtimedistcleaner:A}
at net.minecraft.world.IWorldReader.getChunk(IWorldReader.java:112) ~[?:?] {re:mixin,pl:runtimedistcleaner:A,re:classloading,pl:runtimedistcleaner:A}
at net.minecraft.world.World.getChunk(World.java:163) ~[?:?] {re:mixin,pl:accesstransformer:B,pl:runtimedistcleaner:A,re:classloading,pl:accesstransformer:B,xf:fml:observerlib:coremodmethod,xf:fml:astralsorcery:sun_brightness_server,pl:runtimedistcleaner:A}
at com.github.atomicblom.weirdinggadget.chunkloading.WeirdingGadgetChunkManager.forceChunk(WeirdingGadgetChunkManager.java:111) ~[weirdinggadget:2.2.7] {re:classloading}
at com.github.atomicblom.weirdinggadget.TicketUtils.activateTicket(TicketUtils.java:57) ~[weirdinggadget:2.2.7] {re:classloading}
at com.github.atomicblom.weirdinggadget.ChunkManagerCallback.ticketsLoaded(ChunkManagerCallback.java:24) ~[weirdinggadget:2.2.7] {re:classloading}
at com.github.atomicblom.weirdinggadget.WeirdingGadgetMod.lambda$worldLoaded$0(WeirdingGadgetMod.java:95) ~[weirdinggadget:2.2.7] {re:classloading}
at net.minecraftforge.common.util.LazyOptional.ifPresent(LazyOptional.java:161) ~[forge:?] {re:classloading}
at com.github.atomicblom.weirdinggadget.WeirdingGadgetMod.worldLoaded(WeirdingGadgetMod.java:79) ~[weirdinggadget:2.2.7] {re:classloading}
at net.minecraftforge.eventbus.EventBus.doCastFilter(EventBus.java:247) ~[eventbus-3.0.5-service.jar:?] {}
at net.minecraftforge.eventbus.EventBus.lambda$addListener$11(EventBus.java:239) ~[eventbus-3.0.5-service.jar:?] {}
at net.minecraftforge.eventbus.EventBus.post(EventBus.java:297) ~[eventbus-3.0.5-service.jar:?] {}
at net.minecraft.server.MinecraftServer.func_240787_a_(MinecraftServer.java:379) ~[?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A,re:mixin,pl:accesstransformer:B,pl:runtimedistcleaner:A}
at net.minecraft.server.MinecraftServer.func_240800_l__(MinecraftServer.java:308) ~[?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A,re:mixin,pl:accesstransformer:B,pl:runtimedistcleaner:A}
at net.minecraft.server.dedicated.DedicatedServer.init(DedicatedServer.java:168) ~[?:?] {re:classloading,pl:accesstransformer:B}
at net.minecraft.server.MinecraftServer.func_240802_v_(MinecraftServer.java:620) ~[?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A,re:mixin,pl:accesstransformer:B,pl:runtimedistcleaner:A}
at net.minecraft.server.MinecraftServer.lambda$startServer$0(MinecraftServer.java:232) ~[?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A,re:mixin,pl:accesstransformer:B,pl:runtimedistcleaner:A}
at java.lang.Thread.run(Thread.java:832) [?:?] {}
Caused by: java.lang.NullPointerException
at com.robotgryphon.compactmachines.data.CompactMachineServerData.getInstance(CompactMachineServerData.java:42) ~[compactmachines:4.0.0-alpha.6] {re:classloading}
at com.robotgryphon.compactmachines.block.tiles.CompactMachineTile.getMachineData(CompactMachineTile.java:261) ~[compactmachines:4.0.0-alpha.6] {re:classloading}
at com.robotgryphon.compactmachines.block.tiles.CompactMachineTile.doChunkload(CompactMachineTile.java:280) ~[compactmachines:4.0.0-alpha.6] {re:classloading}
at com.robotgryphon.compactmachines.block.tiles.CompactMachineTile.validate(CompactMachineTile.java:61) ~[compactmachines:4.0.0-alpha.6] {re:classloading}
at net.minecraft.world.chunk.Chunk.addTileEntity(Chunk.java:409) ~[?:?] {re:classloading,xf:fml:xaeroworldmap:xaero_wm_chunkclass,pl:runtimedistcleaner:A}
at net.minecraft.world.chunk.Chunk.addTileEntity(Chunk.java:399) ~[?:?] {re:classloading,xf:fml:xaeroworldmap:xaero_wm_chunkclass,pl:runtimedistcleaner:A}
at net.minecraft.world.chunk.storage.ChunkSerializer.readEntities(ChunkSerializer.java:402) ~[?:?] {re:classloading}
at net.minecraft.world.chunk.storage.ChunkSerializer.lambda$read$2(ChunkSerializer.java:133) ~[?:?] {re:classloading}
at net.minecraft.world.chunk.Chunk.postLoad(Chunk.java:457) ~[?:?] {re:classloading,xf:fml:xaeroworldmap:xaero_wm_chunkclass,pl:runtimedistcleaner:A}
at net.minecraft.world.server.ChunkManager.lambda$null$25(ChunkManager.java:582) ~[?:?] {re:mixin,pl:accesstransformer:B,pl:runtimedistcleaner:A,re:classloading,pl:accesstransformer:B,pl:mixin:APP:ftbchunks.mixins.json:ChunkManagerMixin,pl:mixin:A,pl:runtimedistcleaner:A}
at com.mojang.datafixers.util.Either.lambda$mapLeft$0(Either.java:162) ~[?:?] {re:classloading}
at com.mojang.datafixers.util.Either$Left.map(Either.java:38) ~[?:?] {re:classloading}
at com.mojang.datafixers.util.Either.mapLeft(Either.java:162) ~[?:?] {re:classloading}
at net.minecraft.world.server.ChunkManager.lambda$func_219200_b$26(ChunkManager.java:569) ~[?:?] {re:mixin,pl:accesstransformer:B,pl:runtimedistcleaner:A,re:classloading,pl:accesstransformer:B,pl:mixin:APP:ftbchunks.mixins.json:ChunkManagerMixin,pl:mixin:A,pl:runtimedistcleaner:A}
at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:642) ~[?:?] {}
... 26 more
FYI dims are generally present, even ones that presumably don't use a workaround like yours:
async forge tps
Dim minecraft:overworld (minecraft:overworld): Mean tick time: 0.000 ms. Mean TPS: 20.000
Dim minecraft:the_nether (minecraft:the_nether): Mean tick time: 0.000 ms. Mean TPS: 20.000
Dim minecraft:the_end (minecraft:the_end): Mean tick time: 0.000 ms. Mean TPS: 20.000
Dim compactmachines:compact_world (null): Mean tick time: 0.000 ms. Mean TPS: 20.000
Dim rats:ratlantis (rats:ratlantis): Mean tick time: 0.000 ms. Mean TPS: 20.000
Dim mining_dimension:mining (mining_dimension:mining): Mean tick time: 0.000 ms. Mean TPS: 20.00
There was however an earlier instance where your dim was the only non-vanilla dim to load (via fallback) - when something else broke dim loading altogether. One of these cases was advanced rocketry with its datapack that (i think) broke deserializing level.dat's worldgen records, but this was all way too much lambda soup to see through and debug properly...
Posting a log as requested: https://gist.github.com/RaspberryCommie/595489fae2092e536ae43aeabb0bb2c1
CM was causing me to be unable to rejoin a save when in a pack with Applied Energistics and The Undergarden. But only if all three were present.
For all involved, I've released two versions that should hopefully address this. Alpha 7 was the first, and Alpha 8 adds some new tunnel stuff for creative players. Please let me know if there are continued dimension issues.
Thanks! The new version at least resolves the crash and loads the dim, whether it actually works ingame is likely but untested.
Awesome! I'll wait for @RaspberryCommie before I close this, but that's great news.
Everything's working the way it should as far as I can tell. I think you got it.