I have a processing system where uu is autocrafted to sticky resin, pulled from the ACT by an extractor module and then sent to an itemsink on an extractor machine. Every time the extractor module pulls, it pulls an entire recipe of 21 resin. After three pulls, the machine has 63 resin in it with space for only one more. The next pull takes another 21 resin from the ACT, puts one in the machine, and then the remaining 20 pop out of the pipes.

My question is how to combine the concepts of backpressure and overflow safety. By backpressure, I mean the idea that if you have a system with a pipeline of several processing stages, once the last stage fills up, the intermediate stages stop extracting their outputs, and eventually the pipeline stops accepting input items. By overflow safety, I mean a system that won't ever drop items on the floor. My eventual goal is to build a feed-forward system that converts uu into hv solar arrays.

A simple way to achieve overflow safety is to add a default route to the system that dumps to a tubestuff incinerator. This gives the excess 20 resin a place to go, and the incinerator itself can never fill up. But it is wasteful, and the presence of a default route interferes with the backpressure concept. Instead of stopping when the pipeline fills up, the extractor modules will start sending items into the incinerator.

The extractor modules could be replaced with quicksorts. This would get the pipeline to gracefully stop when it fills up and the default route would only be used for excess items. Unfortunately, quicksorts do not work on machines or ACTs because they lack the required number of inventory slots.

I'd be grateful for any advice on what to do. Some ideas:

• Implement an extractor module that can be configured to allow default routes or not.
• Implement an itemsink module with hysteresis: the module ceases to be a valid destination for extractors once the inventory exceeds a certain number of items, but continues to accept items until the inventory is actually full. The module reappears as a valid destination for extractors once the inventory falls below a lower threshold.
• Implement an extractor module that will only extract to high-priority destinations, i.e. passive suppliers. Put both a passive supplier and an itemsink module on the machine. Set the passive supplier to 44 resin. If the machine contains 43 resin, the extractor will send a batch of 21. The passive supplier module would accept 1 and the itemsink module would accept the other 20, resulting in the machine being full with 64 resin.
• Use redpower regulators to measure the contents of an inventory and produce a redstone signal when a threshold is reached. Send this signal to gates that disable the extractors. There are no redpower tubes involved and no items actually pass through the regulators.

An alternative approach that I have not tried is to build a pull-based system based on supplier pipes and crafting pipes instead of a push-based system. This alternative does not seem as appealing to me because it is not self-regulating based on the rate of uu becoming available at the pipeline input. Instead, to make one hv array, there will be a large and complex crafting request outstanding that could take an arbitrary amount of time to complete. Won't it just keep timing out and repeating over and over?

at the moment extractors do not send to full inventories, only to inventories with space.

There's some code in place (currently unused) which will soon/eventually take into account items already on the way.

the best way to handle this is to qsort, not extract, as the qsort won't send to a default route
you can then have a default route-sink + provide on a chest to cach and serve the extras as needed.

crafting requests do not time out, unless an item is dropped, or bounces off a full inventory. In that case it re-orders it after 5 seconds.

The idea with the 5 seconds is in that time the item makes it's way to a provider where it can be provided. A provider (like an extractor) will only send to a destination with space in it's inventory.

edit: quicksorts do not have a slot limit any more. That was originally there because they were a laggy module. Now they are possibly the least laggy module out there.

Thanks for the responses. I'm running tekkit lite 0.6.5 with LogisticsPipes 0.7.0.96, and it appears that the slot limit is still in place. A quicksort will not pull from an ACT, but replacing the module with an extractor in the same chassis will start pulling.

When attached to a regular chest, the quicksort appears to be fast enough to pull multiple times before the first set of items reaches the destination. So there can be many items in flight when the destination fills up, and these need an alternative destination (e.g. a default route) or they pop out. I think the same thing would happen with an extractor module when the flight time exceeds the extraction interval.

I think this means that having a default route on the network is an absolute necessity. To avoid wasting items, you would want a way to resend items out of the default route chest back into the network. Another quicksort module on the default route chest could do this, but now you have two quicksorts competing for the same destination space, with no way to prioritize already-made items from the default route chest over new items out of the ACT.

A pull-based system using supplier pipes is starting to look like a better idea. But I still think it would be nice to have a system regulated by the arrival rate of the uu rather than the supplier pipe pull rate.

Thanks for your work on this mod - this is a fun engineering problem.

on the todo list is for push items to take into account items already on the way.
I might even do that this weekend ...

I generally use push for bulk processing (ore->ingots), and pull for rate limited, and specific output (crafting fertilizer for farms, and other uses of crafting arrays)