When setting a space platform's requests via circuits, the request source will be both platforms and planets, with no way to set them otherwise. This is incredibly limiting. There should be a way to limit circuit based requests to either platforms or planets, or either.
One concrete example for why this is necessary is that if it were possible to configure circuit based requests to only be fulfilled by other platforms, it would become possible to send an item from a freighter to an orbital station, then send that item from the orbital station to a different platform, by controlling the orbital station's requests via latches. This would enable hub-and-spoke logistics, which would be useful both for intra-system shipping of items like green belts and for promethium logistics at the solar system edge.
I feel like there are many forms this could take in terms of UX, whether a radio button selector for planet/platform/all, or a Set Request Source checkbox which allows passing signals for the planets or for platforms into the hub, or some other method.
Space platform requests set by circuits should not default to "All"
Moderator: ickputzdirwech
Re: Space platform requests set by circuits should not default to "All"
Couldn't agree more. The 2.1 changes are great but it makes space buffer stations very difficult to achieve.
For example if I want to keep a supply of uranium fuel cells at a space station over Gleba then the station will request all the cells I keep on Gleba before a resupply ship can make it there. Then Gleba will run out of cells and request them back from the station. They'll keep sending these back and fourth, wasting rockets, until I'm lucky and a passing ship fills the request.
I can't just keep the requests there all the time because then the platform will never share it with the planet or other platforms. If I could instead only request from platforms then I can turn off the request once I've reached my buffer and only request again when I'm running low.
I think a circuit option like what we see on splitters would be the best option. So space stations would have these options on input
It feels like the only way to achieve this at the moment is to have radars on resupply ships inform planets of what they have available so that the planets/stations can make more informed decisions. I think this is more circuitry than 99% of people are willing to do though
For example if I want to keep a supply of uranium fuel cells at a space station over Gleba then the station will request all the cells I keep on Gleba before a resupply ship can make it there. Then Gleba will run out of cells and request them back from the station. They'll keep sending these back and fourth, wasting rockets, until I'm lucky and a passing ship fills the request.
I can't just keep the requests there all the time because then the platform will never share it with the planet or other platforms. If I could instead only request from platforms then I can turn off the request once I've reached my buffer and only request again when I'm running low.
I think a circuit option like what we see on splitters would be the best option. So space stations would have these options on input
- Set requests
- Send to platform
- Request from planet [Signal]
- Request from platform [Signal]
It feels like the only way to achieve this at the moment is to have radars on resupply ships inform planets of what they have available so that the planets/stations can make more informed decisions. I think this is more circuitry than 99% of people are willing to do though
Last edited by Franhell on Mon Jul 06, 2026 7:54 am, edited 1 time in total.
Re: Space platform requests set by circuits should not default to "All"
+infinity
It would help if we could wire up cargo bays.
It would help if we could wire up cargo bays.
Re: Space platform requests set by circuits should not default to "All"
tldr: +1. Just a "circuit requests should be imported from <planet | surface>" control signal would be plenty to enable the "space buffer station" setup I'm going for.
---
Here's more details about my use case:
I'm building the buffer network in the OP: one parked hub per planet, one ship per edge, cargo relayed hub->ship->hub so it never touches the ground. A hub at an intermediate planet must request the in-transit items in order to accept them from an arriving ship. Because circuit requests are always "All", that same request is equally visible to the silos below it.
So the planet supplies its own stock as if it were transit cargo. If that planet also imports the item, it re-exports it immediately - the same item launching up and shipping out forever, burning rockets at both ends. Same root cause as Franhell's fuel cells above: a buffer has to request in order to receive, and requesting unavoidably drains the planet under it.
What would solve this:
- a signal that conveyed to the space platform "import from planet" or "import from platform" as a blanket for all signals
- constant combinator signals get the same "planet/platform/all" filters UI that space platforms get
the latter case sucks because you have to consider the case of combined signals and what filter wins. the former seems easy?
Edit:
another idea is to make it so signals on (for example) the red wire mean "import this from a planet" while green wire means "import this from a platform". both red and green could mean "import from all" as is the current heuristic. not sure if I like this idea either though.
---
Here's more details about my use case:
I'm building the buffer network in the OP: one parked hub per planet, one ship per edge, cargo relayed hub->ship->hub so it never touches the ground. A hub at an intermediate planet must request the in-transit items in order to accept them from an arriving ship. Because circuit requests are always "All", that same request is equally visible to the silos below it.
So the planet supplies its own stock as if it were transit cargo. If that planet also imports the item, it re-exports it immediately - the same item launching up and shipping out forever, burning rockets at both ends. Same root cause as Franhell's fuel cells above: a buffer has to request in order to receive, and requesting unavoidably drains the planet under it.
What would solve this:
- a signal that conveyed to the space platform "import from planet" or "import from platform" as a blanket for all signals
- constant combinator signals get the same "planet/platform/all" filters UI that space platforms get
the latter case sucks because you have to consider the case of combined signals and what filter wins. the former seems easy?
Edit:
another idea is to make it so signals on (for example) the red wire mean "import this from a planet" while green wire means "import this from a platform". both red and green could mean "import from all" as is the current heuristic. not sure if I like this idea either though.
Last edited by blushies on Mon Aug 03, 2026 5:24 pm, edited 1 time in total.
Re: Space platform requests set by circuits should not default to "All"
+1
I spent a while this weekend trying to figure out how to make a pretty obvious design work.
Let's start with the constraints I put on myself:
1) Every platform only follows one route ever.
2) Warehouse platforms and radars are allowed and encouraged.
Next, let's look at a straightforward thing to want to do: Get items from Vulcanus to Gleba or Fulgora. Let's say calcite to Gleba, and since we already have a Nauvis-Vulcanus shuttle, a Nauvis-Gleba shuttle, and a Nauvis warehouse, we'll ship the calcite through the Nauvis warehouse instead of adding a Vulcanus-Gleba shuttle.
1) Obviously we have the Nauvis-Vulcanus get calcite from Vulcanus, and deliver it to both the surface of Nauvis and to the Nauvis warehouse platform.
2) Obviously, we'll have the Nauvis warehouse request calcite from platforms only.
3) Obviously, we'll have the Nauvis-Gleba shuttle request calcite from platforms only.
Now this doesn't work. The Nauvis warehouse will not give up its calcite to the Nauvis-Gleba shuttle. The next step here is to smartly tell the warehouse when it should & shouldn't request calcite so that it will give up its stockpile. A couple of radars later, and we're in business. We have a warehouse that successfully takes from the Vulcanus shuttle and passes the supply off to the Gleba shuttle.
However, there's a big problem: The warehouse now requests from anywhere because it's circuit controlled, and we cannot stop it from grabbing calcite from the surface of Nauvis. The whole point of the system was to allow passing calcite along without extra rockets, so sending calcite back and forth between the warehouse and the surface is kinda a deal breaker.
For now, the solution I implemented was to drop any warehouse design constraints and go back to full network traversing ships. p2p transfers are still nice for allowing platforms to move excess building supplies to other platforms for free, which mitigates a huge mental burden while building ships (I know I'll use those platforms later, so now they're 'free' to send early), but I'd really like them to have good uses for transfer depots as well.
I spent a while this weekend trying to figure out how to make a pretty obvious design work.
Let's start with the constraints I put on myself:
1) Every platform only follows one route ever.
2) Warehouse platforms and radars are allowed and encouraged.
Next, let's look at a straightforward thing to want to do: Get items from Vulcanus to Gleba or Fulgora. Let's say calcite to Gleba, and since we already have a Nauvis-Vulcanus shuttle, a Nauvis-Gleba shuttle, and a Nauvis warehouse, we'll ship the calcite through the Nauvis warehouse instead of adding a Vulcanus-Gleba shuttle.
1) Obviously we have the Nauvis-Vulcanus get calcite from Vulcanus, and deliver it to both the surface of Nauvis and to the Nauvis warehouse platform.
2) Obviously, we'll have the Nauvis warehouse request calcite from platforms only.
3) Obviously, we'll have the Nauvis-Gleba shuttle request calcite from platforms only.
Now this doesn't work. The Nauvis warehouse will not give up its calcite to the Nauvis-Gleba shuttle. The next step here is to smartly tell the warehouse when it should & shouldn't request calcite so that it will give up its stockpile. A couple of radars later, and we're in business. We have a warehouse that successfully takes from the Vulcanus shuttle and passes the supply off to the Gleba shuttle.
However, there's a big problem: The warehouse now requests from anywhere because it's circuit controlled, and we cannot stop it from grabbing calcite from the surface of Nauvis. The whole point of the system was to allow passing calcite along without extra rockets, so sending calcite back and forth between the warehouse and the surface is kinda a deal breaker.
For now, the solution I implemented was to drop any warehouse design constraints and go back to full network traversing ships. p2p transfers are still nice for allowing platforms to move excess building supplies to other platforms for free, which mitigates a huge mental burden while building ships (I know I'll use those platforms later, so now they're 'free' to send early), but I'd really like them to have good uses for transfer depots as well.