RFTools

RFTools

74M Downloads

Compacting storage drawers having contents deleted

vdrake77 opened this issue ยท 12 comments

commented

Using the storage scanner and a couple inventories, two of which were compacting storage drawers holding gold ingots and redstone and making capacitors.

Some point during, it totally cleared the contents of both storage drawers. I've been trying to figure out how, but with no luck. I've gotten it to occur several times, but can never quite get figure out when or why, but I think it might have something to do with crafting. I think whatever solution was used to prevent duping might be too aggressive.

commented

What version of rftools?

commented

1.10-5.07

commented

I can reproduce this. Checking it out

commented

@jaquadro I would like your advice on this. Apparently there is a problem with the compacting storage drawers. Can you tell me exactly how compacting drawers work with regards to how they handle slots and the 'virtual' items so that I can make sure my method works with that as well?

commented

All slots are backed by the same variable. Each slot reads or writes that variable with a different multiplier applied, so any change to one slot will simultaneously change the others, from the POV of anything interacting with the inventory.

That brings a couple points to bear:

  • Any time you insert or extract from a compacting drawer, any ItemStack you previously read from any slot in the block should be considered invalid with respect to the current state of its slot.
  • You cannot simulate multiple extractions or insertions into a compacting drawer, because subsequent simulations will not remember the effects of modifying another slot.

Based on what I reviewed the other night, your strategy of physically removing items in your simulation should handle this correctly, since those accumulating effects will be honored.

The same caveats apply to working with controllers, because some of their slots can be compacting slots, and thus subgroups of slots will affect each other's state.

commented

Ok, it does seem to work in most cases (i.e. when the crafting test only extracts part of the items in a compacting slot) but it doesn't work fine in case you request more items then are available. It appears that when my system extracts all available items (like a full stack of 64 redstone if that's all that is in the drawer) then my 'undo' operation can't seem to insert that redstone back and evertyhing is lost.

So that's the situation that I need to solve

commented

Does this happen if the drawer is locked?

If it's only with unlocked drawers, then it's probably because all the slot associations and conversions are lost when the drawer's inventory drops to 0. Once that happens, slots 1 and 2 become disabled, so the item would need to be put back into slot 0 (it would get shuffled into the right place as it reinits itself).

This is something I can probably handle on my end, to avoid need for a hardcoded block check.

commented

It happened with an unlocked drawer

I could potentially also solve it on my end by implementing a fallback in the undo() in case the insertion fails. I can test for that and when that happens just try to insert in the first slot or in the first available slot or something. Do you think that would be a good idea?

commented

If there's another mod that disables some of its slots based on what's in the block, I can't say that it would be safe to assume that you try and stuff them into slot 0. The only way you know for sure your fallback will behave as expected is to wrap it with if (blockName == 'StorageDrawers:compDrawer'). Since I think I can address this cleanly on my side, you shouldn't need to pollute your code with that.

commented

True, on the other hand. Solving this also on my side makes it safer in case someone else has some similar mechanism to what you have. Also I can detect the items will be lost if I do nothing so I think it would be best if I at least try to insert them into the device somehow. I can just do the same like any item insertion algorithm would do and that should be safe. i.e. just by using ItemHandlerHelper.insertItem(). That method should be safe for any inventory accepting items. If not a lot of things would break

commented

Sure, at worst it should just reject your stack. It's up to you. I'll still review my code, but if you want to handle this then you might have a fix released before me.

commented

Ok, I made it as safe as I can. First I try to put it back in the original slot. If that fails I just try to insert it in the inventory. If that fails I try to put it in players inventory and if that fails I'll just spawn it in the world. So there should really be no way to lose items now :-)

So fixed for next release