Abstracts and Concepts for Various Potential Mods

[Yaivenov]

If you are chronically TL;DR, then this isn't the thread for you.

Here are some of the mod concepts and improvements that have popped into my head while playing KSP. I do know that some of these ideas may have already been implemented, so if you see me writing about an idea that someone else has already put into practice please tell me so I can go ahead and cross it off the list. Beyond that I'm just looking for feedback on which (if any) of these is interesting and should be looked at further and additional suggestions on how any of these ideas (or just some of your own if you like). Some of the ideas I can implement, others are a bit beyond my ken. They are not in any particular order, I just happened to write them down here and there and then compiled them all together. Anywhoo, on to the list...

Player Created Ground Stations:

My first time playing RO I didn't have the remotetech transmission sites updated, so in order to launch unmanned craft I first had to built a base control station. It was an oversized ground vehicle with six kerbals on board along with the necessary antennas to communicate with the craft. I drove it about 5 km away from the launch complex but still with line of sight to the pad. This kept the vessel outside of the loading range from whatever active rocket the player is trying to launch (assuming the player still has the stock loading distances in place). This could be parlayed into another aspect of the game where not only are you setting up satellite constellations, but you are also responsible for setting up your initial ground control stations both local (at the cosmodrome) and remote (think Alice Springs, Australia during Mercury). This is achievable easily via reducing the number of static ground stations and/or severely limiting their transmission distance and providing enough parts early in the game for the player to make their ground stations. See the RemoteTech Additions section for relevant information concerning non-Line-of-Sight radios.

Mood and Sanity:

A psych or "sanity" state for the kerbals as part of the life support system. Sanity being affected by things such as living conditions, enviroment, overall duration in a given enviroment type (no "change in scenery"). Factors:

Mood - As a sanity affecting factor mood is weighted more heavily, happy people don't come unhinged as fast as unhappy people. Mood in general is an amalgam of the following factors, however other special events can have an immediate and overriding impact on the Kerbal in question. For instance they might be as happy as can be under STP, but for the 5 minutes they spend hurtling through the atmosphere on re-entry they could still have a rather significant emotional event.

-- Interaction - Social critters need to social. If there are no other critters nearby to make pleasing noises with then the next best thing is calling up other critters on a communication device and making pleasing noises by remote transmission. Basically don't leave your Kerbal alone and out of radio contact for very long, you never know what kind of mischief they might get up to. Very short clock on this one. Radio communication ameliorates isolation but is an imperfect solution and only decreases the penalty.

-- Habitat Volume - How was your last airline flight? Much elbow or leg room? Want to stay in that seat for the duration of a 2 week mission? Well that was about the sum of things for the Gemini pilots. For very long duration missions you'll probably want more than a phone booth's worth of living space per 'naut. This factor is largely static and is directly based on the available crew volume in a vessel divided by crew members, perhaps done non-linearly. Two 'nauts might have to share the extra space, but at least it's still extra space so it isn't just a straight division.

-- Diet - Luxury or specialty food items selected by astronauts on the ISS are used to break up the monotany of the available food stuffs on board. I imagine a Kerbal equivalent would be a "Mint Dessert" to break up the constant snackage. MD are prepackaged in single serving units and the Kerbonauts would be "instructed" by ground control to "open science mission package 327b and execute contained instructions..." which naturally would be "Eat me." with an appropriate number of MD cakes (cake (mint dessert type), one (1x) per) would be consumed giving the 'nauts an appropriate boost to mood and will also reset a "snack clock". At first the diet will have a net positive affect on sanity, however after a period of time (as the snack clock climbs) it will decrease, flatten out for a while, and then begin negatively impacting the sanity. As mentioned this can be reset with the application of suitable luxury food items.

-- Gravity - Major mood killer if you can't get out of your rack because Eve's gravity has you pinned to the matress like a cat to a car window. Low/no gravity can be initially very fun and a mood boost, but will gradually slide to slightly negative in zero-G as the physiological effects begin to take their toll. A centrifuge habitat can be used to raise it up to just a neutral effect. Heavy gravity is immediately fatiguing and so is an immediate and constant negative effect to mood.

