Factorio Forums

TL;DR

When a space platform request only requests items from other platforms (not planet and not all) AND has a maximum (< inf) set it currently dumps cargo to planetary hub when i think it should not.

The Topic is linked to this suggestion viewtopic.php?t=134822 as it tries to address similar issues but with a different or additional fix.

How i arrived here

I tried a simple thing: Send items by request from a Space Station to the Planet, but keep a minimum number on Station.

Example: First space station that constructs science, should supply Planetary Base with overflowing Iron but keep a reserve for continued production.
The implementation of that idea has several issues. Even in [2.0] i can either:

1. Set a space station request for Iron, but also limiting it.

   

   grafik.png (23.88 KiB) Viewed 184 times

   • I now cannot enable automatic rocket requests, because it may waste Rockets on Iron. Can be mitigated by setting min amount to 0.
   • I cannot limit Iron supply on Planet, in worst case resulting in Landingpad-Overflow
2. Set a request for iron on landing pad
   • Now i cannot guarantee space production as it may use all iron to fulfull the request
   • I cannot coordinate different space station logistic hubs with that

Using solution 1 and 2 simultaneusly has no benefit and compounds drawbacks.

Now with [2.1] arrived inter-space-platform-requests and i'm excited for a new idea:
I'll use a buffer platform like mentioned in the semi-recent FFF https://factorio.com/blog/post/fff-441

• Buffer platforms in orbit for quicker transport turn around.
• Orbital assembling of space materials (such as Space platform foundation) to save on surface rockets.

I set up everything like i imagine it should work and it does not:

1. Landing pad requests items.
2. Buffer station requests min X [no max set] of items only from other platforms. Inserters voids items to space if item_amount > X+threshold. (I would like it to enable supply of other stations for it to be also a space supply buffer, but do not as of now for simplicity)
3. Any other platform or Ship in Orbit that want's to make use of the buffer is set to request the amount of item it wants to keep as min amount from other platforms and sets the max amount upon which it dumps items to other places in the same slider. They set no planetary request for those items. They enable supply of other stations.

What i would like to happen: Any station configured to use the buffer for a certain item will keep a number of itmes [min < cargo < max] of the request set. And if the cargo exceeds max amount it should send a cargo pod with those items to the buffer station. If the landing pad has cargo < requested then the buffer station should send it's cargo down and the non-buffer stations should ignore that request if they have < min amount of requested items in their cargo bays. In other words: the condition [item in cargo < min amount requested from stations] should prevent items to be dropped to planet.

What happens instead: Any other platform that overshoots it's target just dumps it's items directly into the planetary landing pad. This is frustrating because they completely circumvent the buffer station. And will still overflow the landing pad. That will happen even if the landing pad has no request set, or if the request is set to max=0 which will dump the items into it's trash-slots.
At least i can confirm that the Buffer station will adhere to landing pad requests, even if it has that request set from other stations on itself and it's minimum requirement are not yet met. I think this works as intended, or how i think it should. [edit: after closer examination, this is not how it should work actually. As described it's exactly what i want to prevent in the other stations. With my idea the buffer station would not have a minimum number of items needed for it's purpose (buffering). It then could've been configured to request min=0, max = inf from ALL (not just platforms) and inserters start voiding at threshold for each item type to be buffered. It should then be able to also drop to planet on request.]

Current solution rant or Why this is important

The standard community (i asked in discord) solution seems to be "just use [2.0] method 1 and dump/void everything". But i would argue that is provably/empiricly wrong.

The logistic problem i describe can appear as soon as the first space platform, long before we unlock the recycler or even Fulgora itself. While space has a voiding mechanic, Nauvis does not. The only reliable way to void overflow iron would be to limit oneself to ore (not plate) requests, detect an overflow, craft ore into plate and send that up to a second space station for voiding. At that point in the game there would be no way to effectively void carbon (if collection rate > burn rate on planet).

The other community answer is "you should not be overflowing iron anyway". And i would argue that assumption of player behaviour is out of place.
If you encounter the setting as early as i described you may soon fly to another planet, and have science stall for hours while exploring other places for the first time.

The last idea would be to try to automate requests with radar networking, memory cells and SR-Latches which would be way above the giving up threshold of your average player and also does not work for it's own reasons, see the linked suggestion in TLDR segment.

What i want to establish in this section: this issue is legitimately encounterable, confusing and has as of yet no viable automationable solutions.

Where do we go from here

I acknowledge that the first naive solution would be to set seperate requests in stations for each item for planetary and space requests.
I tried that and found out that this basicly acts as an "from all" request with maximum values selected both requests min-max sliders.
I will asume that seperation of those request destinies would be technically difficult to implement.

That's why i propose this simpler fix: If a Space Platform has more items of a type than the maximum value of it's request from other stations and no planetary request for that item then exclude the landing pad from the list of valid recipients. I would like to see Stations with any request for that item with < maximum items of that type in cargo to be preferred in dumping cargo. If there are no other stations to dump to then the station should simply NOT send those items anywhere.

