Names for rocket silos so requests can be scoped to certain silo groups

[jmillikin]

TL;DR

Rocket silos should have names (similar to train stations), and logistic requests from platforms should be able to request from specific silo names.

What?

This suggestion has two components:

• Allow rocket silos to have optional names. Multiple silos on a surface can have the same name, like train stations.
• Allow space platform requests to optionally specify a silo name. If set, only silos with that name will satisfy the request. Silos attached to a circuit network report the requests that match their names.

Why?

This makes it easier to allocate separate rocket silo capacity between bulk exports (science packs, planet-specific resources) and small-run exports (e.g. the outputs of a mall).

For example if I have a Fulgora factory that exports holmium plates in bulk to Aquilo and also has a bot mall, if a ship arrives with a request for plates then that request gets served by both sets of rocket silos, which drains my mall of holmium plates and takes up its entire silo launch capacity. I want to be able to configure the platform requests so they only get satisfied by the bulk export silos, which have their own dedicated train stations. Similarly on Vulcanus I want to export calcite and tungsten products without having them get drained out of the mall.

On Gleba I want exported bioflux to be served from specific silos that have fresh bioflux -- when bioflux is just pulled out of the general logistic network it might be quite stale. Draining the general logistic network also runs the risk of running low on bioflux-produced nutrients, which can cause sections of the factory to stall.

[neoChaos12]

While we wait for an overhaul to makes rocket logistics more train-like than logistic chest-like (requested in many forms, afaik), have you tried to play around with the logistic chest priorities? In my experience, SA makes it absolutely crucial to use buffer chests and requester chests appropriately. In your case, I would set up one or more buffer chests for the rocket silo stuff right next to the silo, fed using belts and trains (depending on throughput required) and let the mall use requester chests (with or without "request from buffer chest"). This should, ideally, make it so your bots will only pull items from the nearest buffer chest for the silo, although it might also cause the occasional item to be hauled from the silo buffer chests all the way to your mall. Using a buffer chest to collect the silo's requirements will also ensure that if your item production falls behind, your mall will get auto prioritized by your bots. Stationing a small army of bots nearby inside a bunch of roboports should also encourage the pathfinding to adopt this behaviour.

[jmillikin]

Waiting for an "overhaul" to completely change a core aspect of Space Age's logistics system doesn't seem like much of a plan -- have the devs even said they're considering such a thing?

Regarding your suggested workaround, I'm not sure I follow what you mean. Buffer chests are useful for ensuring resources have a pool near where they're going to be consumed, for cases where resources are produced slowly and transit time is a factor, but they don't change how rocket silos satisfy requests.

As a concrete example, say you've got a platform that requests 100k holmium plates and ferries them to Aquilo. You might then have 50 silos on their own logistics network, with a train station to deposit plates produced on the various small islands. When the platform arrives, the two queued up rockets in each silo send plates to the platform. Then the plates for the next shipment arrive over time while the platform is doing its delivery.

If you also have a bot mall attached to some silos, then 50k plates will be satisfied by the first batch of rockets from the main silo array, but some portion of the remaining 50k will be drained from the mall before the second batch of rockets are in launch position. Now the mall stalls out because it's got no plates, and (at least in my case) the mall's train stations aren't scaled for that kind of throughput so recovery takes a while.

[neoChaos12]

Waiting for an "overhaul" to completely change a core aspect of Space Age's logistics system doesn't seem like much of a plan -- have the devs even said they're considering such a thing?

No, I have no idea if the devs are considering it. I mentioned an overhaul here to imply that it's probably not going to happen anytime soon and that finding an alternative solution to your problem would probably make more sense.

Regarding your suggested workaround, I'm not sure I follow what you mean. Buffer chests are useful for ensuring resources have a pool near where they're going to be consumed, for cases where resources are produced slowly and transit time is a factor, but they don't change how rocket silos satisfy requests.

As a concrete example, say you've got a platform that requests 100k holmium plates and ferries them to Aquilo. You might then have 50 silos on their own logistics network, with a train station to deposit plates produced on the various small islands. When the platform arrives, the two queued up rockets in each silo send plates to the platform. Then the plates for the next shipment arrive over time while the platform is doing its delivery.

