Describe the bug
Since updating from mod version 1.14.4-1.7.1.36 to 1.14.4-1.7.1.38, the backpacks have been exhibiting unusual behaviour in creative mode. Most often this results in the backpack being cleared of all items entirely, but other times it results in changes to the contents of the backpack not being stored (and it reverting to a previous state).

I believe this may be related to the override of getShareTag(ItemStack stack) that was added to fix #22 - while in creative mode, I think inventory actions require the full NBT tag data in order to work correctly (the client sends the information to the server in a CCreativeInventoryActionPacket). I haven't dived deep enough into the code to be 100% certain, I'm just going off a quick glance.

To Reproduce
The easiest way that I have found to consistently reproduce some of the behaviour:

In creative mode, add items to a backpack, then quickly move the backpack to a different inventory slot (eg. from slot 1 to slot 2 in the hotbar).

Expected behavior
Backpacks should operate consistently as in survival mode.

Screenshots
N/A

Versions

• Mod version: 1.14.4-1.7.1.38
• Minecraft version: 1.14.4
• Forge version: 28.1.40
• UTeamCore version: 1.14.4-2.7.3.132

Log (if crash occures)
No crash nor any logged information.

Hey for some reason, i have the same glitch in my 1.18.2 server, any have a idea how to fix it??

also is happening with survival players.

Please open an other issue with the exact version you are using.
Include a screenshot, the config options and if you can a video of you producing the bug.
Thanks.

I can reproduce this by upgrading from .34 to .38 on a multiplayer server, 100% repro. Connect (player connects in survival mode, for reference, but I don't think it's important). Then you go into creative, open the backpack. All of its contents are gone. No need to change slots. Re-testing steps now to confirm.

I am on Forge 28.1.26
UteamCore is 1.14.4-2.7.3.132

It might be a little more complicated than the original bug report implies, especially since it doesn't sound like that's a 100% repro.

I just tried this to try and determine if it affects pre vs post update backpacks and it did not repro the bug (though this test alone is hardly comprehensive nor conclusive that this bug only affects pre-update backpacks):

1. Upgrade mod.
2. Login.
3. Put pre-upgrade backpacks in chest for safe keeping.
4. Pop into creative mode.
5. Grab a small, medium, and large backpack from creative into hotbar.
6. Grab three stone blocks from creative into hotbar.
7. Hop into survival mode.
8. Load each backpack with a mod (by clicking the stone and right clicking one into the backpack).
9. Pop back into creative mode.
10. Access, close, access backpack again (no bug triggered).
11. Put backpacks in different hotbar slots and repeat step 10 (no bug triggered).

My next test will do the same, but instead craft the backpacks in survival (with creative supplies)...

Success! At reproducing the bug. 100% repro rate for all backpack sizes.

Steps:

1. Create a backpack of any size in survival.
2. Put anything in the backpack.
3. Switch to creative mode.
4. Open the backpack.
5. Observe the backpack contents.

Observed Results:
Backpack is empty and remains empty from there on out.

Expected Results:
Backpack never clears from just accessing it, in any mode.

Hello,
Thank you for the report @Vaelzan.
Thank you for your further investigation @fuzzyweapon.

I can reproduce this issue. It only occures on a dedicated server because then the getShareTag method is used, so the bug was introduced in #22

The main problem is that minecraft trusts the client in the creative mode and don't use the server item stacks.
This leads to the problem:

• Player is in creative mode
• Player opens backpack and insert item stacks
• Server saves the item stacks because the container synchronizes the stacks between the client and the server
• Server item stack now has the new nbt data and tries to send it to the client
• The getShareTag method removes the inventory tag and therefore the client item stack will not update the nbt value
• Player change item stack to an other slot
  • In survival mode this works fine because the change is done completely on the server side
  • In creative mode the change is done on the client side and then the change is sent to the server -> The client stack never gets the new inventory data -> Inventory data is lost

The problem is, there is no easy fix as I know.

• Of course I can revert #22 but this will introduce again the issue of very large nbt packets (up to 2mb) and sometimes even time outs. This won't occur with items that don't store much nbt data, but if a mod heavily use nbt data this limit will be reached pretty soon.

• An other way might be to change the behaviour of getShareTag to respect the players game mode.

  Useful-Backpacks/src/main/java/info/u_team/useful_backpacks/item/BackpackItem.java

  Lines 77 to 88 in c8d6596

  	@Override
  	public CompoundNBT getShareTag(ItemStack stack) {
  	if (!stack.hasTag()) {
  	return null;
  	}
  	final CompoundNBT compound = stack.getTag().copy();
  	compound.remove("Items");
  	if (compound.isEmpty()) {
  	return null;
  	}
  	return compound;
  	}

  
  The issue here is that I have no way of obtaining the players game mode without the use of reflections or a core mod...

If you have other ideas please let me know.
~ Johannes

Currently as a workaround I have added a config option that disable by default #22. So this bug should not appear anymore.
As a payoff #22 might occur again and the mod send many unnecessary data to the client. Must investigate in a better system to store the inventory data.
Maybe capabilities can work, but I'm not sure if they persist the creative inventory slot change.
~Johannes

And how can we manually "restore" the inventory data to recover the lost content of backpacks?
Where is the inventory data held for the backpacks or it's just the playerdata in the world folder for each player?
This is for the cases of having a backpack in inventory and switching from SP to dedicated server and losing contents.

Thanks.

I'll close this issue as there is currently no way than this little config workaround.
If some other issue occur please reopen.