Hello.
I have developed a optimized saving method for inventories that can compress them in the best case ~10-15x and in the worst case does save exactly the same as it does right now.
For a little CPU overhead.
This method basically Maps Exact same ItemStacks together (including stacksize).
And creates a slot list per item.
If the slot list is only 1 entry it will save it like default otherwise it is saved as a byte array.
This would be backwards compatible and on top of that it would reduce NBT overhead for things like Shulkerboxes massively.
Bugs like "Banning players by having to much NBT" could be less likely to hit since the compression would require a lot more effort to achieve this limitation.
In the attachments you find example code that is running since roughly 5 months stable.
A doublechest full of dirt goes from 3KB NBTdata to roughly 200Bytes.
I hope this improves minecraft in some way.
This patch can be applied to technically any game version
Edit: These methods could be injected into the helper methods you already provide.
Comments 7
Technically this would not break every command that checks player inventories because the compressor I am suggesting would only compress NBT.
And player inventories are not "serialized" during a inventory check command.
Unless you want to look directly into shulkerboxes contents while they are in Item form.
would only compress NBT
Wouldn't it also change how the inventory/ender chest of players is saved then? in that case checking the NBT of the player inventory would change format then, or am I misunderstanding something here?
Currently we check slots' contents via
{Inventory:[{Slot:0b}]}and alike.
Yes it would if you check for a specific slot. But Item saving itself wouldn't change. Only the slots would be compressed to reduce memory usage.
And on top of that this would only apply if there is duplicates single items or items with different NBT wouldn't merge and still support the old format.
On the other hand this would help a lot with world sizes since chests are usually bulk storage based or have exact duplicates allowing to save a lot of space.
And since its backwards compatible and only affecting duplicates it would only affect certain cases.
I wonder if a optional setting would be interesting since its backwards and technically forwards compatible. On top of that entities could only save for the final storage like that and not for commands.
On top of that entities could only save for the final storage like that and not for commands.
There isn't a difference between these 2, NBT check in commands are literally "save entity, check save-data".
I recon this would break literally every command contraption that checks player inventories out there. Might be something to consider as well.