Originally shared on the public FactorioPrints / Factorio School archive (factorioprints.com · factorio.school). Authorship preserved from the public catalog.
Tired of your space platforms firing off scads of cargo pods, with only a few items in each? Frustrated that your cargo landing area requires so many cargo bays to accept imports?
I present to you a solution: logic that requests orbital drops a) in stack sizes that fill a cargo pod, and b) only requests an orbital drop of a particular item when locally-cached resources fall below (configurable) targets. This issue seems to be (at least partially) addressed in Factorio pre-release 2.0.25 - but this blueprint should continue to be useful even after platforms are a little more greedy about batching exports into cargo pods.
Oh and it uses color-coded lamps to indicate when it makes a request for particular type of item (by default, the lamps are set for science packs). Available in an unlighted version as well (uses half as many combinators).
How It Works:
Reads the current item counts from connected containers/belts, AKA the "cache"
Checks each item type versus the amount desired in the cache, AKA the "restock threshold"
For each item with a quantity less than its restock threshold, the system will emit a 1-tick pulse of that item with the amount to request from the logistic network, AKA the "cache target" amount
Passively monitors the amount of each item in the cache and automatically emits the 1-tick restock request immediately upon an item dropping below its restock threshold
Every so often, actively checks the cached amount of each item and automatically to emits the 1-tick request for each item below its restock threshold
This also ensures that restock requests that were unable to be fulfilled periodically get re-requested
Space platforms orbiting this planet automatically receive the restock requests via the logistic network, and then for each item requested, dispatch a cargo pod with (up to) the requested amount
Generally, this will result in 1 cargo pod per item type being dispatched, with a full stack of that item
If there are fewer items available than the amount requested, the available amount is dispatched
Multiple platforms may attempt to fulfill the same request if they have any of the requested items available; the logistic system should prevent more than the requested amount from being dispatched in total, but multiple drop pods may be dispatched (at most 1 per platform responding to the request)
How to Set Up:
Place the blueprint near your cargo landing pad for simplicity, or far away with circuit connections
Create 1 or more chests or other circuit-network-connectable storage near your cargo landing pad, then connect these all with red wire and ensure they have some variant of "read contents (hold)" enabled
Configure your desired item cache targets using the labeled constant combinator (you can add or remove from the defaults); each item signal's magnitude influences how many of it should be imported from orbit:
Explicitly, the "cache target" amount/"restock request size:" the desired maximum(-ish) quantity of that item in the planet's cache & the # to be requested per restock request
Implicitly, the "restock threshold" (half the cache target): when the cached amount of an item drops below its threshold, the system automatically sets a logistic request for it on the cargo landing pad for 1 tick
By default, cache target configuration is set for the 6 non-Nauvis science packs @ 200 each
Configure the polling period Z via (a different) constant combinator; this is the amount of ticks between active cached item checks; default 3600 (1 minute)
Make the 2 required and 1 optional circuit network connections, which are all indicated with constant combinators - you can remove these 3 combinators after making the network connections
The required red network connects to the cache to read item counts
The required green network connects back to the cargo landing pad to set logistic requests
The optional green network connection connects to any inserters that should automatically set their filters based on items missing in the cache; mostly useful if offloading all incoming cargo into active provider chests
Set the cargo landing pad to "set requests" mode
Add or remove any colored lights; additional packed RGB colors for more items can be defined on (yet another) labeled constant combinator
Wait for the system to perform an active check of the cache
Enjoy a much smaller amount of cargo pods dropping coming down in a lovely, synchronized fashion
Caveats:
You cannot use "read contents" on your cargo landing pad, which is quite the shame because it would be the most appropriate place to store the cache of items; with all those attached cargo bays it has cavernous storage space and wouldn't require adding intermediate containers to act as a cache. Maybe we will eventually get the ability to independently filter which mode(s) an entity applies to each of its circuit network connections, similar to filtering the input and output of arithmetic and decider combinators to red and/or green.
Until then, the cargo landing pad must be unloaded and cached in chests/belts so the relevant containers can have their contents read. Use the (optional) inserter automatic filter green network to unload into chests/belts without differentiation (suggested for unloading into active provider chests), or set up your own strategy, e.g. static filtering on several inserters to load certain items onto different belts.
