Issue type:

• 🐛 Bug

Short description:

Counting one particular item from the inventory of a Storage Drawers Controller Slave, doesn't work correctly if that Slave is also being routed through for items using item tunnels. The count blinks between zero and the correct count, even if said item routing is not active and spread across the wrong channels.

Steps to reproduce the problem:

1. Rebuild the simple setup from below screenshot
2. Set the "Import all items" aspect of the Item Importer to channel 1 and Passive Interaction=false
   (make sure the Item Interface remains on channel zero or any other channel than the Importer)
3. Insert a blank variable card (A) into the above mentioned aspect
4. Insert a blank variable card (B) into the Items (List) aspect of the Inventory Reader
5. Insert a stack of any item into the drawer (doesn't have to be crystalized chorus chunks)
6. Program a new variable card (C) to the same item
7. Program a new variable card (D) to ItemListCount of cards B and C in that order
8. Insert card B and C into the variable store and put card D into the display panel
   →:x: Notice the display panel now blinks back and forth between 0 and 64, with inconsistent intervals

Note that, even if you put more than a single stack into the drawer (or ensure the contents is higher than the transfer rate), and put both importer and interface to the same channel, the display panel will still blink.

Also note that, replacing the Storage Drawers blocks with just a vanilla chest filled with the item, does not cause this blinking behaviour.

Expected behaviour:

The display panel should be showing a consistent 64, and never blink back to zero. Because no items are actually being transported and never is the count actually zero. It looks like the inventory count is periodically unavailable to the network for some reason.

Versions:

• Dynamics: 1.8.4
• Tunnels: 1.8.2
• Core: 1.11.7
• CC: 2.7.0
• Minecraft: 1.16.5
• Forge: 36.1.32
• Other mods installed:
  • JEI 7.7.0.106 (for convenience)
  • Storage Drawers 8.2.2

Log file:

Thanks for reporting!

So if I understand correctly, you're creating a continuous loop of item transfer using the importer and interface.
If so, then the blinking behaviour sounds like expected behaviour to me.
That is because the importer will extract some items from the network+drawer, and reinsert it back again immediately.
Due to caching (for achieving better performance), the observable network contents will only be updated a bit later, hence the blinking behaviour.

In any case, I would recommend against creating such loops, as this will place unneeded stress on your server, as it essentially does nothing.

You're right that this is a loop, sort of. But not exactly. The transfer doesn't actually even happen, items stay in place because of the deliberate channel mismatch. If what you say is intended, then this should not happen if the channels are mismatched.

Also, originally in my nontesting world where I discovered this, the transfer that is "looping" the network on the slave, was actually not a loop at all. Different items were extracted from it to a different place and somewhere else was exporting other items to it on a different channel. So the loop is only in effect in terms of logic cable connectivity.

Something should be moving, otherwise I see no reason for the blinking to happen.
What happens if you remove the variable card from the importer?

Both if I remove the importer's variable card or if I remove either the interface or importer, will cause the blinking to stop.

Also, if the "transfer" that is not supposed to take place, is lower than the total count available, for instance 128 stored and transfering 64, then the count logically would be expected to blink between 64 and 128, however it always blinks back to zero instead (also applies to 693 stored and 579379 stored, always blinks to zero).

So it's not just a delayed visual of a transfer actually happening, it's a total unavailability of the count at all.

Weird, perhaps some kind of cache is being invalidated in storage drawers when a (failed) import takes place.
In any case, if this doesn't occur with plain vanilla chests, I don't see how ID/IT could be causing this, as ID/IT handles both identically.

Could you report it over at their issue tracker?

I will, thanks.

Also with further testing I finally produced definite proof there is no looping going on:

The left importer is specified to empty the empty chest into the slave, the other one is transporting variable cards to the chest (which aren't in the system).
When I remove the item interface on the left, the blinking stops. However obviously, that one isn't even connected to the network that shows the blinking.

Closing this one here in the meantime.