Item Exporters set to exact amount hang if first ItemStack is below transfer threshold
Parker8283 opened this issue ยท 8 comments
Issue type:
Only keep the issue types that are applicable.
- ๐ Bug
Short description:
When setting an Item Exporter to use "Exact Amount" for transferring, and setting the amount to some threshold, ItemStacks closer to the front of the inventory that are below the threshold block ItemStacks farther down in the inventory from being transferred, even if their size is above the threshold.
This was tested with a simple boolean true
for the Export All Items condition.
Expected behaviour:
If the given condition allows, any ItemStack in the inventory that has a stack size above the threshold specified should be allowed to transfer.
Actual behaviour:
The stack with a lower stack size that is in front of the stack with the higher stack size prevents the latter from transferring, even though it has enough items to meet the requirements to transfer
Steps to reproduce the problem:
- Set up two chests with an Item Interface on one and Item Exporter on another.
- Set up a transfer condition of a constant true with "Exact Amount" set to true and "Item Transfer Rate" set to some number. (I used 9 as I originally discovered this when working moving items to an IC2 Compressor)
- Place a stack of one item with a stack size less than the threshold previously specified, followed by a stack of another item (can actually be same item from my testing) that meets or is over the specified threshold.
- Observe that none of the second ItemStack is being transfered.
Versions:
Exact versions of the following mods, not just latest.
- This mod: 1.5.5
- CyclopsCore: 0.11.5
- Minecraft: 1.12.2
- Forge: 14.23.2.2654
Not sure if you had a chance to look at this yet, but I poked around for a little bit, and this is what I found.
This is where it short-circuits. Because it failed to move the ItemStack in the first slot, it's just returning out of the function, which short-circuits out of the moveItemsStateOptimized()
function as well. As someone who is not as familiar with your codebase, I didn't know the best way to approach a fix, so I just figured I'd leave this here.
Sorry, haven't had time yet to look into this. Hopefully next week (pretty busy with RL stuff atm...).
That indeed looks like the place where it goes wrong. I'm afraid that I might have to make some non-insignicant changes to fix this, so it'll indeed be better if I fix it myself. Thanks for checking it in any case!
No rush! Not trying to push you or anything. Just figured if you were busy I'd try to fix it myself so you didn't have to worry about it. But after looking at it, it looks like I threw myself into the deep end. :P
Hello, I just encountered the same issue and was wondering if there was any update on correcting this? Working with the GTCE (GregTech Community Edition) and this would solve a HUGE functionality issue that I cannot get around with their tools as far as ore processing is concerned. Thanks!
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.
Side-note: there is currently a new issue with exact amount (#145) that will be fixed soon.