Space platform requests set by circuits should not default to "All"

[nzer]

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.

[Franhell]

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

• Set requests

• Send to platform

• Request from planet [Signal]

• Request from platform [Signal]

Then I could maintain different circuits for requests I'll take from the planet and requests I'll take from other platforms.

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

[macdjord]

+1

[DK_]

+1

[worph]

+infinity

It would help if we could wire up cargo bays.

[blushies]

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.

[berggen]

+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.

[NauticalInsanity]

+1 To this suggestion

I think the simplest UX is for the circuit configuration menu of the platform to offer a "pick one" of ["Request from Planet", "Request from Platforms", "Request from All"].

[blushies]

+1 To this suggestion

I think the simplest UX is for the circuit configuration menu of the platform to offer a "pick one" of ["Request from Planet", "Request from Platforms", "Request from All"].

I like this idea

[TV4Fun]

+1, having it default to all really limits what you can tell your platforms to do.

[blushies]

+1 To this suggestion

I think the simplest UX is for the circuit configuration menu of the platform to offer a "pick one" of ["Request from Planet", "Request from Platforms", "Request from All"].

I like this idea

Thought about this more again today, and this actually doesn't work for me. My hubs both import from planets and provide to platforms, so locking it to one breaks that concept.

For me, it'd really be ideal if the logistics groups in the ship UI could be turned on/off based on a circuit condition. Typical <circuit signal> <operator> <value> UI

[Amarula]

A space platform is 'smart' enough not to export items to a planet where it is importing that item from that planet, even if the import is zero. What if landing pads and rocket silos on a surface got the same smarts? So if a landing pad is requesting an item, even if it is zero of that item, none of the silos on the planet will export it?
Instead of needing the platform to know where the item is coming from, make the planet smart enough to know it isn't coming from the planet, they have to get it from another platform.

[Alfonse215]

A space platform is 'smart' enough not to export items to a planet where it is importing that item from that planet, even if the import is zero. What if landing pads and rocket silos on a surface got the same smarts? So if a landing pad is requesting an item, even if it is zero of that item, none of the silos on the planet will export it?

The reason space platforms need that logic is that there is only 1 storage container available to a platform. This container is responsible both for providing exports and requesting imports (and if the platform wants to use non-belt storage, this is the only option). As such, anything which a platform imports is now in theory available to be exported. So you need to make sure that if a platform imports something, it cannot be stolen away easily.

Rocket silos and cargo landing pads are different items, each with their own logic. Auto-requesting silos can only pull from a cargo landing pad if you choose to put them in the same logistic network. You didn't have to do that. If you want to curate exactly what items are available to be exported, you can do that.

Also, if a planet could not request and provide the same item, how could you have a planet that could act as a centralized repository? Pre-2.1, that was the only way to have a centralized warehouse for all planetary imports/exports.