You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have checked for existing issues, and have found none.
Tested latest version
I have checked that this occurs on the latest version.
GregTech CEu Version
1.6.4
Minecraft Version
1.20.1 Forge
Recipe Viewer Installed
JEI
Environment
Multiplayer - Dedicated Server
Cross-Mod Interaction
No
Other Installed Mods
ATM9 modpack
This goes way back and was never fixed in Nomifactory or GTNH (in those cases items could be voided if transfer rate > 1 and not a divisor of
filtered counts)
Expected Behavior
Using a robot arm on keep exact mode with a filter on whitelist (either on pipe with extract or on machine with inport).
At least two distinct items, say A and B, in the whitelist, each with a specified count (equal or not), say X and Y.
Target inventory/machine should receive exactly X amount of item A and Y amount of item B.
Actual Behavior
The first considered count (last in reading order in the filter IIRC) acts as the amount of total items.
Say X is considered, the machine receives a total of X items in an arbitrary combinations (whichever are supplied first) of items A and B.
Y is ignored.
The behaviour is normal if only one item is filtered, but as soon as two items are filtered one starts to see this issue.
Steps to Reproduce
A good test example would be the sulfur dust+raw rubber dust recipe in a chemical reactor.
Setup a chemical reactor (CR) and two input sources (chests with conveyors or machines with auto output), one with sulfur dust,
the other with raw rubber dust. Connect all 3 with item pipes.
Setup a robot arm, either on the CR in import mode, or on a pipe at the CR in export mode (bug happens in both cases).
Set the robot arm in keep exact mode.
Add a whitelist filter to the robot arm with both sulfur dust and raw rubber dust with their respective counts.
(either same counts, say 32 and 32 or distinct counts, say 2 and 18)
Additional Information
This is likely caused by an algorithmic error when looping through filtered items while book-keeping
transfered item amounts and checking against per-item exact counts.
The text was updated successfully, but these errors were encountered:
Checked for existing issues
Tested latest version
GregTech CEu Version
1.6.4
Minecraft Version
1.20.1 Forge
Recipe Viewer Installed
JEI
Environment
Multiplayer - Dedicated Server
Cross-Mod Interaction
No
Other Installed Mods
ATM9 modpack
This goes way back and was never fixed in Nomifactory or GTNH (in those cases items could be voided if transfer rate > 1 and not a divisor of
filtered counts)
Expected Behavior
Using a robot arm on keep exact mode with a filter on whitelist (either on pipe with extract or on machine with inport).
At least two distinct items, say A and B, in the whitelist, each with a specified count (equal or not), say X and Y.
Target inventory/machine should receive exactly X amount of item A and Y amount of item B.
Actual Behavior
The first considered count (last in reading order in the filter IIRC) acts as the amount of total items.
Say X is considered, the machine receives a total of X items in an arbitrary combinations (whichever are supplied first) of items A and B.
Y is ignored.
The behaviour is normal if only one item is filtered, but as soon as two items are filtered one starts to see this issue.
Steps to Reproduce
A good test example would be the sulfur dust+raw rubber dust recipe in a chemical reactor.
Setup a chemical reactor (CR) and two input sources (chests with conveyors or machines with auto output), one with sulfur dust,
the other with raw rubber dust. Connect all 3 with item pipes.
Setup a robot arm, either on the CR in import mode, or on a pipe at the CR in export mode (bug happens in both cases).
Set the robot arm in keep exact mode.
Add a whitelist filter to the robot arm with both sulfur dust and raw rubber dust with their respective counts.
(either same counts, say 32 and 32 or distinct counts, say 2 and 18)
Additional Information
This is likely caused by an algorithmic error when looping through filtered items while book-keeping
transfered item amounts and checking against per-item exact counts.
The text was updated successfully, but these errors were encountered: