Factorio Forums

I spent some time and created some circuit magic to allow more fine grained control over when an item can be imported/exported in Space Platform Hubs and Cargo Landing Pads.
I wish I didn't have to do this.

It's easiest to understand if you test the blueprints.
They are not big AT ALL and should be able to be incorporated into most space platforms with little to no effort.

Here are the blueprints:

Space Platform Hub:

Copy blueprint

Cargo Landing Pad

Copy blueprint

Technical Explanation

I tried to get it to work as cleanly and simply as possible. Using the least amount of combinators I could.
It uses some decider combinators and a latch to remember which items where delivered to satisfaction in the past.
ONLY when the stock of that item falls below the threshold set in the first decider combinator ("10" or "100" in my blueprints), only then will a new request be forwarded.
For exports in orbit, it will check if you setup a threshold for an export item. If it detects that item in storage and it is below the export threshold, it will retain it, so long as there is not enough of it. What that specifically means is that it - paradoxically - creates a request for that same item of amount "1". But since the item is already present, with at least 1 item (or more), it should never receive any more of that item.
But due to how the development team decided to program platform-to-platform logistics, this essentially ensures the item can never be dispatched anywhere else.

Limitations

I'm overall happy that it works, as far as I can tell. But it's very clumsy and a bit hacky. It's also not very approachable, because it's not at all intuitive where you set the lower supply threshold. On top of that you will need multiple of those circuits for each set of items with a different lower supply threshold.
And the fact that it creates requests that are "request from everywhere" in the Space Platform Hub is additionally horrible, if you also want to use Rocket silos with the "automatic requests" setting enabled.
Also this solution needlessly occupies space on space platforms that could be used for more important things.
It being required on allmost all platforms is notgreat either.
And having excess circuit networks, with multiple space platforms this can realistically go into three digits. Meaning over 100 circuit networks, that take up computing power.

Why

With the new experimental update cargo bays are used at an absurd rate, because there is no way to limit how much and how often items get exchanged between platforms. Platform-to-platform rockets are "free" but the throughput of cargo bays is not endless and shouldn't be stressed as heavily as it currently is.

Meta

I could have just programmed this for myself and been happy, that I found a way for me to work around the limitations placed upon the platform-to-platform logistics. But in actuality I want to start a conversation about the state of platform-to-platform logistics.

I have put those few circuits on almost all of my space platforms, because from my experience, if you want to have space platforms sharing items with one another the vanilla way is not sufficient, without a solution like this. And I wish the developers would take notice and implement some way to add these tresholds to the game somehow. The same thing could even be said about robo-chests, which should also work with supply thresholds in my opinion.

What do you think? Has anyone done anything similar? Are you happy with platform-to-platform logistics in it's current state? Let me know.


*edit: Added "Limitations" paragraph.
*edit2: Here is a way to do something similar with robochests, specifically supplying a rocketsilo with it's three materials, while only sending new items when one falls below 10 to the upper limit of 100 (can be modified in constant combinator). This wasn't possible until 2.1, because you could read/set values on a chest simultaneously. Copy blueprint

(sorry I haven't been able to try the blueprints yet)

I think I understand what you are doing, and this is very cool and useful in many contexts. It is essentially, "when inventory dips below the minimum, make a temporary request to be filled up to the maximum".

Is the problem this solves that transfer pods are normally sent with less than a full stack as soon as inventory dips below the requested amount? And you save cargo bay landing slots by waiting until a full stack is needed before requesting any?

IMO, logistic robots avoid this problem because they have a built-in one-robot hysteresis. If a chest is short its minimum request 1 item, the bot will bring a full load of 4 items every time (if enough items are available). As long as the maximum request (trash threshold) is higher than min+4, it is supplied with the optimal number of bots. A larger hysteresis is only needed in special scenarios, and needing circuitry is justified in those cases.

If inter-platform logistics did the same, then as long as the supplying platform has an abundance, it would send a full stack as soon as the receiving platform was short by 1, and you would have one stack worth of hysteresis automatically. You would still have the too-many-pods issue if the supplying platform was producing the requested item at a slow rate.

robot256 wrote: Tue Jul 21, 2026 6:53 pm Is the problem this solves that transfer pods are normally sent with less than a full stack as soon as inventory dips below the requested amount? And you save cargo bay landing slots by waiting until a full stack is needed before requesting any?

Essentially, yes. It's very inconsistent. Both in terms of where the items come from and how many are sent/received.
And since the basegame only allows you to set one useful request number, it limits the system in both directions.
With base requests you can never have a buffer is what that means. It seems to wait a little bit until it tries to satisfy the request again, but that time is not very long.
And you cannot set minimum dispatch sizes.
That is why with this it allows you to control both export and import limits.

The best way to improve the vanilla game would be to introduce another value in the center of the existing request interface, so you have a lower threshold, an upper threshold and a dump-if-above treshhold. (The latter could also function as a "take this stuff from me if you need it" treshold; the whole dumping seems less useful now in 2.1). And make the "minium resupply" actually apply to platform-to-platform requests, too. IMHO.

robot256 wrote: Tue Jul 21, 2026 6:53 pm IMO, logistic robots avoid this problem because they have a built-in one-robot hysteresis.

I tend to agree, when it comes to situations where you need a constant supply, that is delivered by robots. You expect a constant back and forth, because the machine should run.

But especially in my malls the problem is similar. I don't want you to bring 4 plates to my mall, just because you just crafted a single belt. There are still 96 plates inside the requester chest, we can defer a resupply to a later date.
I want you to bring them in larger batches, when supply runs low.
Maybe I am wrong, but I feel like this would make more sense, to at least be able to set it up that way without 4 combinators.