GT-New-Horizons-Modpack
GT-New-Horizons-Modpack copied to clipboard
GTNewHorizons
GT Item Filter does not work as expected when paired with high throughput pipes
Which modpack version are you using?
2.0.9.0QF4
If in multiplayer; On which server does this happen?
Private server
What did you try to do, and what did you expect to happen?
Item filter + Restrictive Item Pipe set up to separate Ore Washer ores from Chemical Bath ores.
What happened instead? (Attach screenshots if needed)
Only about 1/3 of the ores matching filter goes through the Item Filter, the rest end up in the restrictive item pipe.
By choking the output pipe to 1 stack/sec the filter will work correctly, but this kills the system's throughput.
What do you suggest instead/what changes do you propose?
This issue is caused by GT item filters only buffering 1 itemstack per filter slot per operation - so if 3 stacks of Nickel Ore are routed through the pipe at once, the item filter accepts one stack and the rest are rejected - so they go the other way.
Solution: Allow GT block filters to immediately consume and push incoming items instead of buffering them in inventory and trying to push it later.
Iirc, in a cycle of item movements, item filters will only allow the amount of stacks of items within the filter to be transfered. So if you filter 4 ores, and your main pipe pulls 5 stacks, that last stack will go through the restrictive pipe.
If you're doing ores tho, you probably don't want item filters, try a type filter instead
Iirc, in a cycle of item movements, item filters will only allow the amount of stacks of items within the filter to be transfered. So if you filter 4 ores, and your main pipe pulls 5 stacks, that last stack will go through the restrictive pipe.
The filter is set to filter 5 ores, but even if I insert only 2 stacks of Nickel, one stack is rejected. So it doesn't work the way you described and my original description is its current apparent behavior.
If you're doing ores tho, you probably don't want item filters, try a type filter instead
Per my original post I'm separating the Chemical Bath ores (the ones that give good byproducts) from the Washing Plant ores. Type filters don't work for this.
That's different if you have nbt enabled. If you only have 1 nickel ore in the filter, it will only handle 1 stack per cycle
If I disable that then the filter is pointless, I need it to match only the 5 ores I have specified.
Yes, it isn't really going to help you here for sorting ores like that. Sfm or eio is best for filtering more specific items like that
The point is GT filters are not compatible with GT pipes because the filters have a limited throughput regardless of tier, which is a bug that can be addressed by making the filters try to emit the item on the output side as soon as they receive it, and only buffer internally if it fails.
It makes the filters work a lot better for automation setups involving GT pipes and it's not like this breaks balance or anything.
This is not a solution to the issue but in your specific setup you could replace the restrictive pipe with inverted filters containing what you would want to put through the chemical bath. I do agree that the item filter limitation should not be, or at least the output limitation should improve with the tier of the filter. I am curious if this limitation is specific limitation is unique to the item filter or if many of the gt filtering blocks share it.
The Type Filter has 9 buffers, so when you feed it more than 9 items in the same feed cycle (like with an IV conveyor) it does the same thing - rejects the excess until it can emit again.
The GT filters (looking at GT5u source) don't emit items by themselves - they are currently implemented to just let items be put into them with allowPutStack() (see here for source). Item emission happens separately in GT_MetaTileEntity_Filter and is handled by moveItems() triggered by onPostTick().
I'm not too familiar with GT TE work order, so not entirely sure if anything bad will happen if you make a filter try to emit items as soon as it receives some.
The simplest non-breaking solution would be to increase the internal buffer along with the filter tier. Although transparent filter is probably also ok, it would make tiering useless