payload may not be larger than 32767 bytes
Xetaxheb opened this issue · 3 comments
Describe the bug
Issue described here as well: M4thG33k/TombManyGraves2#42
TL;DR an item with huge nbt data, 3 identical copies (from dying 3 times in succession) are stacked in my simple AE2 storage and cause a crash if I try to remove them.
In that mod you can get an item with a lot of nbt data, multiple times and identical enough to stack in an ae2 disk. If this is an AE2 bug, in theory something like a forestry backpack with a lot of breeded butterflies would work too. Some info here: https://github.com/CoFH/Feedback/issues/865
I don't know if this is a TombManyGraves bug or an AE2 bug.
To Reproduce
Get item with massive nbt data, try to take out of AE2 storage.
Expected behavior
Item moves properly
Additional context
[06:21:00] [Netty Local Client IO #1/ERROR] [FML]: NetworkDispatcher exception
java.lang.IllegalArgumentException: Payload may not be larger than 32767 bytes
at net.minecraft.network.play.client.CPacketCustomPayload.(CPacketCustomPayload.java:28) ~[lh.class:?]
at net.minecraftforge.fml.common.network.internal.FMLProxyPacket.toC17Packet(FMLProxyPacket.java:142) ~[FMLProxyPacket.class:?]
at net.minecraftforge.fml.common.network.handshake.NetworkDispatcher.write(NetworkDispatcher.java:533) ~[NetworkDispatcher.class:?]
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:738) ~[netty-all-4.1.9.Final.jar:4.1.9.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:801) ~[netty-all-4.1.9.Final.jar:4.1.9.Final]
at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:814) ~[netty-all-4.1.9.Final.jar:4.1.9.Final]
at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:794) ~[netty-all-4.1.9.Final.jar:4.1.9.Final]
at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:831) ~[netty-all-4.1.9.Final.jar:4.1.9.Final]
at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1032) ~[netty-all-4.1.9.Final.jar:4.1.9.Final]
at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:296) ~[netty-all-4.1.9.Final.jar:4.1.9.Final]
at net.minecraft.network.NetworkManager$4.run(NetworkManager.java:245) [gw$4.class:?]
at io.netty.channel.DefaultEventLoop.run(DefaultEventLoop.java:54) [netty-all-4.1.9.Final.jar:4.1.9.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858) [netty-all-4.1.9.Final.jar:4.1.9.Final]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_162]
Environment
Enigmatica 2 modpack, tomb many graves 1.12.4.2.0, TMG2 api 1.12.2-1.0.0
- Minecraft Version: 1.12.2
- AE2 Version: appliedenergistics2-rv6-stable-2
- Forge Version: 14.23.5.2768
Refined Storage has that working just fine though... and they don't even have a 63-item-types-limit on their disks.
I get this error, when I try and remove a simple Iron Chest Transporter from my AE system:
It doesn't contain a chest; it's just the Iron Chest Transporter itself.
That's basically how Forge/Minecraft works. Nothing we can really fix (or the effort not being worth it)
There are ways for the mod adding the items to reduce it. But in the worst case it makes it hard or even impossible to identify the same ItemStack on the server and client as both consist of different data. So while it might no longer cause log entries due to crashes, the end result might still be that you cannot take out the item.
Usually this shouldn't be the case as they are mostly comparable, but not many mods are actively using it. So there might be the possibility that some mod could always break it in the future.
Ideally forge would add something like a unique identifier for every itemstack, but that's simply not the case. Or at least something like a common bag interface, so it would be easy to avoid stuffing bags into bags and thus creating stacks with massive data.
