Sophisticated Core

Sophisticated Core

49M Downloads

[Bug] Items are lost when unloading or replenishing from a high-capacity [Stack Upgrade] to a low-capacity container.

FirDragon opened this issue ยท 4 comments

commented
  • Reproduce the environment

Mode: Single player mode and online mode
Version: Current latest: 53098b8
Upstream: Sophisticated Backpacks to Sophisticated Backpacks & Sophisticated Backpacks to Sophisticated Storage

  • Steps to reproduce

Item loss occurs when using [Deposit Upgrade] or [Restock Upgrade] with a [Stack Upgrade] sophisticated container to transfer items to another sophisticated container with low [Stack Upgrade] or no [Stack Upgrade].

  • helpful

I found the possible cause of this bug.
[Sophisticated Backpacks] calls [net.p3pp3rf1y.sophisticatedcore.util.InventoryHelper:transfer].
[net.p3pp3rf1y.sophisticatedcore.util.InventoryHelper:transfer] is executed through simulation to calculate the number of items to be subtracted. So use the parameter [simulate] as true to indirectly call [net.p3pp3rf1y.sophisticatedcore.inventory.InventoryHandlerSlotTracker:insertItemIntoHandler].
Then insertIntoSlotsThatMatchStack will be called. Due to the stack upgrade, not all items can be moved. So keep calling insertIntoEmptySlots after subtracting the result of insertIntoSlotsThatMatchStack.
insertIntoEmptySlots will be indirectly called to [super.insertItem] through [net.p3pp3rf1y.sophisticatedcore.inventory.InventoryHandler:insertItemInternal]. At this time, [super] is [net.minecraftforge.items.ItemStackHandler], and its insertion logic uses "ItemStack existing = this.stacks.get(slot);" as a reference for existing items. But at this time, due to the simulation execution, the state before [insertIntoSlotsThatMatchStack] still exists in "this.stacks". This will cause the inserted quantity to be counted again, thus incorrectly calculating the remaining quantity of the item.
After returning to [insertItemIntoHandler], you will find that the number of [remainingStack] has been reduced twice by mistake. Go back to [InventoryHelper:transfer] and find that the value of "slotStack.getCount() - resultStack.getCount();" is twice the correct value. Subsequent "copiedStack.setCount(countToExtract);" will lose twice as many items.

commented

Sorry, there is a typo, I modified it:"So use the parameter [simulate] as false" -> "So use the parameter [simulate] as true"

commented

Minecraft containers are not affected.Because the InventoryHandlerSlotTracker will not be called.

commented

image
I tried to fix this problem locally through the following methods.
Did you copy the last overloaded method and forget to delete part of the code?

commented

Just released version with fix on curseforge