Life Support for Gemini needs adjusting, to match historical doc

[NathanKell]

Needs a once-over.

[stratochief66]

I hadn't noticed this post (I should look at Issues more often)

Is there currently a life support mod that is up 1.0? IIRC I used TAC in 0.90.

Does it need a once over to check for fuel volume/mass changes with CRP or to confirm it still supplies life support for the appropriate length? (Or both)

[stratochief66]

@NathanKell

I am making my fine tooth pass though FASA and am running into some issues I would like to seek a consensus on before I make any changes.

1. First off, I want to make sure I am using the right TAC version, so links would be useful. IIRC, RO comes with a config file for TACLS and I have been downloading the most recent version of TACLS from the forums.
2. Consistently craft CO2 scrubbers have been failing around 2 days because the "Waste" category fills up. In my Dev KSP setup the astronauts have failed to die at this point. Does TACLS not have a catch to kill astronauts on CO2 overload?
3. For realism purposes I would like to make the water generated by fuel cells only enter the craft supply stats on craft where the water was actually used this way. ie. In the Gemini it was not, so I would either make it appear as not generated, or add to WasteWater.
4. I want to make sure H2 is not being boiled off at the regular background temperature rate while in a service module, as the service module would be refrigerating the life support LiquidH2 supply to keep it around. I suspect I have been running into this, but I still need to do rigorous tests to confirm if this is happening. I just wanted to put the idea / challenge in your ear @NathanKell .
5. It would be good to have a standard for what ends up in Waste and WasteWater. Currently, spend LithiumHydroxide adds to Waste, which I disagree with. A spacecraft "Waste" does not fill up in two days and stop spending cartridges and then kill the astronauts. I think of it this way, a fresh LH cartridge and spent LH cartridge take up the same space, so no "waste" is generated.

In my proposed standard, only human waste would add to Waste, only human waste water would add to WasteWater. Even this is not entirely idea. Ideally for realism, there would be a TAC module for performing at least liquid waste dumps. Gemini would not have that option (IIRC?) and Apollo would.

Anybody else; thoughts or observations on life support in general would be much appreciated.

[NathanKell]

@stratochief66 you can subscribe to the repo, and thus get email notifications for issues (assuming you have email turned on for github).

1. The current version of TACLS is this. Although @taraniselsu merged my PR, there hasn't been a release since then. It seems to work fine in 1.0.4 (and I can think of no reason it would not).
2. Correct, TACLS only kills on resource absence, not resource presence. It's a deliberate design choice. Sounds like we need to revise our waste maxAmounts.
3. Makes sense to me. WasteWater sounds like the better approach, conservation of mass and all.
4. The service module has the same insulation as tanktype Cryogenic, which means boiloff should be rather low. However, I agree we need to add some kind of refrigeration system. Thankfully @toadicus has offered expertise (and willingness) on that score, so when I get a sec (heh) I'll start in on RealHeat, now with refrigeration (tm).
5. That makes sense to me, as does your proposal.

[stratochief66]

Excellent, thank you. I hope to make an easy to use tool for calculating how much resources a craft should have, with the end user able to plug in basics like kW average energy use, days of life support desired, number of crew members.

@NathanKell

These are the demand values I should be pulling from, yes? https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/ThunderAerospace/TacLifeSupport/PluginData/TacLifeSupport/LifeSupport.cfg

In particular, I would prefer if we changed:

BaseElectricityConsumptionRate = 0.2

to zero. This would make it easier for new people adapting craft to calculate and input the energy demands of a craft. Of course, having a value set might make it easier for modelling sometimes empty craft, such as early Soviet space stations. I would prefer that those base consumption values are baked in craft by craft to allow for variation, or set to a more complex formula based on crew capacity (ie. ISS base power consumption would be higher than Salyut base consumption)

[NathanKell]

Yep, that's correct. I made such a calculator in Calcs.xls but it does not account for recycling/scrubbing.

Yeah, that change is fine, although it does mean we need to add generators to everything...

[stratochief66]

Update: I have adapted the FASA capsules & service modules to work and behave well in 1.0.4 with TACLS. If anyone has an issue please let me know and I will try to address it. My goal is/was to make the FASA parts decent examples to be copy and paste-able for other LS needs.

[NathanKell]

Great! :)

[stratochief66]

I need to re-adjust the Gemini Fuel Cell stuff, based on the document Bob Fitch shared.

https://www.scribd.com/fullscreen/42019333?access_key=key-29j2c9oqo6u7ojwcvelq&allow_share=true&escape=false&view_mode=scroll

My Apollo has reasonable LH2 and LO2 amounts, but the Gemini was clearly wrong.

LH2 should be 44.88L, LOX 41.34L. The consumption and production of the Gemini fuel cell will also need adjustment to compensate unfortunately.

[RedAV8R]

Except...Gemini was available in different configurations. So while those values may be true for that particular flight. They were different for others.

Much more detailed information can be found in the Project Gemini Familiarization Manuals.

[stratochief66]

For the purpose of my work, I am simplifying to 2 configurations:

1. Battery only, something like 3 day duration
2. Fuel fells, charged with enough fuel to make a 2 week duration.

Shorter fuel cell durations can easily be simulated by putting less LH2 & LOX in the SM, but there would be some guess-timation because it will need more LO2 for breathing gas, I think. But hey, it can be done with slider bars in-game, which is a plus.

[RedAV8R]

Are we ignoring the 'realism'. If docs say 22lbs of lh2 then lets do that. We can reduce/remove boil off per tank as required.

[rogersk]

hi, Was it intended for the US_FuelCell (US_1P110) to receive that "-0.2 EC" consumption rate hit?

RealismOverhaul/GameData/RealismOverhaul/RO_SuggestedMods/UniversalStorage/RO_UniversalStorage.cfg

The cell anyway is insanely hungry and powerful. At a rate of 16ECs producing roughly 300kEC in just over 5 hours with the "packaged" fuel.

The 'standard' TAC/squad fuel cell is set by RO at just 0.75EC/s and lasts pretty much 5 days with similar sized LH/LOX tanks. Enough to sustain a Mk1 Pod for that time (also delivering a total of 300kEC).

And the US cell can not be isolated, except by hibernating the vessel/probe.

Besides, it's the only power source available in the tech tree to complete contacts until unlocking solar. all of this may be related to mix of my addons (1.0.5/ro/64/ven/tac/ctt/...)

[jwvanderbeck]

Besides, it's the only power source available in the tech tree to complete contacts until unlocking solar.

Err what? You should have batteries, and then solar panels, before you have any fuel cells.

[rogersk]

@jwvanderbeck but batteries don't satisfy "produce power" in contracts the US alkaline fuel cell is available in (my) tree in 'survivability'

anyway, that's not really the point :)

[jwvanderbeck]

Yeah you're right but solar panels do. If you are getting fuel cells in Survivability then that is an error or you are using a Non-RP0 tagged part.

Either way you are right that isn't the point in this issue, just be aware you are using an unsupported or partially supported part from the sounds of it.

[rogersk]

I don't do RP0, just RO, but UniversalStorage is in RO_SuggestedMods, and this part behavior was modified in these patches.

Another thing is the production rate itself - the RO_US config seems to use REGO_ModuleResourceConverter, which - if I understand correctly - is no longer used? It gets dumped by MM anyway and US parts retain their own ModuleResourceConverter configs.