If you also have a bot mall attached to some silos, then 50k plates will be satisfied by the first batch of rockets from the main silo array, but some portion of the remaining 50k will be drained from the mall before the second batch of rockets are in launch position. Now the mall stalls out because it's got no plates, and (at least in my case) the mall's train stations aren't scaled for that kind of throughput so recovery takes a while.

So here's my point of confusion - if your base is large and organized enough that you can have separate roboport grids with train based supplies in the kind of numbers you just mentioned, surely it is trivially easy to just move your mall into its own logistics network? Or rather, isolate the rocket silo logistics network (as you mentioned) and completely circumvent this issue? I had assumed your base is small enough that separating the two logistics networks is not exactly feasible, hence leading to a prioritization issue. Requesting such a drastic change in how the rocket silos work for this seems like overkill, honestly. If I've misunderstood something, perhaps you can further clarify why having the mall in the same network is so important.

[jmillikin]

The mall and its silos are already in a separate logistics network from the bulk export silos.

To prevent the mall's silos from being used to satisfy holmium plate requests, the mall would have to be isolated from its own silos, which means every produced item needs to be transported from the mall into a requester->inserter->provider chest boundary wrapped around the edge of the silo logistics network. This gets pretty annoying, because the whole point of a bot mall is to be able to easily place ad-hoc production capacity for different items. It also means a lot of overproduction for intermediate items that might themselves be exported, because some need to be kept in the mall and some moved to the silo network just in case they get requested.


I don't consider adding names to silos and platform requests to be a drastic change.

[mmmPI]

I don't consider adding names to silos and platform requests to be a drastic change.

So if you add new silos, you need to add their name in all the platforms you have ? or by default they have no name and drain from anywhere breaking the naming scheme in use ? :/

[neoChaos12]

The mall and its silos are already in a separate logistics network from the bulk export silos.

To prevent the mall's silos from being used to satisfy holmium plate requests, the mall would have to be isolated from its own silos, which means every produced item needs to be transported from the mall into a requester->inserter->provider chest boundary wrapped around the edge of the silo logistics network. This gets pretty annoying, because the whole point of a bot mall is to be able to easily place ad-hoc production capacity for different items. It also means a lot of overproduction for intermediate items that might themselves be exported, because some need to be kept in the mall and some moved to the silo network just in case they get requested.

Ah now I get it. That's a fair point. I admit I cannot think of a better solution than to setup a combinator based system (this is actually quite easy) on the edge of your mall's logistics network that pulls in the items required by the mall silos (which now exist in a separate network) such that the mall silos always retain a full inventory. Once setup, your mall can still remain ad-hoc, assuming your mall export signal groups on your space platforms are setup to auto-sync with the combinator setup. This, I suppose, is one of those cases which Krastorio 2's tri-state roboports would've enabled easy handling of. Incidentally, this system could be extended with (e.g.) constant combinators corresponding to different planets or whatever other grouping of groups you'd like.

I don't consider adding names to silos and platform requests to be a drastic change.

I called this a drastic change because even though cosmetically it might look small, what you're requesting is that the system being used in the back-end be changed. Currently, rocket silos/landing pads seem to be using the logistics network system, effectively serving as some combination of very large requester chest with sourcing items from buffers enabled and passive provider chests. The change you're suggesting means they would instead act like train stops instead. Even if enacting the change is a single line of code, it is drastic in terms of the implications. Compare that to some softer changes discussed here that could also resolve your issue.

[jmillikin]

So if you add new silos, you need to add their name in all the platforms you have ? or by default they have no name and drain from anywhere breaking the naming scheme in use ? :/

By default silos have no names and requests have no name filter, so any unnamed platform request could be fulfilled by any unnamed silo.

If you give a silo a name (or create it with a name, via blueprint / copy-paste) then it would only fulfill platform requests with that silo name.

So if you want to expand (for example) your holmium plate launch capacity, you could copy existing holmium plate -only silos, and platforms that request holmium plates would start requesting from that new silo.

I don't consider adding names to silos and platform requests to be a drastic change.

