SolarSupremacy
New Member
- Nov 29, 2025
- 3
- 2
(Copied from this Discord suggestion.)
# Primary Suggestion Breakdown
1. Give capsules and drone cores "equipment bays". Older capsules and drone cores would have fewer equipment bays, meaning if you want to add more modules to an older-style craft, you'd have to use additional parts to support more modules.
2. These equipment bays would be used by "modules". Modules would primarily be various flight guidance systems that provide flight guidance, navigation, and autopilot capabilities. You'd unlock more (advanced) modules through research.
3. These modules would be represented *skeumorphicly* by the UI on your vessel. Before you have SAS, you wouldn't have the SAS panel. A basic SAS-supporting flight computer would have limited functionality, and therefore, limited buttons/features. The most advanced one would have full support. Likewise, adding a separate autopilot-capable flight module would add the auto-manouver panel on the UI. And so on...
# Additional Suggestions
1. If the game implements forms of life support, life support modules could be implemented, using the same equipment bays. For example, this could include an "air conditioning" module required to maintain a pressurized and oxygenated atmosphere and a "CO2 scrubber" module to allow the air conditioning module to operate without needing to wastefully bleed atmosphere to space to maintain safe CO2 levels.
2. Automation modules. This is a topic for another suggestion (several have already been posted), but simply covering: player-programmable PLCs, "KAL Controller" analogues, kOS analogues, etc.
# Purpose & Examples
There are three primary reasons that I believe this suggestion would make for good gameplay.
1. It provides players with some interesting cost-benefit analysis and soft limitations. A player could reduce the mass of their vessel by a small amount by not installing modules they won't need, or similarly, could allow the player to swap modules with ones they find more beneficial. Especially if life support is implemented, a player may consider, "do I really need a CO2 scrubber on this relatively short mission? Would it benefit me more to have an auto-land computer?" The limitation of capsules/drone cores only having a limited number of bays for modules provides this soft limitation where players consider how much they really need each module. This limitation has a simple work-around though, simply by adding additional equipment bays with extra part(s), though adding some additional weight to the craft.
2. It makes vessels more unique. Instead of the same UI and the same capabilities on every craft, each craft would *skeumorphicly* have its own unique UI representing the buttons and dials and gauges *that craft* would have based on the modules the player installed. Crafts would (if the player chooses) slowly transition from "a launch button and a navball*" to a feature-full UI of panels with various buttons for all sorts of capabilities that the player has unlocked. However, if they swapped over to an older vessel they launched back at the start of the game, it would still look as bare-bones as it did the day it launched.
\*I would even argue the first craft a player launches should have no modules whatsoever. Just a "stage" button and a prayer. That's all we really need anyway for our first launch. Strap on a small SRB and a parachute and you're good. Navballs could come with the first flight computer they unlock shortly after.
3. If modules can be swapped in-situ, it allows retrofitting of older vessels with newer tech. Or perhaps, even making modifications on the fly.
4. It gives a more mechanical feel to your vessels. Optionally, the game could provide a UI element representative of a server rack showing the modules currently installed on the vessel. Each module could have a pushbutton to power them on/off and possibly additional buttons such as "safety override" or "reset", depending on the module. It would cut down on the amount of right-click menus to configure parts by providing a skeumorphic solution *and* allow the players to reboot/reset modules if they feel the need to. For instance, a new player could have hit a bunch of buttons on the SAS panel and don't understand why they can't control the craft or why the craft is doing something strange. But, they could open the module panel, shut down the flight guidance computer/SAS module, see the UI for that module go dark, turn it back on, and see the UI for that module light up again but in its default configuration, and know whatever they did has been reset and see what the default configuration is. Even if the idea of "rebooting the flight computer" may seem wholly unnecessary, I believe it would be a great feature feeling "tactile" and giving you the idea of having full mechanical control over the systems you've installed on your vessel. Additionally, maybe you could disable modules in a low power scenario in an attempt to converse power... but that implies some/all modules having a form of power drain and that's a whole other consideration.
# Specific Breakdown Of Modules
Work in progress. To an extent, the developers may have better insight into this anyway.
# Whacky Examples To Put A Grin On Your Face
These examples are not necessarily suggestions, but ways this suggestion could create new aspects of the game and give players more opportunities to improvise solutions. The specific module(s) in question are not well thought out. These are examples I came up with on the fly to fit the specific scenario. As childish as it may seem, the idea of these examples is what makes me so excited about this suggestion post.
1. "What the heck is happening?! Is SAS configured wrong? I'm going to crash! AHHH!" The panicing player, mid-landing, unable to control their craft, remembers the one thing every "tech support scammer trying to fix their internet" says to them before they hang up the phone in frustration...
> DiD yOU tUrn it oFF and BaCk oN AgaIN?
But the player realizes... hey! Turning it off and back on again actually CAN solve your problems! So they do that. They kill the power to the flight guidance computer, turn it on again, and all of their problems (except for landing) are solved as the flight computer boots back up in its default configuration (SAS off instead of SAS on, anti-radial to surface), which the player understands and is competent enough to continue to a successful landing.
2. Maybe a player landed on the moon but their lander didn't have enough fuel to get back into orbit. If it makes the difference, they could rip out all the unnecessary modules from the capsule (as well as dump out any available cargo) in an attempt to squeeze out that extra dV they need, Mark Watney style.
...or, even wackier, they brought a rover with little jump jets on it for science/entertainment purposes. They realize the rover could provide enough of a kick to get them up to orbit, but it lacks flight guidance because they swapped out flight guidance with rover controller and rover autopilot modules as those would obviously be more useful for a purpose-built rover. They could rip out the rover guidance systems, pull the flight guidance and target-tracking modules (making these up on the fly) from their lander, bolt them in the rover's probe/cockpit, and be excited as they improvised a crazy solution to their problem in a way that feels rewarding.
3. Perhaps, with an implementation of life support, the interior of vessels are simulated to be pressurised and oxygenated, specifically considering the volume of each of the IVA-accessible areas for your Kittens. One of the life support module(s) would logically be responsible for depressurizing and repressurizing the craft (or part of the craft) when Kittens need to EVA, either with dedicated airlocks or simply by depressurizing the capsule prior to EVA. The specifics regarding the logic of airlocks are not important here. We could consider this specific module having a safeguard to not allow you to vent the internal atmosphere to space accidentally, so when you want to use an exterior door, it briefly handles depressurization for you and repressurizes once you're complete.
...now, imagine you need an emergency source of forbidden dV. You just read the previous example, saw "Mark Watney style", and know where this is going. Open up the hypothetical list of "equipment bay controls", find the module(s) responsible for pressurization and airlock controls, and either hit "safety override" or "power off". Now, there's nothing stopping you from opening that hatch and venting your entire spacecraft to vacuum with a known force vector. Forbidden dV unlocked. Perhaps you could even leave the hatch open and enable/override the air conditioning system to keep trying to pressurize the craft, giving you a trickle of propulsion as you slowly vent your oxygen tanks to space.
# Primary Suggestion Breakdown
1. Give capsules and drone cores "equipment bays". Older capsules and drone cores would have fewer equipment bays, meaning if you want to add more modules to an older-style craft, you'd have to use additional parts to support more modules.
2. These equipment bays would be used by "modules". Modules would primarily be various flight guidance systems that provide flight guidance, navigation, and autopilot capabilities. You'd unlock more (advanced) modules through research.
3. These modules would be represented *skeumorphicly* by the UI on your vessel. Before you have SAS, you wouldn't have the SAS panel. A basic SAS-supporting flight computer would have limited functionality, and therefore, limited buttons/features. The most advanced one would have full support. Likewise, adding a separate autopilot-capable flight module would add the auto-manouver panel on the UI. And so on...
# Additional Suggestions
1. If the game implements forms of life support, life support modules could be implemented, using the same equipment bays. For example, this could include an "air conditioning" module required to maintain a pressurized and oxygenated atmosphere and a "CO2 scrubber" module to allow the air conditioning module to operate without needing to wastefully bleed atmosphere to space to maintain safe CO2 levels.
2. Automation modules. This is a topic for another suggestion (several have already been posted), but simply covering: player-programmable PLCs, "KAL Controller" analogues, kOS analogues, etc.
# Purpose & Examples
There are three primary reasons that I believe this suggestion would make for good gameplay.
1. It provides players with some interesting cost-benefit analysis and soft limitations. A player could reduce the mass of their vessel by a small amount by not installing modules they won't need, or similarly, could allow the player to swap modules with ones they find more beneficial. Especially if life support is implemented, a player may consider, "do I really need a CO2 scrubber on this relatively short mission? Would it benefit me more to have an auto-land computer?" The limitation of capsules/drone cores only having a limited number of bays for modules provides this soft limitation where players consider how much they really need each module. This limitation has a simple work-around though, simply by adding additional equipment bays with extra part(s), though adding some additional weight to the craft.
2. It makes vessels more unique. Instead of the same UI and the same capabilities on every craft, each craft would *skeumorphicly* have its own unique UI representing the buttons and dials and gauges *that craft* would have based on the modules the player installed. Crafts would (if the player chooses) slowly transition from "a launch button and a navball*" to a feature-full UI of panels with various buttons for all sorts of capabilities that the player has unlocked. However, if they swapped over to an older vessel they launched back at the start of the game, it would still look as bare-bones as it did the day it launched.
\*I would even argue the first craft a player launches should have no modules whatsoever. Just a "stage" button and a prayer. That's all we really need anyway for our first launch. Strap on a small SRB and a parachute and you're good. Navballs could come with the first flight computer they unlock shortly after.
3. If modules can be swapped in-situ, it allows retrofitting of older vessels with newer tech. Or perhaps, even making modifications on the fly.
4. It gives a more mechanical feel to your vessels. Optionally, the game could provide a UI element representative of a server rack showing the modules currently installed on the vessel. Each module could have a pushbutton to power them on/off and possibly additional buttons such as "safety override" or "reset", depending on the module. It would cut down on the amount of right-click menus to configure parts by providing a skeumorphic solution *and* allow the players to reboot/reset modules if they feel the need to. For instance, a new player could have hit a bunch of buttons on the SAS panel and don't understand why they can't control the craft or why the craft is doing something strange. But, they could open the module panel, shut down the flight guidance computer/SAS module, see the UI for that module go dark, turn it back on, and see the UI for that module light up again but in its default configuration, and know whatever they did has been reset and see what the default configuration is. Even if the idea of "rebooting the flight computer" may seem wholly unnecessary, I believe it would be a great feature feeling "tactile" and giving you the idea of having full mechanical control over the systems you've installed on your vessel. Additionally, maybe you could disable modules in a low power scenario in an attempt to converse power... but that implies some/all modules having a form of power drain and that's a whole other consideration.
# Specific Breakdown Of Modules
Work in progress. To an extent, the developers may have better insight into this anyway.
# Whacky Examples To Put A Grin On Your Face
These examples are not necessarily suggestions, but ways this suggestion could create new aspects of the game and give players more opportunities to improvise solutions. The specific module(s) in question are not well thought out. These are examples I came up with on the fly to fit the specific scenario. As childish as it may seem, the idea of these examples is what makes me so excited about this suggestion post.
1. "What the heck is happening?! Is SAS configured wrong? I'm going to crash! AHHH!" The panicing player, mid-landing, unable to control their craft, remembers the one thing every "tech support scammer trying to fix their internet" says to them before they hang up the phone in frustration...
> DiD yOU tUrn it oFF and BaCk oN AgaIN?
But the player realizes... hey! Turning it off and back on again actually CAN solve your problems! So they do that. They kill the power to the flight guidance computer, turn it on again, and all of their problems (except for landing) are solved as the flight computer boots back up in its default configuration (SAS off instead of SAS on, anti-radial to surface), which the player understands and is competent enough to continue to a successful landing.
2. Maybe a player landed on the moon but their lander didn't have enough fuel to get back into orbit. If it makes the difference, they could rip out all the unnecessary modules from the capsule (as well as dump out any available cargo) in an attempt to squeeze out that extra dV they need, Mark Watney style.
...or, even wackier, they brought a rover with little jump jets on it for science/entertainment purposes. They realize the rover could provide enough of a kick to get them up to orbit, but it lacks flight guidance because they swapped out flight guidance with rover controller and rover autopilot modules as those would obviously be more useful for a purpose-built rover. They could rip out the rover guidance systems, pull the flight guidance and target-tracking modules (making these up on the fly) from their lander, bolt them in the rover's probe/cockpit, and be excited as they improvised a crazy solution to their problem in a way that feels rewarding.
3. Perhaps, with an implementation of life support, the interior of vessels are simulated to be pressurised and oxygenated, specifically considering the volume of each of the IVA-accessible areas for your Kittens. One of the life support module(s) would logically be responsible for depressurizing and repressurizing the craft (or part of the craft) when Kittens need to EVA, either with dedicated airlocks or simply by depressurizing the capsule prior to EVA. The specifics regarding the logic of airlocks are not important here. We could consider this specific module having a safeguard to not allow you to vent the internal atmosphere to space accidentally, so when you want to use an exterior door, it briefly handles depressurization for you and repressurizes once you're complete.
...now, imagine you need an emergency source of forbidden dV. You just read the previous example, saw "Mark Watney style", and know where this is going. Open up the hypothetical list of "equipment bay controls", find the module(s) responsible for pressurization and airlock controls, and either hit "safety override" or "power off". Now, there's nothing stopping you from opening that hatch and venting your entire spacecraft to vacuum with a known force vector. Forbidden dV unlocked. Perhaps you could even leave the hatch open and enable/override the air conditioning system to keep trying to pressurize the craft, giving you a trickle of propulsion as you slowly vent your oxygen tanks to space.
Upvote
1
