Storage Drawers: Forestry Pack

Storage Drawers: Forestry Pack

6M Downloads

Loss of Items from Iron Backpack

p75369 opened this issue ยท 7 comments

commented

Posting this here as well as I don't know which mod is at fault.

gr8pefish/IronBackpacks#19

I had items destroyed when using Quick Deposit to dump my backpack into a Storage Drawers controller that did not enough attached drawers to store everything.

Minecraft version 1.7.10
Iron Backpacks version 1.0.4
Forge version/build 7.10.99.99 (i think)
Versions of any mods potentially related to the issue Storage Drawers 1.5.14

Steps to reproduce
Place down an insufficient number of storage drawers with an attached controller (mainly focussing on the number of different types of item, rather than stack size), shift click the contents of the backpack into the controller.

commented

Also had this issue

Also happening with Storage Drawers 1.6.2 and Iron Backpacks 1.0.4 and was still able to replicate:

1: Put stuff in backpack
2: Shift right click on storage controller
3: Check backpack
4: Be amazed at magic trick/empty backpack.

Also to note I had a few drawers free, but i think it's just the controller as if you shift right click on an empty draw it will put the item in (Provided you have one type in backpack).

commented

I disagree with the assessment, but I think it is a difference in the behaviors of isItemValidForSlot and canInsertItem in StorageDrawers that is tripping things up.

Like any deep storage block, SD's IInventory is telling you a lie and presenting slots that are only valid for input, and slots that are only valid for output. The ISidedInventory can* methods do the obvious right thing, but isItemValidForSlot would give you the green light as long as the items matched (essentially). This probably led to you inserting into extract-only slots, which might have then re-balanced incorrectly.

While said behavior matches Jabba, and diverging from Jabba usually gets me in trouble, aliasing isItemValidForSlot to canInsertItem makes sense and fits the documentation. We'll see.

That said, I could not reproduce the problem, even with knowledge of such weird edge cases (and in reality, the balance operation is pretty forgiving anyway). If this release doesn't fix the problem, then I have no possible leads and a concrete reproduction will be absolutely required.

https://github.com/jaquadro/StorageDrawers/releases/tag/sd-1.7.3

commented

I will not release that build to CurseForge until I get confirmation that it fixes the issue, so please test and report back.

commented

Hmm fair enough on the canInsertItem, I agree with you.

I'll test and let you know if I can reproduce the issue. I couldn't even reproduce it before though, so don't expect too much.

commented

Thanks, but that was mainly directed at the two people who did claim to see the problem ;)

I'm sure either of us could identify the exact cause quickly if we could reproduce it.

commented

Ah haha yeah that makes more sense. I will alter my code to use canInsertItem anyway I think.

Edit: canInsertItem is implemented, thanks for the suggestion.

commented

Right, so I think this is on your side, as I tested it pretty extensively myself and couldn't find fault on my end (there is still the possibility, but it is unlikely).

I haven't looked in depth at your code, but myself and TehNut think what happens is that the Drawer Controller reports X open slots when you right click it, the backpack thinks it has enough so it dumps all the items, then the controller actually doesn't have the amount that it reported, so the items poof.

If you want to see what I am doing on my end here is a good place to look. Edit: Ignore that TODO on line 635, it's fixed.

Good luck :D