I called this a drastic change because even though cosmetically it might look small, what you're requesting is that the system being used in the back-end be changed. Currently, rocket silos/landing pads seem to be using the logistics network system, effectively serving as some combination of very large requester chest with sourcing items from buffers enabled and passive provider chests. The change you're suggesting means they would instead act like train stops instead. Even if enacting the change is a single line of code, it is drastic in terms of the implications. Compare that to some softer changes discussed here that could also resolve your issue.

Did you link to the wrong thread? That one seems to be related to cargo landing pads, which aren't involved in the silo -> platform transit.

Regarding the relationship between silos and logistics networks, I'm not sure I follow your point. Logistics networks can be segmented by keeping their roboports separated, so a requestor chest's choice of source chests isn't the entire surface, it's scoped to a given logistics network. And logistics networks can be named, so effectively each chest is associated with a single named network.

In theory logistics network names could be used to segment platform requests instead of silo names, but silos aren't 1x1 so they can belong to multiple disjoint logistics networks, so from the perspective of segmenting silo launch capacity it seems better to also name the silos rather than treat them as simply appendages of the logistics network (as chests are).

[mmmPI]

So if you add new silos, you need to add their name in all the platforms you have ? or by default they have no name and drain from anywhere breaking the naming scheme in use ? :/

By default silos have no names and requests have no name filter, so any unnamed platform request could be fulfilled by any unnamed silo.

If you give a silo a name (or create it with a name, via blueprint / copy-paste) then it would only fulfill platform requests with that silo name.

So if you want to expand (for example) your holmium plate launch capacity, you could copy existing holmium plate -only silos, and platforms that request holmium plates would start requesting from that new silo.

If i add a silo with no name, it will be prevented to launch holmium because there may exist somewhere in the map some silo for holmium plate ? or will it send holmium still ? ( draining the wrong area potentially).

[Muche]

Would having two silo groups - automatic and manual be enough?
Then a platform's cargo request could have a tri-state toggle - from all silos (default), only from manual, only from automatic.

[jmillikin]

If i add a silo with no name, it will be prevented to launch holmium because there may exist somewhere in the map some silo for holmium plate ? or will it send holmium still ? ( draining the wrong area potentially).

If you add a silo with no name, it will be used for platform requests that don't have a name.

So if you have one platform for Fulgora -> Aquilo that requests 100k from silos named "bulk holmium", and a second platform that requests 1k from unnamed silos, building an unnamed silo in your mall would cause that silo to satisfy the second platform's requests, but not the first's.

Would having two silo groups - automatic and manual be enough?
Then a platform's cargo request could have a tri-state toggle - from all silos (default), only from manual, only from automatic.

That would work for my base (since I use manual loading for bulk exports), but people who make more use of logistics bots would probably find it a bit frustrating.

[mmmPI]

If i add a silo with no name, it will be prevented to launch holmium because there may exist somewhere in the map some silo for holmium plate ? or will it send holmium still ? ( draining the wrong area potentially).

If you add a silo with no name, it will be used for platform requests that don't have a name.

So if you have one platform for Fulgora -> Aquilo that requests 100k from silos named "bulk holmium", and a second platform that requests 1k from unnamed silos, building an unnamed silo in your mall would cause that silo to satisfy the second platform's requests, but not the first's.

Ok i think i understand better the problem i see here. This suggestion to me means that you are using logistic bot to fill in the silos directly, and as such you don't get to control what gets put in. And you want to use names to scope certain request to certain silo. But you can already do that if you use requester chest next to the silo, and configure their request to match what the platform wants.

ie : if your platform request 100K holmium => some requester chest are active, and request holmium for "bulk". If your platform request only 1K holmium, => other requester chest are active, and request holmium for different purpose.

Now if you give names to silo, but they are in the same logistic network/location, if you have the 100K or 1K platform request that arrives, sure you will use different silo, but they will take holmium from the same network. The fact that you give them name serve little purpose related to the use case mentionned : "preventing the mall to be drained ".

It would only work if the silo are in different logistic area/ receive holmium from a different source. But if that is the case, then you don't need naming scheme to activate one group or another based on the quantity requested i think.

[jmillikin]

... no, I'm not trying to allocate requests according to the outstanding number of items. I want platforms that perform bulk export to pull items from one pool of silos, without pulling items out of other silos that are associated with logistics networks that happen to contain that item.

