Is it possible to detect slots with item restrictions in Inventory peripherals?

[fechan]

Some inventories like the vanilla Brewing Stand have hard restrictions on what items can be placed in them (unlike Blast Furnaces, which allow you to insert arbitrary items regardless of whether they're blastable). I'd like to be able to detect these restrictions.

For context: I have an algorithm which tries to move items from one arbitrary group of [peripheralName, slot] pairs to another, and generates the minimal number of inventory.pushItem coroutines required to move those items. These coroutines are then run using parallel.waitForAll.

However, since I don't know how to detect item restrictions on the destination slots, the algorithm assumes the destination slot is successfully filled by the item in the lowest numbered slot in the origin group (even if it is incompatible), and will not generate an inventory.pushItem for other potentially compatible.

[Wojbie]

Could you not modify your code to read inventory.pushItem return value and verify how many items it moved or if it moved any at all and detect this way that slot is not a valid target for specific item?

[fechan]

I considered using that value for this purpose, but since I'm trying to come up with a set of pushItem calls that can run in parallel and transfer items from inventories with possibly gigantic sizes, I would ideally prefer not to generate pushItem calls that could fail.

More specifically, I considered defining a set of backup destination slots for each item being transferred. Then within each coroutine if the first pushItem failed, it would try the next backup slot. Of course, since the slot is still free, then I could check if another item in the origin inventory could go into that slot with some recursion or something.

However, since each pushItem incurs a 50ms performance penalty, this does not scale well if there are a large number of destination inventory slots. If no items in the origin inventory can go into the destination inventory, then there would be up to NxM failed pushItem calls, where N and M are the sizes of the origin and destination inventories respectively.

[SquidDev]

Sadly there isn't really a generic way to do this. Minecraft doesn't expose any information about what items can be inserted into a slot, so the only way you can do it is to try and see.

If no items in the origin inventory can go into the destination inventory, then there would be up to NxM failed pushItem calls, where N and M are the sizes of the origin and destination inventories respectively.

I don't think this is too bad. Typically M is going to be small - things like brewing stands or furnaces are only a couple of slots. I guess if you have a chest full of items, you'd have to try $5 \times 27 = 135$ different combinations (though note you could do some of these in parallel) — maybe in that case it is better to have custom handling for specific inventories.

Though that said, does it make sense to have an automatic bulk-transfer function to a brewing stand? I imagine in most cases you do actually care about which items go in which slots, and so some generic function makes less sense.

[fechan]

It's too bad it's impossible. Thanks for replying anyway!

The program I'm writing is essentially a ComputerCraft replacement for modded item pipes, with the added feature where you can pool together peripherals and group together their inventory slots arbitrarily, like if you want to address a bunch of furnaces as a single "machine". So you'd create virtual pipes implemented in software that would tell ComputerCraft how to transfer items between these groups of item slots.

As a workaround, I'll probably tell the user if the pipe is failing to transfer items and ask them to define an item filter manually, which is probably fine UX-wise.

[SirEdvin]

You can just have a specific wrappers for different inventory types in your program, this usually helps to solve this kind of issues.