RFTools Modular Storage in Handy Bag
worblood opened this issue · 5 comments
Hi.
I was moving my storage system. I tought filling up my handy bag with modular storage full of items. After storing 6-7 modular storages I get kicked out, and only way to be allowed back in to the server was to delete my user data from the server.
Error message was: Tried to read NBT database but that was too big: tried to allocate 2097154bytes but only 2097152bytes where allowed.
worblood
This is a generic problem with at least items with NBT data - if the data grows too large, you get exactly that error because of some safeguards in the vanilla/Forge NBT code. I'll try to see if I can add safety checks to my inventories to check when the data grows too large, but I'm not yet sure if that is feasible and how bad of a performance hit it would cause. In general it is usually a bad idea to nest storage items, exactly because of this issue/limitation.
And then the other question. I assume you lost a LOT of your stuff when your player data was deleted? If you want them back, does the server have backups, and how often? Could they restore a previous version of your player file, or do they have a backup of that broken version? I could try to manually fix it by moving some ItemStack tags around so that there isn't too much nested inside the bag.
No problem, i ran another quarry and are back in business.
But if you still want the savegame for debug I can upload it later when I get home.
Many thanks.
Well I assume it would have items from several mods, and I mostly have (some of) my own mods and JEI in my dev environment, so it wouldn't really help much. And I can easily copy memory cards in creative mode by middle clicking and then keep recursively nesting them to get huge nasty NBT data for testing purposes :P
Speaking of, I probably should disallow placing memory cards with items on them inside my item-based inventories to help prevent this issue. But there isn't really a good generic way to detect inventory items from other mods...
Yes... The first thing that usually happens is that the network code will kick the client when the slot containing the Handy Bag is attempted to sync to the client. But nest storage items deep enough and even the server would at some point fail to read or write the NBT data for the item...
So in general, nesting storage items is a really bad idea, especially if they can contain significant amounts of data. For reference, when the client gets kicked, the slot/item being synced has at that point surpassed 2 MB of NBT data on that single item (!!). Which would mean that (assuming you are just barely under that limit), every time you open any inventory GUI, or any time the bag changes in any way (for example putting items in or taking them out, or moving the bag into a different slot), that ~2 MB of data will have to be sent when syncing just that bag alone...
I'm still planning on trying to change how I store and handle the bag's data, so that the whole NBT structure doesn't get synced to the client. So it would solve the network disconnect issue with badly nested storage items in the bag. But the server-side "too complex NBT data" issue is still possible with large amounts of storage nesting, and there is nothing I can do about that, without completely separating the item storage from the bag item into a separate system. That is pretty unlikely to happen. I might look into limiting the amount of items that can be stored in the bag (based on the amount of stored NBT data), but unfortunately there isn't a nice and clean/fast way to know how much NBT data there is, without trying to serialize it and use the NBTSizeTracker, or implement a similar custom system.
