Multiple cargo hubs per platform

[Executer]

TL;DR

This:

2024-11-04_22-44-31.png (823.98 KiB) Viewed 1029 times

Could become this:

2024-11-04_22-45-43.png (880.24 KiB) Viewed 1029 times

What?

It would be useful in some situations to be able to construct a second hub for receiving mats from/dropping mats to a planet.

Why?

I would like to build production space platforms around planets, taking advantage of the "free" resources of asteroids, not needing to have power wires, unique resources not available on planet, and all the other benefits of space building. Currently if you want a lot of materials arriving/leaving a platform, you need a ton of bays surrounding the single hub, while trying to maintain enough edge-space to grab/filter the mats into their respective areas. Most people do this with some form of sushi belt (myself included) but it would be nice if there was another option.

With this change, each hub would have its own logistics request system from the planet. It would allow separated item networks without having to filter everything out of one central hub into two (or more) distinct areas. It would also allow for more than one location for dropping materials down to a planet and receiving materials from a planet.

You could have one hub in a corner set up for space science, while another dedicated to just ammunition production, and so on. Each hub could still accept cargo bays, to increase their unique inventory and allow for more pods landing at the same time.

[Tinyboss]

Will probably be rejected for the same reason we can't use inserters with cargo bays--it will trivialize item routing on platforms. I would just make a chain of them connected by bulk inserters and circuit logic to equalize item counts so they act like a single huge hub.

[Executer]

An alternative would be to allow cargo bays to be built away from the hub, and have them act as their own mini-hub if you did. Able to send/receive only a single pod, with minimal storage contents.

As for chaining them together... that's already kinda what a sushi belt does. By your logic, who needs item routing when you can just dump set amounts of items onto the belt with circuit logic. Has the added benefit of you can just route the belt into any shape you want, not limited to the shape of a building.

[Tinyboss]

As for chaining them together... that's already kinda what a sushi belt does. By your logic, who needs item routing when you can just dump set amounts of items onto the belt with circuit logic. Has the added benefit of you can just route the belt into any shape you want, not limited to the shape of a building.

I've actually done what you describe, and it's fiddly, messy, and difficult to maintain. Having a single storage that multiple entities can use for input/output is just better in every way. I'm not saying that would be terrible, just that it's very close to the the thing the devs cited when rejecting inserter access to cargo bays initially.