I appreciate what you're wanting to do here, but I don't think you're using the right tool for the job.

Essentially, what you want to do is use the hub for local storage, but if there's more than X of an item in the hub, then you want it to be made available to others who want it.

I do not believe that trashing (and requesting, for that matter) is the appropriate way to handle that.

If you trash an item, what you're saying is "get rid of this ASAP." This is not a request; it is an order. It should not be ignored, just as logistic bots cannot ignore when you trash items in your inventory. You're not trashing things to help fulfill the requests of other inventories; you're trashing things to get rid of them.

Having the failure state of trashing (ie: nobody wants it) being that the hub keeps the item is... bad.

I appreciate the insight, so i should clarify.
What you say is absolutely correct, that is why the hub (my buffer station) is using inserters to void items as failure state for this "nobody want's items" case, see picture in original post.

Essentially, what you want to do is use the hub for local storage, but if there's more than X of an item in the hub, then you want it to be made available to others who want it.

That is exactly what i want to be able to implement, and came to the conclusion that this is impossible with the current space logistics. (There is no way to conditionally enable supply of other stations, there is no way to orchestrate demand side requests without invoking planetary logistics)
I did mention this:

I would like it to enable supply of other stations for it to be also a space supply buffer, but do not as of now for simplicity

But that's only my example for how i think the game should behave in the depicted situation.

Having the failure state of trashing (ie: nobody wants it) being that the hub keeps the item is... bad.

I would argue the opposite: this behaviour would be consistent. That's exactly how your players inventory trash slots, or any other trash slots behave if there are no free logistic chests to dump to. It would also be consistent with the UI: there is only one selection for "import from" and this selection should apply to the entire request. The other interesting option would be to have a second selector "Export to" also with [planet | platform | all] options. However that would encroach feature creep territory and be less clear even tough it could arguably be a bit more useful

The current feature is: i can request from stations, but they will be emptied.
The current failure state is: planetary logistics hub overflowing.

This is not a request; it is an order.

I think this description is immaterial, the only difference is direction and guaranteed availability of material vs guaranteed space.
That's exactly where the comparison to the robot network falls apart: Space logistic currently has no buffer chests.
If i trash inventory normally i can have it immediately sorted into requests from blue green (selectively even yellow chests); thus the trash order can come with usage direction.
However that behavior is not present with space logistics: i only get to trash to the planetary logistic hub; basicly a single chest for everything.
From the FFF-blog i figure that buffer stations are indeed intended, but currently for one station to request basic materials to buffer and then sending them to another for a higher priority request is simply not feasable.

My solution solves the core problem with minimally invasive change, while not touching any other scenarios. The only negative could be that non buffer stations trash items into random stations that are not configured to reject the items. It would be an easy problem to solve, and could only occur after explicitly trying to use the feature in a way i described.

@Alfonse215 As you appreciate what i'm wanting to do here, what would be your way of handling the requirement (sending only overflow items). Do you have a current vanilla-SA method for that? If not do you have a different/better proposed change?

There is no way to conditionally enable supply of other stations, there is no way to orchestrate demand side requests without invoking planetary logistics

Of course there is. You just need to use circuit networks and interplanetary communication.

There are two cases here. One is the traditional platform->platform->platform transfers. That's done easily enough by communicating to the hub. The feeding platforms specify which items they're providing and how much of them, but they only send this information to the channel for the hub when they are in the same place as the hub. If the hub needs something, it only requests it when a feeder platform is sending a signal. And it only requests the amount it needs, up to what the feeding platform is providing.

As such, no "planetary logistics" will be invoked, since platforms can always cover them.

The case you talked about, where the platform is producing a thing for internal use *and* for external use is even simpler: if you don't want it send to other platforms, don't put it in the hub. If you need to keep 100 iron ore around for internal use, those ores should go onto belts. The extras can be split off to go to the hub via a prioritized splitter.

That's exactly how your players inventory trash slots, or any other trash slots behave if there are no free logistic chests to dump to.

But there is space to dump to. On the planet. Which is where stuff gets dumped to in space.

Or more to the point: if trashing stuff doesn't go to the planet, how can you send stuff to a planet without a landing pad? Or to send something without making a request for it (a one-time manual delivery)?

My solution solves the core problem with minimally invasive change

I don't call changing a fundamental operation of a space platform's behavior "minimally invasive". Any build which relies on trashing to send stuff to the planet stops working.

Especially now that you need a new UI to send stuff to a planet deliberately without an active request.

Or more to the point: if trashing stuff doesn't go to the planet, how can you send stuff to a planet without a landing pad? Or to send something without making a request for it

