Issue type:

• 🐛 Bug

Short description:

When there are destinations for a round-robin group that don't accept the to be transferred item, it throws off the distribution of the round-robin algorythm.

Testing with 2 out of 3 accepting targets, everything ends up in 1 accepting target (pattern 64-0-X), but with a different amount of targets the result changes (e.g. a pattern of 32-0-16-16-X)

Steps to reproduce the problem:

1. Setup a network like in the screenshot
2. Modify the "Import Item" aspect like this:
   • Round-robin: yes
   • Item transfer rate: 1
   • Passive interaction: no (might not be related)
3. Use logic programmer to program these variable cards:
   • 3x Item "Oak Log"
   • 1x Item "Birch Log" (or anything not oak log)
4. Put the Birch Log variable card into the Item aspect of the top filtered interface (as mentioned in the screenshot)
5. Put a Oak Log variable card into the Item aspect of the importer
6. Put the remaining Oak Log variable cards in the remaining filtered interfaces
7. Put a full stack of oak logs in the container on the left
8. Notice how they all end up in one container on the right

Expected behaviour:

Eventhough not all reachable destinations are filtered to accept the incoming item, all remaining targets should still get an equal amount of the total distribution. In this case the bottom 2 containers on the right should both get 32, keeping the top one empty.

Versions:

• Dynamics: 1.23.3
• Tunnels: 1.8.31
• Core: 1.19.5
• CC: 2.9.3
• Minecraft: 1.20.1
• Mod loader version: Forge 47.3.10
• Other mods:
  • jei-1.20.1-forge-15.19.5.99
  • theoneprobe-1.20.1-10.0.2

Also tested with newer neoforge:

• Dynamics: neoforge-1.23.6
• Tunnels: neoforge-1.8.28
• Core: neoforge-1.23.0-601
• CC: neoforge-2.9.4
• Minecraft: 1.21.1
• Mod loader version: NeoForge 21.1.51
• Other mods:
  • jei-1.21.1-neoforge-19.19.0.219
  • theoneprobe-1.21_neo-12.0.3

Log file:

Thanks for reporting!

Do note that when the blocking target is removed, the algorythm fixes itself straight away. So it specifically has something to do with the blocking target(s).

Also note that the issue is not with the filtered item interface; replacing them with normal item interfaces and self-filtered containers observes the same result.

This has been fixed, but I'll wait with making a new release until I've resolved the other open bugs.