-- Duration - How long has the 'naut been away from home, and also how long have they been in a given biome? Overall duration starts neutral and then eventually evolves to negative both in mood and in a slow but cummulatively relevant direct affect on sanity. The closer the local environment is to home, the slower this clock runs. Time in a given biome starts out with a positive boost to mood, and a slightly positive direct affect on sanity and then progresses to neutral and flattens there as the local scenery becomes common.

-- Distractions - Food for the eyes and mind. New movies, messages, pictures. Anything novel and interesting that can be digitized and delivered at 2.4GKz. Behavior similar to the desserts for diet but gives a slightly longer (but less intense) mood boost and also a direct positive sanity increase if the distraction is emotionally significant for the 'naut (letters from family, etc.)

-- The practical effects of mood and sanity states could be displayed in a cross-grid, and possibly include spontaneous transmissions, varying levels of command compliance, positive/negative effect on craft and systems, et alii.

Integration of Craft Parts Into Avionics Mods:

In short limiting the information available to the player via MechJeb (or others) while in flight based on the available onboard (or offboard) hardware. As an example, MechJeb not being able to display the local temperatures without an on-board thermometer. Perhaps certain higher order maneuver planning is unable to be performed with the on board craft hardware and instead you need a radio link back to mission control where the ground based super computers can chew on the problem for you.

Other aspects would include integrating other mods together, such as the KerbalGPS system with RemoteTech and Mechjeb. Early hardware may prove insufficient for accurately plotting the ship's trajectory out beyond a certain distance and so instead of a nice orbital line being displayed the player instead sees an ever expanding cone from their current position to the point where the plot just ends because it has become excessively inaccurate.

Ablation Resource for Engines and Regenerative Cooling Failure:

Inspired the cooling selection mod but primarily for those using RO or similar engine mods that already make large distinctions between fuel types and engine hardware. Add the ablation resource to ablatively cooled engines in much the same manner as for command pods thus giving them a very much finite run life. This could be the single major limiting factor in the reused of hypergol engines that are otherwise not restart-limited.

