Compact Machines

Compact Machines

68M Downloads

Preview crash - too much NBT data.

Psithief opened this issue ยท 12 comments

commented

Compact Machines version: 1.12.2-3.0.12-b215
Forge version: 14.23.4.2760

I am not using Optifine: But I am using BetterFPS
Link to Crashlog: here
Screenshot (if possible): N/A

Description of the problem including expected versus actual behavior:
My storage system inside a compact machine has too much NBT data to be safely read for a preview, but not so much that it can't be visited in person.

Tried to read NBT tag that was too big; tried to allocate: 2097194bytes where max allowed: 2097152

Storage blocks from that machine are from the following mods (ordered most likely to least likely culprit):

  • ME Drive from Applied Energistics 2 (inc. drives from Extra Cells 2)
  • Junk Storage Unit from Ender Utilities
  • Compacting Drawer and Basic Drawer from Storage Drawers
  • Infinite Water Source from Overloaded
  • Material Stonework Factory from Industrial Foregoing

Steps to reproduce:

  1. Have too much NBT data in a block in a compact machine
  2. Right-click the block

Unrelated
The link in the default issue to https://vazkii.us/br101/ needs to be changed, as that page is now a 404.

commented

I can replicate this;

Using BetterFPS.
Storage Blocks in that machine;

  • About 500 AE2 Import Bus
  • A Single AE2 ME Chest
  • About 500 Roost from Roost

[07:55:22] [Netty Client IO #3/ERROR] [FML]: There was a critical exception handling a packet on channel compactmachines3 io.netty.handler.codec.DecoderException: java.lang.RuntimeException: Tried to read NBT tag that was too big; tried to allocate: 2097172bytes where max allowed: 2097152

commented

Hey, would you be able to retest this with the latest build 250? Download can be found here.
Thanks!

With the fix it should either render just the blocks without their tile data (pipes might not connect, screens might not light up, blocks might have to wrong rotation etc) or -if the package is still to big- it renders nothing.
But it should not crash anymore.

commented

I will look into it.

commented

I still crash on build 250, but the error log is slightly different so I'm posting both it and the previous build's.

This is a different compact machine that only contains:

  • 120 AE2 interfaces
  • 628 AE2 molecular assemblers
  • 87 AE2 dense smart cable
  • 51 AE2 smart cable
  • 30 AE2 P2P interfaces
  • 2 AE2 Dense Energy Cells
  • 1 AE2 wireless access point
  • 1 AE2 export bus
  • 1 chickenchunks spot loader
  • 1 capability adapter

Crashlog:
b249
b250

commented

Maybe this fix works for individual tile entities, but all of them added together still trips the limit?

commented

Hmm, I'm stripping all TileEntity data from the chunk if its too large.
My guess is that my limit calculation is off by a few bytes. If that's correct it should stop crashing once you add even more nbt data to the machine.

I'll try to improve my test case a bit to fit the size limitations more strictly - so far i've just added way too much data (it's a 4mb nbt tag...) - and adjust the threshold accordingly.

commented

Sorry for the huge delay. ๐Ÿ˜ข
Would you mind another retest with the latest build >= b256?

commented

Using build 263, these are my results.

My storage machine doesn't crash on preview anymore, but it seems another machine has started crashing.

It seems Advanced Rocketry multi-blocks will crash on preview now, where they didn't before.

I've tried a very old version of AR and the newest, but both have the same issue.

[Netty Local Client IO #0/ERROR] [FML]: There was a critical exception handling a packet on channel compactmachines3
java.lang.ClassCastException: net.minecraft.block.BlockAir cannot be cast to zmaster587.libVulpes.block.BlockTile
	at zmaster587.libVulpes.tile.multiblock.TileMultiPowerConsumer.readNetworkData(TileMultiPowerConsumer.java:315) ~[TileMultiPowerConsumer.class:unspecified]
	at zmaster587.libVulpes.tile.multiblock.TileMultiBlock.func_145839_a(TileMultiBlock.java:548) ~[TileMultiBlock.class:unspecified]
	at zmaster587.libVulpes.tile.multiblock.TileMultiblockMachine.func_145839_a(TileMultiblockMachine.java:540) ~[TileMultiblockMachine.class:unspecified]
	at zmaster587.libVulpes.tile.multiblock.TileMultiblockMachine.onDataPacket(TileMultiblockMachine.java:93) ~[TileMultiblockMachine.class:unspecified]
	at org.dave.compactmachines3.utility.ChunkUtils.loadEntities(ChunkUtils.java:248) ~[ChunkUtils.class:?]
	at org.dave.compactmachines3.utility.ChunkUtils.readChunkFromNBT(ChunkUtils.java:208) ~[ChunkUtils.class:?]
	at org.dave.compactmachines3.world.WorldCloneChunkProvider.loadChunkFromNBT(WorldCloneChunkProvider.java:42) ~[WorldCloneChunkProvider.class:?]
	at org.dave.compactmachines3.network.MessageMachineChunk.onMessage(MessageMachineChunk.java:54) ~[MessageMachineChunk.class:?]
	at org.dave.compactmachines3.network.MessageMachineChunk.onMessage(MessageMachineChunk.java:17) ~[MessageMachineChunk.class:?]
	at net.minecraftforge.fml.common.network.simpleimpl.SimpleChannelHandlerWrapper.channelRead0(SimpleChannelHandlerWrapper.java:56) ~[SimpleChannelHandlerWrapper.class:?]
	at net.minecraftforge.fml.common.network.simpleimpl.SimpleChannelHandlerWrapper.channelRead0(SimpleChannelHandlerWrapper.java:36) ~[SimpleChannelHandlerWrapper.class:?]
	at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) ~[netty-all-4.1.9.Final.jar:4.1.9.Final]

I don't know if this is from the change in 70da35b or perhaps 15b1797.

It is clear that zmaster587 is making some assumptions with multi-blocks that other mod-makers aren't making, but what those are I cannot say.

commented

After some disassembly and re-assembly, and moving tile entities further apart from one another, it stopped crashing until I exited the game (to the main menu) and entered again.

commented

Did the last change help?

commented

I didn't get a notification until you replied, so I haven't tested yet.

commented

No problems with b267. Thanks.