Issue type:

Only keep the issue types that are applicable.

• 🐛 Bug

Short description / Steps to reproduce:

I have an item network with the following:

• Chest (A) with an item exporter (priority 1) that has a variable card duped from the interface reader on the same chest (ie, if an item is in this chest another item of the same type should route here)
• Chest (B) with an item exporter (priority -10) that has a export all variable card
• Chest (C) with an item exporter (priority -5) that has an export predicate for modded items

Changing the relative priorities of Chest B and Chest A doesn't fix the issue.

Expected behaviour:

I would expect that when I import items into the system that have an identical item in chest A, that they would route to chest A
I would expect that when I import items into the system

Actual behaviour:

When I put a modded item (say a blue slimeball from TiC) in chest 1 and import more of the same, sometimes they end up in chest B

When I put a vanilla item in chest 1 and import more of the same, sometimes they end up chest C

Versions:

• Integrated Dynamics: 1.12.2-0.10.3
• Integrated Dynamics-Compat: 1.0.0
• Integrated Tunnels: 1.12.2-1.4.1
• Integrated Tunnels-Compat: 1.0.0
• CyclopsCore: 1.12.2-0.11.1
• Minecraft: 1.12.2
• Forge: 14.23.1.2601

Could you first try updating to the latest version to see if the problem still exists there?

I've upgraded to the following versions and the bug is still occurring:

Integrated Dynamics: 1.12.2-0.11.8
Integrated Tunnels: 1.12.2-1.5.4
CyclopsCore: 1.12.2-0.11.5
Forge: 1.4.23.2.2629

Thanks for checking, I'll look into it soon.

Did some testing with this, and I'm afraid this will be pretty difficult to solve. I will be unavailable for a couple of weeks, so I won't have time to fix this until I come back.

In the meantime, disabling the item cache (inventoryUnchangedTickTimeout to 0) might fix the problem, but might also increase server load slightly. (Please let me know if this actually fixes the problem for you)

Note to self:
This is probably caused by the item cache timeout that is not synchronized between the two item exporters. This can be fixed by making sure that caches for the same target (and source?) are invalidated at the same time. I might have to decouple source and target hash into separate parts for that.

Last week, I released a new version of Integrated Tunnels (1.6.0) that consists of a big rewrite in how things are transferred. This issue is likely to be resolved with this rewrite. I'm auto-closing this issue if no new reports for this come up in the next coming weeks.

Yup, having exactly the same problem as yannprada. Priority setting not making any difference when working with multiple chests. Also on the latest version in Sky Factory 4.

@yannprada As far as I understand your description, this works as intended. The priority only indicates the order in which each exporter ticks. Since you've set transfer rate to 1, each exporter will move 1 item per tick. But if there is more than one item in the input chest, then it is normal that the items are spread evenly over the chests.

What you probably want, is to reverse the parts (make the interface an importer, and the exporters interfaces). Setting the priorities properly should allow you to do what you want.

Hi, maybe I should open another issue, idk.

Version: 1.12.2-1.6.7 (part of Sky Factory 4)

Setup:

• Input chest with an item interface
• 3 chests with item exporters, all set to:
  • export all items
  • transfer rate: 1
  • Priority respectively: -10, 0 and 10

Current behavior:
All items are spread almost evenly in the output chests, regardless of priority.

Intended behavior:
All items should go in the chest with priority set to 10.

Thanks for your answer.

As for my chest setup, once I revert the tranfer rate back to 64, the whole stack moves to the chest with the highest priority (10).
Except the first time. Idk why, but the first test yielded with the stack in the priority 0 chest. Maybe the network tried to send the stack without detecting all the exporters ? (idk how it's coded, so blind guess here ^^)

The setup you proposed works like a charm, and it's faster. It doesn't have the initial delay mine had. Thanks again for your response.

FYI, this requires some low-level changes in IT. This will be fixed in the next major release, which will consist of a partial rewrite.