Landing Pad Redesign
Posted: Tue Feb 04, 2025 3:44 pm
Taking a look at all of the landing pad mechanics, I feel the whole things needs to be redesigned.
The major issues I see with the current design:
The one per surface limit introduced an unprecedented hard cap to logistics throughput, as you can no longer increase throughput by building in parallel.
The following image illustrated the hard-cap:
The inability to read contents as well as set requests means you can't set filters to the landing pad inserters for increased thoughput unless you are willing to set all requests manually, further reducing the throughput hard-cap.
Taking a look at the decision to use one cargo bay per surface:
From FFF-382 "it is too convenient to put them all over the place to have the imported items right where you need them"
Yes, but the lading pad is large and throughput is limited unless you make it even larger by attaching bays. Plus isn't being able to drop things out of orbit to anywhere on the surface is kind of the beauty of dropping things out of orbit?
" and in the late game, it is nice to have this one very busy logistic junction in your base"
Shouldn't a centralized planetary hub be a gameplay decision rather than a design limitation?
My proposal:
1. Remove the limitation of one pad per surface.
2. Cargo bay does not increase storage of pad, but acts as it's own storage.
3. The cargo bays should still visibly connect, but their inventories are separate. The connected bays and pad act as a single drop point selectable from the platform.
4. Read contents available separately on each bay, read contents and set request simultaniously on pad.
5. Increasing bays still increased pod rate, but the actual bay the pod lands in is random. You would need to account for potentially having items in each cargo bay.
Illustration of the throughput hard-cap removed:
Thank you for your consideration!
The major issues I see with the current design:
The one per surface limit introduced an unprecedented hard cap to logistics throughput, as you can no longer increase throughput by building in parallel.
The following image illustrated the hard-cap:
The inability to read contents as well as set requests means you can't set filters to the landing pad inserters for increased thoughput unless you are willing to set all requests manually, further reducing the throughput hard-cap.
Taking a look at the decision to use one cargo bay per surface:
From FFF-382 "it is too convenient to put them all over the place to have the imported items right where you need them"
Yes, but the lading pad is large and throughput is limited unless you make it even larger by attaching bays. Plus isn't being able to drop things out of orbit to anywhere on the surface is kind of the beauty of dropping things out of orbit?
" and in the late game, it is nice to have this one very busy logistic junction in your base"
Shouldn't a centralized planetary hub be a gameplay decision rather than a design limitation?
My proposal:
1. Remove the limitation of one pad per surface.
2. Cargo bay does not increase storage of pad, but acts as it's own storage.
3. The cargo bays should still visibly connect, but their inventories are separate. The connected bays and pad act as a single drop point selectable from the platform.
4. Read contents available separately on each bay, read contents and set request simultaniously on pad.
5. Increasing bays still increased pod rate, but the actual bay the pod lands in is random. You would need to account for potentially having items in each cargo bay.
Illustration of the throughput hard-cap removed:
Thank you for your consideration!