It allows every planet to define what it needs, and what it exports.
Production, import, export, and space‑platform delivery are all automated through circuit logic.
Overview
Each planet becomes an autonomous logistics node. You configure two lists:- Demand list – items the planet wants to have available locally
- Item advertisements – items the planet offers for export to other planets
- Builds the difference between inventory and demand so you get current demand and surplus
- Allows production machines to run only when current demand exists (connect your mall here!)
- Creates cargo landing pad requests for items in demand that are advertised from other planets
- Instructs a space platform to pick up advertised items from source planets and deliver them to requesting planets
How the system works
Radar‑Based communicationOne universal radar channel is used for communication. On green wire, planet requests are collected. On red wire, planets advertise their items.
The advertisements tell for every planet: "I offer this item", so they can be bitmapped and merged into one list. Every planet uses a different bit (Nauvis=1, Vulcanus=2, Gleba=4, Fulgora=8, Aquilo=16) so if you filter by the planet bit you get exactly what item is being advertised by which planet without requiring a separate radar for each item list.
Green wire tells: "We want these items from some planet".
Red wire tells: "I supply these items".
Requests for advertised items: Filtering the advertisements for one planet (here: Nauvis) Local Demand
- The demand list can be used by assemblers to check if they should start crafting an item. Positive numbers indicate surplus (stop crafting), negative numbers indicate demand (start crafting).
Export Logic
In case an item is listed in the advertisements:
- The system creates a cargo landing pad request
- A space platform imports the item from a planet that advertises them
- If the platform has a requested item as cargo and is in orbit of the requesting planet, it will satisfy the planet request
Daily Operation
With a static request list on the platform, you need a huge inventory to keep all possible items in supply. Usually, the inventory is always overflowing and there are still items missing and you need to change the list constantly.Instead, requests show up dynamically and the proper amount is being loaded into the platform. No matter if it's just 5 items or 5000: it's one transaction.
If the system is in operation, you just configure your wanted items on each planet, build production for items you intend to craft locally and configure the advertisement for the items you intend to export to other planets.
There are 2 exception lists:
- items to craft locally even if there is an advertisement from another planet (use this if 2 planets export the same thing)
- items to create a request even if the planet advertises this item (use this if a permanent platform in orbit crafts this item instead of the planet itself, for example the space science pack)
Platform control: The schedule is static: it makes the platform going round robin to visit every planet. To ensure minumum travel times, it goes Vulcanus → Nauvis → Fulgora → Aquilo → Gleba.
Planet control:
In general, they're all the same, just have their own planet specific lists.
Nauvis:
Vulcanus:
Gleba:
Fulgora:
Aquilo:
If you want to know more details, inspect the blueprints - all the combinators have comments and every wire is explained.
Comments?
I guess nobody will actually rebuild this 1:1 for himself, but it's proof there is a useful use case for automatic platform requests. It's working like magic. You don't configure anything on the platform. Instead, you configure demand on each planet and set proper advertisements, and whenever demand changes the platform will pick it up automatically, load the items from the proper planet, and eventually deliver to the requesting planet. Platform inventory micromanagement begone.