Just like before, by setting a max-value in your requests for planetary or all categories.
My proposed change explicitly only limits the dumping to planet when selecting a max value for from platform request.

What you neglect is ease of use. Your explanetion is lacking in detail. "easily enough by communicating to the hub" which hub? planetary, delivering space platform, buffer station? all of them? then you need to orchestrate though global radar, you need a system of message multiplexing, band modulation or usage locking. At least if you possibly want multiple deliveries with multiple stations. That is not "easily enough".

even simpler: if you don't want it send to other platforms, don't put it in the hub.

Now your semanticly circumventing the example i gave in order to not provide a solution for the szenario. Your second case answer boils down to "don't let it come to the situation" which is deeply unhelpful.

But there is space to dump to. On the planet.

Yes but also in the buffer station. That's why there is a buffer station.

Any build which relies on trashing to send stuff to the planet stops working.

I legitimately cannot come up with an idea on why or how to use a space platform from platform request, that then relies on overfilling and dumping to the planet ... i cannot come up with such a thing at all. Not with the current way in which these requests work. ... Did you even read the TL;DR? maybe the topic title was a bit too aggressive.

danischu wrote: Wed Sep 02, 2026 7:33 pm Just like before, by setting a max-value in your requests for planetary or all categories.
My proposed change explicitly only limits the dumping to planet when selecting a max value for from platform request.

That is now highly bespoke behavior. You want space platforms to have two sets of trash slots when every other logistic requester makes due with one.

danischu wrote: Wed Sep 02, 2026 7:33 pm What you neglect is ease of use.

Buffer platforms that act as an intermediary between a planet's surface and other platforms are "easy to use". They request from a planet and provide to platforms; there is no conflict. Centralized hub-and-spoke networks that use platform->platform->platform passages are not as easy to use.

I can live with hub-and-spoke networks requiring specialized circuit machinery. It's still very doable to make them; it's just not as simple as setting a few requests.

And I'm honestly surprised that nobody's made a blueprint book for the circuit machinery for it. It's not that hard.

danischu wrote: Wed Sep 02, 2026 7:33 pmYour explanetion is lacking in detail. "easily enough by communicating to the hub" which hub? planetary, delivering space platform, buffer station?

That's a matter of terminology overloading. You're building a hub-and-spoke model of interplanetary logistics, where each planet feeds a central "hub" platform, and all planets pull from that central "hub". Also, planets don't have a "hub"; they have a "cargo landing pad"

However, to break it down more granularity, it works like this:

There is a central repository platform; let's call it the "repo". For each planet (except for the one the repo is in orbit around), there are some number of platforms that carry exports to the repo and pull imports from the repo to take back to that planet. Let's call them "feeder platforms".

Each feeder platform has a constant combinator containing the things they want to export from their source planet to the repo. Naturally, they request those items from their source planet. But, they take their current inventory, filter it based on the constant combinator, and then send the inventory values for any matching signals through the green wire of a radar using a specific channel. However, that last step (sending the signals out) only happens if the feed platform is currently in orbit around the repo's planet.

The repo station has a constant combinator containing the same logistic group as the feeders. They look at the green wire of that radar channel. When values are on it, it checks to see if its inventory of that item exceeds the amount that it wants to store. If there is a deficit of items, then it sends the full request to the repo's hub. But once the inventory equals the request amount, the request stops being sent to the repo's hub. Any items on the radar which the platform doesn't have a request for in its constant combinator are ignored.

Let's look at an example.

Vulcanus is exporting 500 tungsten plate to the repo. There's a logistic group with 500 tungsten plate on it. The feeder platform uses that group in its internal requests to fetch the plates from Vulcanus (so the requests need to be set to request from Vulcanus). But this logistic group is also used in the constant combinator mentioned above. Therefore, when the Vulcanus feeder arrives at Nauvis (the location of the repo), it sees that it has 500 tungsten plates in inventory. Since tungsten plate is in its constant combinator, the 500 tungsten plates in its inventory are passed to the green wire of the radar (how big the request is is irrelevant; it broadcasts its entire available inventory).

The Nauvis repo sees 500 tungsten plates on the green wire. It wants 500 plates, so it requests that many from "all". This means 300 plates will be brought in. But since the Vulcanus platform is there and has more than 300 plates on it, this request will be fulfilled entirely by the Vulcanus platform. As such, any plates on Nauvis should be untouched.

Once the platform has more than 500 plates, it will detect that its inventory of plates exceeds its desired request amount, so the repo immediately stops requesting any tungsten plates. Since the repo is no longer requesting plates, any platforms who are making requests for tungsten plates from Nauvis platforms will be able to get them from the repo (or from the Vulcanus platform if it's still there, which is also fine).

But what happens if the Vulcanus feeder isn't there? Well, there are 0 tungsten plates on the green wire. Regardless of how many the platform wants, 0 are available, so it requests 0. Therefore, whatever it still has is available to any platform.