Factorio Forums

What?

I would like an additional option "Set requests (logistics network)" for the cargo landing pad, where the requests are not counted against the cargo landing pad inventory but instead against the logistics network content the cargo landing pad is part of.

Why?

The goal is to ensure a given set of items is available in the local logistics network.

Intended workflow:

• define a set of items that should be present in the logistics network
• read the current logistics network content from a roboport and subtract it from the wanted set of items. You get the missing items as positive numbers.
• filter the items from other planets, for example green belts, biochambers and electromagnetic plants. Supply the filtered signals as request to the cargo landing pad.
• Current Problem: with the current behavior, if some of the wanted items are in the cargo landing pad, this is subtracted internally from the requests, so if you want 50 biochambers and have 25 in the cargo landing pad, the demand is 25. So no more biochambers are requested. But you don't want to statically request 50, because some or even all biochambers might exist in the logistics network, for example after deconstruction.
• The root cause of the issue is you don't know and cannot determine if an item is in the cargo landing pad or instead in a logistics chest and at the same time set requests for the cargo landing pad.
• a bad workaround is to trash every item from the landing pad so everything is in the logistics network and nothing in the cargo landing pad. But usually you want science packs stay and directly feed to the labs. So no trash but explicitly remove items. But you cannot do this easily, because there are 6 foreign science packs on Nauvis but the inserter blacklist allows just 5 items, so you have to trash one science pack you want to keep. And the automated trash also doesn't work, because the requests for 25 biochambers are still open!

So I'd like a "set requests (logistics network)" mode, where the cargo landing pad requests are not counted against the content of the cargo landing pad but instead against the content of the logistics network the cargo landing pad is part of. This way it doesn't matter if an item is in the cargo landing pad or in some logistics chest. The requests would always be correct and satisfied completely.

This option is also a welcomed addition to requester chests and buffer chests, because they suffer from the same issue if their requests are circuit controlled.

If this option isn't feasible for some reason, I'd like to be able to read the cargo landing pad inventory at the same time as setting its requests, so I can add this to the request, so all wanted items can be requested, no matter if some are in the landing pad or in some chest. Would achieve the same result, at the cost of more combinators. Has the same synergy with requester chests and buffer chests if these could be read and set requests at the same time.

Tertius wrote: Mon Nov 03, 2025 10:17 am If this option isn't feasible for some reason, I'd like to be able to read the cargo landing pad inventory at the same time as setting its requests, so I can add this to the request, so all wanted items can be requested, no matter if some are in the landing pad or in some chest. Would achieve the same result, at the cost of more combinators. Has the same synergy with requester chests and buffer chests if these could be read and set requests at the same time.

This seems like the best solution; I'm just worried about what behavior occurs with reading contents going into what requests are set.

crimsonarmy wrote: Mon Nov 03, 2025 11:10 am

Tertius wrote: Mon Nov 03, 2025 10:17 am If this option isn't feasible for some reason, I'd like to be able to read the cargo landing pad inventory at the same time as setting its requests, so I can add this to the request, so all wanted items can be requested, no matter if some are in the landing pad or in some chest. Would achieve the same result, at the cost of more combinators. Has the same synergy with requester chests and buffer chests if these could be read and set requests at the same time.

This seems like the best solution; I'm just worried about what behavior occurs with reading contents going into what requests are set.

As far as I see, the proposed primary solution just works. If it comes to requests, it behaves as if the cargo landing pad inventory is the whole logistics network content, not just the cargo landing pad inventory. So if you request 50 items, it doesn't matter if these 50 items are in the landing pad or in a logistics chest. You're able to make your requests more static.

You want 50 big mining drills in your logistics network? You set a request of 50 big mining drills to the landing pad. Whatever is missing from the logistics network, is being requested until there are 50 big mining drills somewhere. If you deconstruct big mining drills, they're added to the logistics network and the amount of drills requested from a platform becomes implicitly less accordingly. It's as if you added deconstructed stuff to the cargo landing pad itself, which isn't physically possible.

I don't want to change the existing options, I want a new option. May be even not an option by itself but an option with a check box:
o None
o Read requests
o Set requests
. [ ] also treat logistics network content as inventory

Tertius wrote: Mon Nov 03, 2025 11:31 am

crimsonarmy wrote: Mon Nov 03, 2025 11:10 am

Tertius wrote: Mon Nov 03, 2025 10:17 am If this option isn't feasible for some reason, I'd like to be able to read the cargo landing pad inventory at the same time as setting its requests, so I can add this to the request, so all wanted items can be requested, no matter if some are in the landing pad or in some chest. Would achieve the same result, at the cost of more combinators. Has the same synergy with requester chests and buffer chests if these could be read and set requests at the same time.

This seems like the best solution; I'm just worried about what behavior occurs with reading contents going into what requests are set.

As far as I see, the proposed primary solution just works. If it comes to requests, it behaves as if the cargo landing pad inventory is the whole logistics network content, not just the cargo landing pad inventory. So if you request 50 items, it doesn't matter if these 50 items are in the landing pad or in a logistics chest. You're able to make your requests more static.

You want 50 big mining drills in your logistics network? You set a request of 50 big mining drills to the landing pad. Whatever is missing from the logistics network, is being requested until there are 50 big mining drills somewhere. If you deconstruct big mining drills, they're added to the logistics network and the amount of drills requested from a platform becomes implicitly less accordingly. It's as if you added deconstructed stuff to the cargo landing pad itself, which isn't physically possible.

I don't want to change the existing options, I want a new option. May be even not an option by itself but an option with a check box:
o None
o Read requests
o Set requests
. [ ] also treat logistics network content as inventory

That solution doesn't feel right to me, but I don't really have a rational reason why. It is probably the best solution.