On the other side for regeneratively cooled engines, perhaps some catastrophic failure (due to rapid and extreme overheating, so technically the failure bit is already in game, we just need a way to activate it in particular situations) if the engines are run to propellant exhaustion and thus are deprived of coolant flow through the engine prior to flame out. So the player would either need to balance the tankage to be a little coolant heavy (so the engine flames out before losing coolant flow, assuming only one of the bi/tripropellants is used in cooling, not an available strategy for monopropellant engines like NTR's) or shut down and/or stage before total propellant/coolant exhaustion (probably the better idea).

Additions for SmartStage Mod:

Additional triggering parameters such as G-load, unifying the different parts into a single part with menu selectable triggering parameters (and attendant texture change to match), and perhaps allowing remote placement such as putting a tank resource Smartpart in the interstage IU and then just telling it which tank to monitor.

Additions for RealismOverhaul Mod: If the improvement is specific to another mod RO alters that mod is listed in italics and underscored.

-- Being able to switch from the day 0 Julian-style calendar currently in game to the more familiar and thus intuitive Gregorian Calendar.

-- Control Moment Gyroscopes of various gimballing function as a later upgrade from the basic (and extremely low torque) Reaction Wheels. In practical application this means just making a heavier reaction wheel module part with stronger torque.

-- A change to the saturation of reaction wheels, instead of having a torque consumable resource that slowly regenerates they could display the current reaction wheel speed and also its maximum and minimum speeds. As the reaction wheel does work it will be gradually speeding up or slowing down the wheel as needed and once it reaches the limit of its speed range it is no longer able to provide torque in that direction. At that point the player can execute a desaturation burn using the onboard RCS engines and thus "reset" all the momentum wheels back to their starting speeds.

Single reaction wheel/single gimbal CMG's to start with. Low mass, placeable as the player desires, and only able to affect a single axis of rotation (based on their mounted orientation). Combo units to follow after unlocking higher tech nodes. Single gimbal CMG's provide better torque, but you'll need more of them combared to a multi-gimbal CMG.

-- Flow limits on propellant lines. If you're feeding a big engine from another tank via a fuel line it would need to be sized up (and thus also it's mass) as appropriate to permit the volume necessary to run the engine. The size of the fuel line/utility tunnel would also affect the rate of resource transfer from one area of the ship to another if it is channeled through such a bottle neck. Flow rate from balloon tanks limited by the rate of tank pressurization (can't let the structure collapse because we're sucking the propellant out of it faster than the pressurization system can manage, this could induce players to choosing heavier tank types if they're feeding big engines or using tankage in a mass/volume restricted application.)

-- Treating electrical charge like any other resource and requiring the appropriate resource connections to channel it around resource break points (decouplers) and the like.

-- TAC Life Support - Resource consumption rate documentation so space craft can be appropriately designed for specific missions and duration (I'm looking at doing an RO config for Universal Storage and will likely be looking up this particular information on my own and can probably just release whatever notes I write down for that purpose.)

-- TAC LS - Cabin CO2 needs to changed so it's displayed as a percentage of the cabin atmosphere, and not an alterable resource (you can't magically reallocate the CO2 out of the air in the cabin without either a chemical scrubber or atmospheric fractioning equipment, which would be heavy). CO2 needs to be constantly and immediately scrubbed so the CO2 absorbers need to be planned to last the entire mission. Any build up in the crew cabin would be detrimental to their health. CO2 gauge should be from 0.00% to 1.50% (or whatever is considered lethal). Kerbal suits should have their own built in systems and crew should be able to get into their suits if the spaceship life support isn't working (this idea is repeated below as it would be appropriate in a non-RO game as well).

-- TAC LS - "Life support" electricity should be broken down into detail so that select technology upgrades can be implemented and cause the astronauts to use less through more efficient lighting/heating/cooling. Crew capsules should also be temperature controlled, which would require greater amounts of electricity if the craft isn't setup to handle its own waste heat efficiently (radiators, etc., more energy used if you have to use a lot of heat pumps to move the waste heat somewhere else to be radiated, so on) Apparently already does this.

-- TAC Fuel Balancer - Should not be able to randomly dump certain resources (such as solid waste). Also needed are persistent settings per craft resource so that the tankage and such can be set up to operate in a specific manner (such as drawing RCS fuel from earlier stages so you don't inadvertently drain the tanks for your reentry control earlier in the mission) and the ability set them while still in the VAB/SPH. This second aspect would be beneficial for TAC FB in general, and not just in RO, and is repeated farther down for that reason.

-- Landing hazards presented by residual toxic resources on board, ergo, the necessity of dumping your remaining RCS propellants and what not before touching down on the ground. Failure to do so would render the craft "toxic" and subject to a long and possibly costly reclamation process (basically a cool down timer and a cost penalty before you can recover the craft, the crew on board could still button up their space suits, get out and go get picked up on their own so they don't die from starvation and the like while the timer is still going.) Heat hazards after reentry might also be a consideration.

-- RemoteTech - Remote operations center (ie. any ship with six kerbals and a radio) kerbal skill requirement (ie. 3 engineers, 2 scientists and 1 pilot for a remote station, and a needed XP level for each). Perhaps a new type of kerbal, the support Technician necessary for certain things.

-- More RemoteTech - Directional antennas that need to be pointed at the target. Some with auto-tracking (similar to solar panel sun tracking, but oriented to the designated target) others without either need the spacecraft to point at the target (Voyager, New Horizons, etc.) or some other mechanism (Infernal Robotics?).

-- MOAR RemoteTech!! - Different radio bands, some that do atmospheric bounce and scattering to allow non-Line-of-Sight communication on a planet without relays (void where prohibited and/or lacking an ionosphere and troposphere), and their associated propagation effects, transmitter power requirements (user adjustable on the fly, why put out enough RF wattage to reach Pluto when you only need to talk to Mars right now?), receiver sensitivity.

-- Multistage Engine Start Up and Operation: spin up turbomachinery first via compressed gas or gas generator, when the pumps are "at speed" or the propellant lines read a certain pressure available then open the fuel valves to the injector and activate the ignitor system if seperate (the H-1 engine bled off gasses from the solid rocket motor gas generator that spun up the pumps and used it to also ignite the combustion chamber). On/off status should be independant of throttle setting and require a deliberate action (shutting the propellant valves). Some issues with start-limited engines in the KSP game are there are instances where the game may either bug out momentarily setting throttle to 0 and then back to the previous setting and there are instances with mechjeb (such as switching off the launch guidance while still in powered flight) that will also change the throttle setting and interfere with proper operation and often cause a failed launch. The game "hiccups" can be resolved by allowing the automatic re-ignition and continuation of an engine that is already at speed (pump wise) and temperature (combustion chamber wise).

Being able to build an appropriate IU (Instrumentation Unit) for the different stages. Almost possible currently with smart parts. Being able to add additional tanks of high pressure helium and/or TEA/TEB to change the number of times an engine could be restarted. The Saturn V S-2 engines (five J-2's) only needed to light once, versus the S-IVB's engine (also a J-2) would need to be able to start at least twice. This will let players further tailor their rockets to their own designs.

-- Stage System Overhaul: Any command that could otherwise be placed into an action group can be optionally placed into the staging queue. Each "stage" can be broken down and different parts can be assigned different times of action to be executed as a stage. Example:

Stage 1 (launching)

T+0 seconds = fire gas generators starting turbomachinery for engines.

T+6 seconds = open fuel valves to combustion chamber.

T+6 seconds = activate ignitor.

T+10 seconds = after achieving full thrust (not an instant thing in real engines), release launch clamps.

T+n seconds = close fuel valves to turbomachinery and allow to spin down on own, thrust drops off gradually.

T+n+5 seconds = initiate staging

-- Procedural Parts - Different battery chemistry and break-down (loss of capacity) over time. Disposable vs. rechargeable, varying capacities vs. weights and so on.

-- Virtual Parts - Flight hardware that can be incorporated into crewed capsules and takes up a set amount of internal volume, such as the on board CO2 scrubber, radio transceivers, various flight instrumentation. The "parts" can be swapped out based on mission needs, upgraded for ability and miniaturization. On-board parts will also affect what flight information is available to the player via MechJeb and the like. Some other example parts include a radar altimeter (which gives you an exact true altitude) a barometric altimeter (which gives you a mostly accurate sea level altitude, but only if you're in an atmosphere to measure), a star tracker (which tells you where you are in space), attitude gyroscopes, a non-resetting mission clock (that basically just records how long that particular capsule part has been in use and doesn't get reset by things like docking and undocking) and the list just goes on and on with the only real limit being player desire for how far they want to take it. Capsules and probes would have a set internal volume for flight hardware as distinct from the volume set aside for tankage with realfuels. Excess hardware volume could be made available for crew habitat use (note the Mood and Sanity need for habitat volume above).

Additions for MechJeb Mod:

Smart A.S.S. control mode that uses engine gimbal to "center" the engine thrust through the center of mass of the entire spacecraft, and to orient the navball so that prograde is parallel with the thrust vector. This should help players deal with minor craft imbalances at the later stages of flight where the issues become more and more pronounced as craft mass decreases.

Additions for FASA Launch/Umbilical Tower:

A unified common tower model from which the umbilical arms and boarding gantries are suspended from. Perhaps put it on the VAB side of the launch pad and have the tower base mounted on rail bogeys in those existing track models so it appears to be part of the roll out system and stands off from the launch pad proper. Umbilical arms and boarding gantry should be procedurally adjustable for length in order to have the reach for the larger rockets that have a wide diameter or lots of boosters at the lower stages.

Additions for TAC Fuel Balancer:

Persistent settings per craft resource so that the tankage and such can be set up to operate in a specific manner (such as drawing RCS fuel from earlier stages so you don't inadvertently drain the tanks for your reentry control earlier in the mission) and the ability set them while still in the VAB/SPH.

Additions for Procedural Parts:

Toroidal propellant tanks. Similar to the fillet cylinder, but with a hollow cavity in the middle and an "Inner Diameter" adjustment for it. Basic mounting hardware at the top where the tank attaches in the stack and with the second stack node just below it so engines and other parts can be nested inside the tank (ie. lunar ascent and descent stages for the LEM).

Additions for Kerbal Attachment System with Kerbal Inventory System:

Spacesuit change to crew inventory item that they can choose to wear (option to wear available both inside and outside the craft). Suit life support values independant from the spacecraft at all times (with the player controls to refill from ship resources.) Wear of a space suit while inside the craft will put that person's life support requirements on the suit thus giving them an option in the event of ship life support failure.

Additions for Procedural Fairings:

A "see through" mode for procedural fairings akin to the stock fairings so you don't have to pull them off (and thus break some action groups) to get at the parts underneath when setting stagings and action groups. This could be accomplished by having the fairing simply be mostly transparent and non-clickable/collidable (except for a small bit where it mounts to the support ring) while in the VAB/SPH.

Smaller/skeletonized thrust plates and cargo/interstage adapters. The adapters become excessively tall at larger sizes and being able to reduce that height (and also mass) manually would be helpful. Thrust plate load capacity (and thus overall mass, again) as an independantly adjustable setting that affects the visible thickness of the structure. Images of skeletonized thrust plate concept to follow.

Bird-cage/lattice style fairing panel for early interstage junctions. Examples can be found on the Soviet SS-8 and SS-13 missiles.

Having most of the part objects consolidated into 2 or 3 distinct parts and then use selection menus to specify and customize. Procedural fairings pieces with selections for exterior texture, interior texture, shape geometry, material selection (extra insulated, metal vs. composite, reentry tiles, etc.), a single "mounting adapter" that is selectable for Engine Thrust Plate, Cargo Mounting (specially selectable for the height of the payload mounting, depressed/flush/elevated and how much), interstage and so on.

Additions for TestFlight:

For the TestFlight mod: What about test stands that let you evaluate and develop engine reliability without risking them in flight? Test stand can be as simple as your rocket stage being mounted to extra-strong, non-releasing launch clamps that also act as the probe core for control. As an addon for KCT, you could develop engines on a test stand to reduce their dynamic failure rate (rather than flying them to do so), and then also incorporate a minimum "material defect" failure rate. To counter this you would test unique engines on the stands, verify they are good, and then install them on the rockets for use. A few special areas don't allow this though, such as the Lunar Descent Engine on the LEM. Due to the corrosive hypergol propellant and the ablative cooling it could only be fired once and allowed for no pre-testing, so while you might reduce the tech development failure rate with R&D and live fire tests you will be unable to avoid the material defect failure rate in certain cases.

Additions for Airlock:

Unable to exit the crew capsule unless it is depressurized first, can only depressurize if everyone in the capsule is suited up. Airlock code module for crew capsules large enough to support them, airlocks allow ingress/egress without depressurizing the whole capsule, but will vent an airlock's worth of oxygen to space if a scavenger pump isn't available/used. Airlock possible extra item to add to ships or stations that don't yet have one.

Existing-mod-based Parachute Parts Pack for RealChute:

A model pack of all the available (permission pending) parachute models rolled together and made available for use by the RealChute mod in order to add more variety to the game. Possibly also practical effects based on chute selection.

Other addiction for RealChute: Collision mesh (?) for parachutes so they push each other aside (and maybe deform/flatten where they contact) while deployed instead of clipping through each other.

Astro-Charting and Telescope Experiments:

A few previous mods have entertained the idea of needing to physically orient the craft so that the telescope can see things, but this could be taken a few steps further. This idea would necessitate the discovery, observation and tracking of celestial objects that have otherwise been overlooked if you wanted to be able to (accurately and/or successfully) visit them. Astronomy experiments to first discover other celestial bodies followed by plotting their orbits (repeated observations). Perhaps a system to give the player an idea of where to manually look with a telescope (using WFOV IR/Vis/UV as an example), and then repeated static sightings being calculated into orbital parameters. Already fulfilled by ResearchBodies mod (thank you Hab136 for telling me about it.)

Spacestation Purposes and Missions:

Add in practical benefits and necessities for station placement, such as you can only do certain experiments on an established (time in present orbit requirements?) spacestation orbiting a specific body at a particular altitude and also missions to expand upon already placed space stations with additional scientific, industrial, or mission payloads that expand the capability of that station.

Mass Centering Tool for the VAB/SPH:

COM centering tool for the VAB (top-down looking indicator showing vessel COM and COT relative to physical center so the player can move payloads around until properly balanced.)

Negative Buoyancy:

Buoyancy ratings for different craft/returned probes and thus a practical use for additional flotation devices to keep your water-landed craft from sinking.

Procedural Utility Tunnels:

Essentially fuel lines that can only be placed vertically (and will automatically snap the second part into vertical alignment), and which will contour themselves to the surface of the craft. Menu selections for which resources that can be passed and in which direction. Needed for controlling resource flow across staged part stacks, like from the Service Module to the Command Module, I want the service module's oxygen to feed the CM, but I don't want to just toggle crossfeed on the decoupler because I do not want the SM's fuel cells to be able to rob the CM's crew oxygen in the event of Something Badâ„¢.

Contracts and Strategies in Science-only Career Mode:

Contracts and administrator strategies should remain open and available during "science only" career playthroughs as both provided a source of science points to unlock technology (a science only career has less science points available to it than a full career, especially early on when the player is scraping together a few points here and there to unlock the initial techs).

Additionally a career mode that allows the player to act as a government agency for funding purposes could be interesting, a regular albeit fixed budget that is provided each year/month with the player able to petition for an increase in funding by putting together project presentations, tech demonstrators, etc. or suffer a decrease if they fail to show merit for continued funding. Idea is already being implemented in a couple mods. I love being able to cross things off.

Preferential Electrical Grid:

A list of all ElectricCharge consuming parts on the vessel and the option to set their priority, ie. the grid control will choose to stop powering certain systems if the on board stored electricity falls below a set threshold, or if the current load demand exceeds a certain point (imagine I turn on the radar mapping device, my power drain jumps and the grid controller reacts by switching off certain non-critical ship components so I don't drain my batteries before reaching the light side of the planet. Accurate time estimations for resource depletion.

Post-Rollout Fueling: (I've already done this and have the altered configs set aside)

In order to get around part loading lag that was destroying massive rockets in my game I would prepare them in the VAB and then drain all the main LOX/LH2/RP-1 tanks and have a few of the ground support parts (launch clamps, umbilical towers) set as resource generators. The rocket would load in with only a fraction of it's flight mass avoiding lag bug destruction, and then would spend a short while gassing up prior to flight. obviously shouldn't apply to small pre-prepared tanks like the Apollo SM's SPS hypergol tanks, RCS fuel, etc. Only modification needed was to add the resource modules to the launch clamps.

Additionally, this reduced the propellant penalty incurred while waiting for the booster engines to spin up to full thrust. Until I released the last of the launch clamps the propellant umbilical on the first stage would try to keep the tank full during start up. A kludge system I used to employ for this issue was an extra fuel tank strapped to the frame of the launch clamps with a fuel line connected to the first stage. The tank I was leaving behind would feed the engines until they were at full thrust and I broke the fuel line connection by releasing the launch clamps.

Edited August 21, 2015 by Yaivenov
Crossing stuff off the list.

[hab136]

Mood and Sanity - Kabin Kraziness, also look at KeepFit

Preferential Electrical Grid - AmpYear Power Manager, sorta

Astro-Charting and Telescope Experiments - ResearchBodies

Post-Rollout Fueling - I think Ship Manifest can do this if you're still on the pad. The launch-clamps-as-generator idea is pretty cool though. I've previously strapped fuel tanks to the launch clamps so that I could power up a jet-engine first stage and still be fully fueled on takeoff.

"Each "stage" can be broken down and different parts can be assigned different times of action to be executed as a stage." - Smart Parts has a timer that you can activate through staging. You could activate a bunch of timers in one stage, then at +5 seconds one part will fire, at +7 seconds a different part will fire, etc. The timer can then activate an action group or stage.

"Crew capsules should also be temperature controlled, which would require greater amounts of electricity if the craft isn't setup to handle its own waste heat efficiently" - my understanding is that TAC's electric usage already accounts for heating/cooling, in addition to CO2 scrubbing.

Most of these ideas as very intricate and fully into the "simulation" end of the pool (instead of the "game" end).

[Yaivenov]

Mood and Sanity - Kabin Kraziness, also look at KeepFit

Preferential Electrical Grid - AmpYear Power Manager, sorta

Astro-Charting and Telescope Experiments - ResearchBodies

Post-Rollout Fueling - I think Ship Manifest can do this if you're still on the pad. The launch-clamps-as-generator idea is pretty cool though. I've previously strapped fuel tanks to the launch clamps so that I could power up a jet-engine first stage and still be fully fueled on takeoff.

"Each "stage" can be broken down and different parts can be assigned different times of action to be executed as a stage." - Smart Parts has a timer that you can activate through staging. You could activate a bunch of timers in one stage, then at +5 seconds one part will fire, at +7 seconds a different part will fire, etc. The timer can then activate an action group or stage.

"Crew capsules should also be temperature controlled, which would require greater amounts of electricity if the craft isn't setup to handle its own waste heat efficiently" - my understanding is that TAC's electric usage already accounts for heating/cooling, in addition to CO2 scrubbing.

Most of these ideas as very intricate and fully into the "simulation" end of the pool (instead of the "game" end).

KeepFit is great for modeling the physiological changes on the body but in this case I wanted to focus on the mind. KabinKraziness seems to be in the direction I want to go but it is dependent on another mod I've already discarded (see below) and seems to be oriented around modeling the system via the resource pool rather than individual attributes tied to particular individuals.

I tried AmpYear, Fusebox and TAC Fuel Balancer. Only TACFB came close to the prioritization I desired (I could rig some fuel tanks to always want to flow in and then rig a fuel line from SM to CM to make a one-way resource route and in that manner the crew capsule always was topped off for oxygen and water) but it doesn't offer the level of control and persistence I'm looking for, and near as I can tell they all treat electricity as an ubiquitous resource not in need of wiring and thus is rather difficult to control the flow of (such as, if the power fails in the service module I want the battery backup in the command module to ONLY power the command module's life support and a few systems and nothing else, but I can't with the current system).

ResearchBodies: Outstanding! ....now I just have to figure out how to integrate it into RO.

Post-Rollout Fueling, I could also just use the TAC Fuel Balancer to click and edit the fuel back into the ship, but there is something amusing to me about the anticipation of fueling it up. As mentioned this is something that I've already found a simple solution to and implemented (launch umbilicals, bless you FASA for all you've given us) but on reflection now I think it could be expanded further: Growing cryogenic effects, boil off apparent at the junctions and vents of the rocket, frost forming over the surface of the LOX and LH2 tanks, etc.

For Staging I've been testing out smartparts and as I mentioned you darn near can make a nice IU using them, but growing part count will always be an issue. Just spitballing here but lets say that's between 6 and 10 smartparts per stage to handle all the timing issues, that's between 18 and 30 extra parts just for a three stage deal. Even with that set aside there is still the desire to be able to remove things from the staging list so it can not be inadvertently activated and the like.

TACLS - Thanks for that info, I was playing around with watching power drain via AmpYear earlier and I wasn't able to discern any changes as the spacecraft proceeded through different environmental regimes. I'll just tentatively scratch this one off the list then.

And yeah, that's why I tried to split the ideas between RO specific and those that I thought could help flavor (mostly) stock games.

[Laie]

-- Being able to switch from the day 0 Julian-style calendar currently in game to the more familiar and thus intuitive Gregorian Calendar.

It should be possible to set an epoch and starting date so that you do, in fact, begin in 1950. However, KSP doesn't know about leap years. So the calendar may look familiar, but it will soon be off. That would set a trap for people who don't know about this quirk and start planning missions from real-life documents -- IMO it's better that the date is obviously, visibly off.

[Yaivenov]

It should be possible to set an epoch and starting date so that you do, in fact, begin in 1950. However, KSP doesn't know about leap years. So the calendar may look familiar, but it will soon be off. That would set a trap for people who don't know about this quirk and start planning missions from real-life documents -- IMO it's better that the date is obviously, visibly off.

I would imagine a Gregorian calendar mod would secretly be operating off the day zero Julian date that already exists. The player just gets to choose an arbitrary start point and the mod could calculate out and display the "correct" G-date as extrapolated from the starting point and the elapsed J-date. The progression of time remains mathematically correct for the purposes of the game, but is just displayed differently on the player's end, much in the same manner as the changing of your speed display from m/s to MPH.

Edited August 22, 2015 by Yaivenov
Typos will be the death of me...

[hab136]

Only TACFB came close to the prioritization I desired (I could rig some fuel tanks to always want to flow in and then rig a fuel line from SM to CM to make a one-way resource route and in that manner the crew capsule always was topped off for oxygen and water) but it doesn't offer the level of control and persistence I'm looking for, and near as I can tell they all treat electricity as an ubiquitous resource not in need of wiring and thus is rather difficult to control the flow of (such as, if the power fails in the service module I want the battery backup in the command module to ONLY power the command module's life support and a few systems and nothing else, but I can't with the current system).

For topping off things, I use GPOSpeedPump (a continutation of GoodSpeed Fuel Pump).

For example, I set my station's Life Support parts to pump level 15 (out of 16), then my lander to level 4. Any time it docks, it automatically refills. If I need to dump life support for some reason (for example a capsule returning to Kerbin), I set it to level 16 which flows to everywhere else on the station.

For waste, I do the reverse. The station's waste container is set to level 1, and my lander's waste container is set to level 4. My lander then empties waste every time it docks, automatically. On returning capsules, I set the pump level to zero, and let it fill up with waste before returning to Kerbin.

The best part is you can set the pump levels (and options of what to pump) in the editor before launch, or during flight, and they persist forever.

The above works for separate parts, but since pods have supplies+waste, I have to set the pump level to zero, let it fill up with all resources, then set the pump options to only pump food/water/oxygen, then set the pump level to 16. Result: pod full of waste and no food/water/oxygen. By default TACLS lets Kerbals survive for 2 hours without supplies, which is plenty of time to deorbit and land from low Kerbin orbit.

By default it only pumps fuel but it's easily extended to pump life support and other stuff, even electricity.

[Yaivenov]

Excellent, I'll give it a look when I get the chance.

At the moment I'm knee deep in service module fuel cells and I might end up writing up an EPS sim concept to more accurately reflect their operation.

Fun fact i just learned: when additional load is put on the FC's it causes a voltage drop at the terminals until the engine case temperature can rise in response to the increased current output and in so doing brings voltage back up to nominal. You have to increase loads slowly or buffer the system via batteries to help support the load while the fuel cells adjust. Otherwise you run the risk of an undervolt situation that could damage stuff. and the reverse holds true when unloading the system, except overvoltage is the danger, though in that direction you can take one of your FC's off the bus in order to bolster the load on the remaining active cells.

Edited August 25, 2015 by Yaivenov
Learning is fun!