I have a TileEntity with an inventory and the size of the inventory is really big. (think 200,000 slots).

 

When in an SMP world the client will disconnect when trying to access the inventory with the message "DecoderException: Packet was larger than I expected"

 

*I* am not doing anything with packets right now, but that doesn't mean the API isn't. What I can think of is the NBT data (specifically the tag list I am storing stuff in) is being sent as a packet, and maybe there is a maximum size? it is possible I have a bug, but if i make the same inventory have a "measly" 100 slots it works great.

 

So, anyway. Is there a maximum size to how much I can store in an NBTTagList? If so, does that translate to the tag compound? What I am thinking is that I can just break the list into many smaller ones, but I don't want to just move the problem up the chain (if that makes sense)

I will double check the ram, but I am pretty sure that isn't it. Everything works fine in a single player world. Multiplayer is where I get the error. The server is only showing 50% usage (of what I gave the game, not the total ram in the machine)

 

Yes, I do bind it all at once as normal slots. A description packet? I am not writing any custom packet stuff. Just implementing writeToNbt and readFromNbt

There -is- a packet-size limit for anything sent between client and server.  Not sure off the top of my head what it is, but it should be at least 2MB.

 

My guess is that MC is exceeding that limit when it sends the initial container contents from server-> client on GUI opening.

 

 

Initial inventory contents are synched to client by container.addCraftingToCrafters(ICrafting), which ends up calling icrafting.sendontainerAndContentsToPlayer(Container, List<ItemStack>).  This wraps up the entire inventory contents (including 'null'/empty slots) and sends them to the client.  It is likely here that you are encountering the packet-size limit.

 

Ok, that is what I thought. so breaking the large list into smaller ones isn't going to do much of a difference. I will need to find something else. Thanks!

A while back there was a user on /r/feedthebeast who made a thread warning others not to store too much stuff on a single Applied Energistics disk. Apparently the NBT data got so big that it corrupted his world or something like that.

 

200,000 slots might be a bit much for one NBT structure unless you 'partition' the chest into several smaller chunks and save each chunk in its own file but present all the chunks as a single inventory.

That is what I was planning on doing, but if they are all going to be sent in the same packet I will still have the problem

Is it possible to be a bit "smarter" with your tagging.  Like I cannot imagine that you actually have 200,000 fully unique slots -- what the heck are you trying to do anyway?

 

Basically you should consider if there is "compression" algorithm you can come up with.  For example, if there is any repetition or regularity in what is in the slots you may not need to send each slot individually.

 

Maybe explain exactly what you're trying to do and we can suggest more efficient ways of storing the data.

Well, I'm working on a multiblock storage system and you can make large inventories with it. I might be able to come up with a different algorithm, but I can also just change how the inventory is partitioned across the structure.

On 9/23/2014 at 8:21 AM, shadowmage4513 said:

There -is- a packet-size limit for anything sent between client and server.  Not sure off the top of my head what it is, but it should be at least 2MB.

 

My guess is that MC is exceeding that limit when it sends the initial container contents from server-> client on GUI opening.

 

 

Initial inventory contents are synched to client by container.addCraftingToCrafters(ICrafting), which ends up calling icrafting.sendontainerAndContentsToPlayer(Container, List<ItemStack>).  This wraps up the entire inventory contents (including 'null'/empty slots) and sends them to the client.  It is likely here that you are encountering the packet-size limit.

 

do you know how to increase this limit?