just to be clear: this is somewhat solveable (as long as you have energy) by doing all calculations in combinators and then only sending signals to the platform that do not exist as items, though that makes it harder to understand platform behaviour by looking at the hub.

space platform hubs have a record number of signals going in/out, they also get another one in 2.1 (requests).

trying to get information to your platform for scheduling/triggers (for example don't fly until you have enough ammunition, or trigger a flight to nauvis when there is low fission cells ...

duplicate of viewtopic.php?t=121543

i too would love this feature, for example on gleba i want to pid-control the amount of fruit being produced, but i need to know what the maximum capacity of the belts is to do that properly.

Would it be possible to split the space platform hub circuit connections, much like combinators work?

there is a _lot_ of possible signals on that and it could get quite annoying to filter, for example you might want to connect some belts to only fly if you have enough ammunition, but not actually ...

05-31-2026, 14-54-16.png


i think this would be built slightly different, see attachment, but that would still open the question why B over D would connect while B under D would not.

i think it is possible to have a simple consistent ruleset around that, but that might then exclude a 4x4 circle ...

edit: i seem to have misunderstood your graphics. you used 4 belts to represent one belt, i did not catch that.

ok, so just to make sure we are talking about the same thing: this would be a 1x1 entity, same as existing belts

let's ignore the thing labeled "alt" that was just an additional idea, i think it is possible to do but i don't think it is necessary, or possibly even good.

your most recent reply made ...

Thanks for taking a look, but the reply is leaving me a bit confused


like if the items should be moving closer to the left edge or to the right edge (provided graphics toggle between those two),

i do not understand what this means


it creates weird cases for T-junction which would need to be ...

i made a little visualization of how it would work.

alt is an alternative mode for open belt ends, where they connect to themselves, this is not a requirement though.

as mentioned there is way less edge cases than might be expected.

for splitters the filter should probably be by lane direction ...

While they would visually not fit the current model, they could just work the same way, just with half the inputs and outputs on the other side.
filters though i am a bit unsure about, maybe they would need to take two filters?

TL;DR
Add belts with lanes going opposite directions.


What
I order of my personal preference: replace green belts by that new belt type, add a new belt type or add a modding api to for users to create that new belt type.

There is actually less edge cases than you would expect at first thought ...

We’ve identified the reason they’re taking as much CPU time as they are but we haven’t had time to work on them yet. Crashes, desyncs, and other game features not working correctly have taken priority.


hey totally understand that priorization, but just to be clear: this is almost the entire ...

thanks for providing an example, here is the original one, it still has the same issue even though vulcanus is more round.

first upload did not work out, so i deleted surfaces and blueprints, its about half the size now and the upload worked.

Space Age has somewhat bad performance on my device, so i investigated a bit.
the show-entity-time-usage debug view shows that a disproportionate amount of time is used for AsteroidCollector and SmokeWithTrigger, additionally a big amount of time is used for Inserter.
This is about SmokeWithTrigger ...