Factorio Forums

I'm trying to set up my space logistics. Whenever I do this, I hit the same problem, it's extremely hard to set things up so that I maintain a set amount of material in the planetary network, without either ending up with a large surplus or shortages. I'm clearly not the only person having issues like this, I found this post which seems to be trying to address the problems I'm hitting.

Basically, my issue is:

1. If I set a fixed request, say 50 EM plants, then my landing pad will request 50 from passing space platforms. But if my bots then take the EM plants *out* of the landing pad, but for some reason they don't get used, they will be put back into storage chests. And the hub will "top itself up" over time with more of them, even though I have 50 on the planet. This is somewhat mitigated by the fact that the landing pad seems to have a lower priority than storage chests for satisfying storage requests, but there's still a potential issue of ending up with an oversupply of possibly expensive buildings locally. Plus, it makes it necessary to have a landing pad big enough to hold everything I want to request - which can be a problem if I'm also requesting bulk items like raw materials or science.
2. If I set up circuit logic to request enough to "top up" the local network, for example requesting 50-N (where N is how many are currently in the local system) I can end up going short. For example, if I want 50, and have 25 locally, I'll set a request for 25. But if the 25 that are already in the local network are stored in the planetary hub, the request for 25 more will appear to be satisfied, and no more will be sent down.

I've tried various ways to fix this - dumping everything out of the hub immediately it's received, keeping everything *in* the hub, complex circuit logic to try to maintain between +/- 50% of the target amount, etc. None feel satisfying to me.

Does anyone have a good mechanism for managing landing pad requests? Or is the general view simply to do something simple and don't stress too much about oversupply or undersupply?

(To be clear, this feels like it's more of an early or mid-game problem. Once you get sufficiently advanced, production is not a problem, so you can just ship "lots" and not worry about waste. But earlier on, when you've just started producing things, or when you're starting out on quality and high quality items are in relatively short supply, overstocking is a real issue, and manually handling shipping is a bit of a PITA).

pf_moore wrote: Fri Oct 02, 2026 4:04 pm If I set up circuit logic to request enough to "top up" the local network, for example requesting 50-N (where N is how many are currently in the local system) I can end up going short. For example, if I want 50, and have 25 locally, I'll set a request for 25. But if the 25 that are already in the local network are stored in the planetary hub, the request for 25 more will appear to be satisfied, and no more will be sent down.

You need to take what is currently in the landing pad and add that amount to any requests you make. So if you have 10 inside the pad, 10 outside, and you want a total of 50 in the available logistic storage, then you request (50 - 20) + 10 = 40 in the pad. That will call down the 30 that you need to add.

pf_moore wrote: Fri Oct 02, 2026 4:04 pmIf I set a fixed request, say 50 EM plants, then my landing pad will request 50 from passing space platforms. But if my bots then take the EM plants *out* of the landing pad, but for some reason they don't get used, they will be put back into storage chests. And the hub will "top itself up" over time with more of them, even though I have 50 on the planet. This is somewhat mitigated by the fact that the landing pad seems to have a lower priority than storage chests for satisfying storage requests, but there's still a potential issue of ending up with an oversupply of possibly expensive buildings locally.

I always do this and I've never had a problem with it. The issue is much more theory than reality.

pf_moore wrote: Fri Oct 02, 2026 4:04 pm Plus, it makes it necessary to have a landing pad big enough to hold everything I want to request - which can be a problem if I'm also requesting bulk items like raw materials or science.

If you're requesting bulk items, then you need more cargo bays just to keep up with the drop rate of stuff. I find, especially on Nauvis, that I'm adding cargo bays for their drop rate, not their storage.

The problem has no solution in game version 2.0 except a clunky workaround where you take everything out of the cargo landing pad as soon as it arrives and set as request the difference between desired stock and logistic network inventory.

In game version 2.1 you're able to set requests and read content at the same time, so there is a solution. Lower the cargo landing pad requests by the amount of items not stored in the cargo landing pad. You're able to read the whole inventory by reading a roboport, and the landing pad inventory by reading the landing pad. The difference is what you have to subtract from the requests.

D : desired items - from constant combinator
L : logistic network inventory - from roboport
C : cargo landing pad content - from cargo landing pad
R : cargo landing pad requests - this is what we want to compute

Externally stored items: E = L - C

we want R = D - E
insert E:
R = D - (L - C)

or more easy:
R = D - L + C

so multiply the reading of a roboport with -1 to negate the value (-L), then connect the result with the constant combinator that contains the desired item stock (D) and with the readings of the landing pad (C) to add all up, and you have what you need to set as requests in the cargo landing pad.

I didn't do this yet (it's on my TODO), but it should work because L and C should increase both at the same tick when some item arrives from space, so R will not change.

Tertius wrote: Fri Oct 02, 2026 5:52 pm In game version 2.1 you're able to set requests and read content at the same time, so there is a solution.

Note that, thanks to "magic subtraction," this works in 2.0 as well. As long as you don't use the same color wire for the set and the read, the landing pad will output the current contents, not the contents + your set requests.

In 2.0 you can either set requests or read content with the cargo landing pad but not both. Only in 2.1 you can do both.

pf_moore wrote: Fri Oct 02, 2026 4:04 pm it makes it necessary to have a landing pad big enough to hold everything I want to request -

I've tried various ways to fix this - dumping everything out of the hub immediately it's received, keeping everything *in* the hub, complex circuit logic to try to maintain between +/- 50% of the target amount, etc. None feel satisfying to me.

This is confusing to me , at first i thought that if you don't want to have a big enough landing pad to hold everything, then dumping stuff immediately like in purple=>yellow chest is the solution. And you read the logistic network content from a roboport and subtract this from a constant combinator holding your desired request. ( 50 EM plant in the combinator, -34 already in the network, 16 will be requested). That will cause a constant "oversupply" because what the bots are holding isn't counted, you can keep it small by reducing the amout of time bots carry the item before they are counted as "in the logistic network" after they were dumped out of the landing pad, with compact designs. But for very small quantity yeah there is a lag between what is actually on the planet but still in the air, and what is actually registered in the logistic network to compare against the request.

But from what i understand you only want to keep "some" stuff in the landing pad like maybe quality EM plant, but "some others" like bulk iron ore shouldn't. correct ?
Problem is that then if you want 50 EM plant on the planet, but 40 are already in the landing pad and as such counted as "inside the logisitic network it makes a resulting request of "10" that will not trigger a drop from any platform because there is already more than that inside of the landing pad. correct ?

This problem can be solved minus the lag mentionned earlier but i could only demonstrate using 2.1 :

Tertius wrote: Fri Oct 02, 2026 5:52 pm so multiply the reading of a roboport with -1 to negate the value (-L), then connect the result with the constant combinator that contains the desired item stock (D) and with the readings of the landing pad (C) to add all up, and you have what you need to set as requests in the cargo landing pad.

I didn't do this yet (it's on my TODO), but it should work because L and C should increase both at the same tick when some item arrives from space, so R will not change.

That's pretty much what i did, but i'm not sure what you mean by "should increase at the same tick", to me it appears that you need to use a dummy combinator to change color wire in 2.1, which cause a 1 tick delay, but it has no consequence because it means you are 1 tick "slower" to request something after the landing pad was depleted, it's not as if it was creating a 1 tick request that you didn't want. It does work anyway

Thanks for the various replies. It looks like this is fixed in 2.1, and for 2.0 (what I'm on now) I'll just have to accept some level of compromise. As one person said, this is mostly just a theoretical issue, so it's something I can live with until I upgrade (probably not while 2.1 is experimental).