[1.12] Storage Crate desync when Smeltery nearby
QBFreak opened this issue ยท 2 comments
Description of the issue:
Contents of Storage Crates (including Reinforced Storage Crates) appear to vanish when viewing crate contents. This occurs if the crate is in the same chunk as a valid Tinkers' Construct Smeltery, however not all Smelterys will produce the issue (I had the most success with 4x4x3). When the issue occurs, it happens every 15 seconds. Closing and reopening the crate reveals the contents. Attempting to sort the crate with InventoryTweaks will reveal the (unsorted) contents. Occurs server/client or single-player.
To reproduce the issue:
- Build a 4x4x3 Smeltery from TConstruct. It doesn't need anything fancy, just the walls, controller, and a seared tank.
- Place a Storage Crate down next to the Smeltery, it needs to be in the same chunk as the controller
- Place one or more items into the crate
- Open the crate and wait 16 seconds, the contents will appear to vanish before the time expires
- Close and reopen the crate, observe that the contents have returned
Versions & Modlist
- Forge: 1.12.2-14.23.5.2815
- ImmersiveEngineering-0.12-89
- TConstruct-1.12.2-2.12.0.135
- Mantle-1.12-1.3.3.55
Additional information
A quote from @KnightMiner of Tinkers'
According to @alexbegt who fixed this issue in Iron Chests, it has to do with the way vanilla handles large numbers of packets. Apparently if the number gets too high, it shoves all the data into the chunk packet which most blocks are not expecting. I don't think the size of the smeltery is your issue as much as the location. There might be something we can do to reduce the number of block updates from an active smeltery which should reduce the chances of this issue happening, but it really is a bug in the mods code apparently that just is rarely exposed.
Said comment can be found here: SlimeKnights/TinkersConstruct#3465
And the Iron Chests issue (now closed) here: progwml6/ironchest#158
The links probably aren't terribly useful, I'm guessing what KnightMiner had to say is the most illuminating.
If there's any additional information I can provide in regards to reproducing, or if you would like me to test any changes, I'd be more than happy to help.
When there is more then 64+ block changes in a chunk, Vanilla clumps it all into a packet with that packet being SPacketChunkData.
This packet uses the method getUpdateTag
from the TileEntity. When it's called on the modded TE, it doesn't include the inventory contents.
So in turn, when the packet get's processed, with the compound it got from getUpdateTag
, it passes it to handleUpdateTag
on the TileEntity and that in turn passes the compound to the 'readFromNBT' causing the desync of items.
I fixed this by actually sending the inventory in the updateTag, just in case the block changes get condensed into a packet like they do due to tinkers construct. Link to my changes: https://github.com/progwml6/ironchest/blob/1.12/src/main/java/cpw/mods/ironchest/common/tileentity/chest/TileEntityIronChest.java#L597-L615. getUpdateTag
is only used by that packet or if you define your own getUpdatePacket
it will be used by that.
IE already overrides getUpdateTag
, to have it write any of the custom data IE stores on those tiles, however it specifically excludes Inventory and other large tags from this packet.
I did that back in the day to make sure we didn't have giant packets floating around. Plus, vanilla wasn't writing their inventories into those tags, so I figured that was the right way to do it.