Attached are screenshots of a schematic base that has belt-fed silos for bulk export (logistic network #1) and a bot mall with attached silo for ad-hoc requests (logistic network #2). I want my Fulgora -> Aquilo platform to pull holmium plates only from the bulk export silos.

[mmmPI]

... no, I'm not trying to allocate requests according to the outstanding number of items. I want platforms that perform bulk export to pull items from one pool of silos, without pulling items out of other silos that are associated with logistics networks that happen to contain that item.

Attached are screenshots of a schematic base that has belt-fed silos for bulk export (logistic network #1) and a bot mall with attached silo for ad-hoc requests (logistic network #2). I want my Fulgora -> Aquilo platform to pull holmium plates only from the bulk export silos.

You COULD read the pending request, to activate either the logistic chest feeding the group of "bulk silo" or the logi chest feeding the "mall's silo". This is already possible in game as i tried to explain.

Maybe it's easier to understand if you think of deactivating the mall almost everytime, except when it receive a request, say 1 piece of legendary wood. This way the bulk silo gets all the work all the time, except when a platform explicitly request a legendary piece of wood, and other things, since a piece of wood is requested, all the bulk silo are not fed, only the mall silo.

You don't have to do it this way, you can also "deactivate the request from the logistic chest feeding the mall's silo" when any request is above 1000. This way they would stay available for small quantity.

I don't think it's wrong to say that "Adding naming for silo would only work if they are also already in different logistic network", and if you made the effort to put them in different logistic network already, you're not far away from not even needing to use name to control which ones are active.

[jmillikin]

I sympathize with the instinct to think of a solution in the fastest possible time, but before posting such a solution you may want to spend thirty seconds or so to double-check that your suggestion actually solves the problem (vs solving an unrelated and simpler problem).

If you're having trouble understanding what the original problem is, then you might try building a quick mockup in the map editor to try playing around with.

[mmmPI]

I sympathize with the instinct to think of a solution in the fastest possible time, but before posting such a solution you may want to spend thirty seconds or so to double-check that your suggestion actually solves the problem (vs solving an unrelated and simpler problem).

If you're having trouble understanding what the original problem is, then you might try building a quick mockup in the map editor to try playing around with.

Thank you, i thought i was just mentionning some known setup. I had hard time understanding why you'd want to have a mall that is undersuppplied when you have the material available in bulk. But i am positive it is possible to achieve in game, if you want some silo to be turned off most of the time except for certains platforms.

I also think the suggestion is one of many variants that players propose and it's not the one that make the more sense to me by far.

[neoChaos12]

Did you link to the wrong thread? That one seems to be related to cargo landing pads, which aren't involved in the silo -> platform transit.

No, I was just in a rush and failed to properly explain what I was thinking. I was referring to the suggestion of allowing us to select the behaviour of a landing pad in the logistics network (requester, buffer, etc.). This change could also be directly applied to the rocket silos and could also alleviate your issue. Currently, rocket silos (in the context of a planet-wide logistics network) are fixed to have the highest request priority with no option for users to change this. An option to alter the priority, e.g. by changing them to (highest priority) buffer chests, would've easily resolved your issue by allowing you to use requester chests for your mall instead.

Regarding the relationship between silos and logistics networks, I'm not sure I follow your point. Logistics networks can be segmented by keeping their roboports separated, so a requestor chest's choice of source chests isn't the entire surface, it's scoped to a given logistics network. And logistics networks can be named, so effectively each chest is associated with a single named network.

In theory logistics network names could be used to segment platform requests instead of silo names, but silos aren't 1x1 so they can belong to multiple disjoint logistics networks, so from the perspective of segmenting silo launch capacity it seems better to also name the silos rather than treat them as simply appendages of the logistics network (as chests are).

You're correct about how named logistics networks and requester chests work. At the same time, I hadn't even considered something you just mentioned - rocket silos aren't 1x1! I actually haven't played around with this at all and have no idea how that interaction works. My point was referring to the back-end algorithm used to determine sink-priorities for resource distribution. I do not know how the actual code works, but my best estimate is that the rocket silos and landing pad belong to a single planet-wide network that is by default assigned a higher/lower (silo vs pad) priority than any other local logistics network, named or not. Simply naming a rocket silo won't change this prioritization scheme. What is needed is a way to determine a silo's priority for distribution across all requesters. The network a chest belongs to only limits the scope, which could be used to determine priority but they're two distinct mechanisms. How exactly Factorio handles these two mechanisms and their interactions is unknown to me. This distinction was unimportant until space age since it was impossible to have a single node (requester, buffer, etc.) in the graph belong to two different scopes (local logistics network vs planetary network). Of course, I don't know if this is how the devs actually implemented it, but it's just my best guess.

The wording of your original suggestion made me think that the only way to implement it would be if instead of acting as part of a global logistics network, the silos and pods (since they're really two sides of the same coin) will need to act as railway stations instead (a role which is currently played by the planets themselves) in terms of the algorithm used for determining resource distribution priorities.

[neoChaos12]

This problem is one I insist on trying to solve for some reason lol
Here's a quick mock-up of the idea with combinators that I suggested earlier:

1. Zoomed out view of the roboports/silo setup

20250210033853_1.jpg (346.89 KiB) Viewed 63 times

2. Zoomed in view of the intersection point

20250210034121_1.jpg (229.71 KiB) Viewed 63 times

3. Blueprint for the combinator setup:

0eNrFVVFvozAM/i95DpNgQFce7o9UVRTAjGiQcEnorqr47+cEmnIdm3aVTtcXTGJ//vzZLhdSdiMMWkhLigsRlZKGFIcLMeJV8s6dSd4DKYgZS2O5FUqSiRIha/hFiniiG641VKIGHVWqL4XkVulVSDIdKQFphRUwp/IvZybHvgSNmPSKw7WwbQ9WVGsoSgZlhCeCKR2J/Cmj5EyKKMM0WIHVqmMltPwk0B+dbkAMr2sfbNxFI7Sx7FaAPQ8u8UloO+JJYDJ7RMCr1pViwMH8fZwaQM8SFiRCLzXaYXwg/5o2k2DflX7z9WioSdHwzgAlrxoAE1k9wj3ljzHOK4R4gAl/9ENzkkBJw88RjHVtbvG50ZZdaMvTZ42phK5GYVmvamCqYSuBcAyut6FnDCQvu1Ajgi4sWCM6pOLrwUqX/uJshTnFobOam5ZJZdmVeyg8wGjVs3JsGo/lpdsQ4fk2oZjqBNGg1Wme+E+k2K+l2EBMA2I5dm+RkAY01rOB9PKnqLXQc7l4lXytsQZes5bjEDgvJGCu1V89/KV3c/1wqm1QzegXa76xmzPb5LtsF9C7PV2/HR5eWyQ6cO2JFuQHcTMxb+D9X9638Kbj5obkD+kT/399/o0cO7rxAdlYkEUGz+IdZXAcDjGNaUafjxSthOY0XawdTbz1jHaMVorPzJ9lGLHzZ/liIZ6w0LvVCl86Sk644D59lif7dL/Psix+SfN0mn4DFv1uRw==

Copy blueprint

The idea is that at the intersection of two disjoint logistics networks sit a (single or series of) pair(s) of requester and provider chests. Two roboports on the silo side read the logistic network contents and the logistic requests from the silo side into the red and green wires respectively. The requester on the mall side of the intersection has its requests set based on subtracting from the green wire (the silo requests):
1. logistic network contents (positive values on the red wire)
2. stuff being carried by bots (negative values on the red wire)
3. stuff being held by the bulk inserter at the intersection point (read into a different green wire)

This can be easily extend to multiple requester/provider chests along the intersection with a little combinator magic (and maybe some dynamic insert filters) to prevent duplicate requests across requester chests on the mall side. Theoretically, this means that you don't even need a constant combinator that syncs with your space platforms using signal groups.
Caution: I haven't tested it extensively yet.

Edit: I forgot to test the setup with an active space platform making requests. Apparently, those don't automatically show up in the local logistics network's requests and needs to be explicitly read by connecting the rocket silo and setting it to "read orbital requests". Just put those into the green wire instead of/alongside the local logistics network's requests.