KSPrynk

Thanks. I was editing my comment as you were viewing, tweaking cfg file stats and adding other hab parts. Dividing the 288 by 10 for 28.8 extra hab-months actually makes even more sense when compared to the other inflatables and MKS parts. Either way, a little re-balancing to keep the USI parts competitive would be welcome.

Thanks again for keeping these parts alive and providing more variety in craft design. I caught what might be a hab time entry error on the small centrifuge, but didn't see a GitHub Issue section. It has a whopping 288 Kerbal-months of extra hab time, which translates to 10 years for a full crew of two. This is far greater than the larger crew capacity parts, and probably makes the larger, late game, USI hab ring redundant. Dividing the 288 by 30 produces a more reasonable 9.6 K-months extra time, for a total of about 5 months for a full crew before adding other hab parts. UPDATE: Dividing by 10 (assuming there was missed a decimal place) produces a much more reasonable total time of 1 yr 13 days for two crew. BTW, I love the IVA; very 2001. I was looking for a little red eye on the wall somewhere....

On further reflection, adding life support functionality to the thermostat capability may be better handled as a separate mod. Mods life USI-LS just track whether the crew is on a vessel, or in the vicinity of one, that has things like supplies. DeepFreeze is the only temperature dependent life support mod that I'm aware of (but I haven't tried out TAC-LS yet). A "Kerbal Komfort Zone" mod would need to track individual Kerbals and how long they've been out of bounds (i.e., helmet closed). Making "KKZ" stand-alone would also make it agnostic to the the thermal management system, so if someone comes up with a better mousetrap to keep habs at room temp (e.g., Squad or USI adds built-in thermal control to hab parts), there wouldn't have to be fights between competing thermal management components.

True enough, but what I'm proposing actually affects the vessel physically, beyond consuming EC. And as previously noted, I think some of the necessary parts (like the heat exchanger, not found in Stock or USI-LS; don't know about TAC-LS) and required level of expertise in their interaction is resident here. Not to say RD couldn't crack it, what with his reactors and resource harvesting parts. Where I think it would really start crossing into being a true life support mod would be throwing in an option to have Kerbals go dormant (easy mode) or even die (hardcore mode) if their hab exceeds a certain temp range for a specified period (can't stay zipped in a suit the whole trip). This would be more analogous to USI hab or supply timers running out. Such functionality probably would be a good RD task as he's beaten timers to death.... PS: Best reason to do it here - it truly is Heat Control that I'm looking for.

Sorry in advance for the long post, but I love the realism that Heat Control and the rest of the NFT parts bring to KSP. With the new heat exchanger parts out, I’d like to propose a variation to achieve what I consider to be the Holy Grail of KSP thermal management – a “thermostat” for hab parts. It’s always bugged me that Kerbals don’t boil or freeze to death when cabin temps are wildly all over the map. I recognize that the thermal transfer code and time warping make for an almost impossible situation, but Heat Control and NFE seem to have the bits and pieces (and knowledge base) to make for a crude approximation. I propose a part (or family), tiny enough for Mk1 pods up through 3.75 Station parts and command modules, that utilizes EC to transfer heat between the part(s) they’re attached to, such as a habitable module, and either the existing or alternate heat exchanger parts to maintain an internal temp of 293K on that attached-to part (note: may warrant a tinier heat exchanger and radiator part set for small craft). Transferred internal part heat and waste heat from the process could be built up as exchanger core heat and removed from the heat exchanger utilizing the existing heat management parts that reach out to the whole vessel. For shadowed or outer solar system use, the “thermostat” would expend EC to heat the hab part. This may be necessary for solar powered craft only as anything with a reactor should have waste heat to spare, or perhaps not at all in the inner system if there’s plenty of stored core heat from cooling solar loaded hab parts. Ideally, this “thermostat” part would also regulate one level of adjacently attached parts, as the stock conformal radiators do, but that might make for too hard a balancing act/feedback loop, which would suggest an unobtrusive tiny part to radially attach to each hab part. Rather than put the author on the hook for balancing the tech parameters (aside from maybe efficiency), I’d recommend an inflight and VAB GUI similar to the NFE engines, where max EC usage can be adjusted by the user, as well as acceptable variation in cabin temp (say up to +/- 10K) to buffer any unforeseen feedback loops. Without knowing the trade space on solar loading rates and conduction from the rest of the vessel vs overall cooled part size, it may be best to have a logarithmic type EC slider, allowing anything from say 0.01 to 1000 EC/sec to be expended in cooling and heating. Lastly, the heat exchangers may need a core heat temp limiting “circuit breaker” that keeps the exchanger from “popping” with excessive heating under crazy warp physics and temporarily turns off the “thermostat’s” heat transfer functions, at least until the radiators get things back under control. Based on previous experience playing with the DeepFreeze cryosleep mod, ambient parts in the sun at Kerbin can exceed 460K when warp effects and/or reactor heat conduction gets wonky. I currently set my cryopods to still operate at 500K, then baste the crew while they have a good crust going…. In summary, this may still fail when going into or coming out of non-physics warp, but at least the habs would eventually get comfy again, faster than they would with just passive conduction and radiation. I’ll log this as a GitHub part request and probably link to the post rather than paste it all in.

Not sure if this is related to the options.cfg issue, but the alert volume level slider isn't working for me (alert volume stays the same regardless of % setting) in-game or after re-starting. Also, the alert settings state is not being saved after re-starting the game. I'm using Danger Alerts 1.4.0 with MM 2.8.0 on KSP 1.3.0.1804 Win x64.

I can confirm the COT-125 patch you wrote does indeed work. However, I discovered the hard way that Nertea's CryoTanks also seems to have a patch specific to the COT-250 that enables resource flow. And it's a much denser patch to pick through, so I haven't attempted to tweak it yet. Without it, cryogenic ZBO tanks and modded stock tanks show "Liquid Hydrogen Full" when the COT-125 is set to H20Splitting mode, and won't fill up. The good news is I think I found a work-around where a CryoTanks part (or modded stock tank) seems to have resource flow enabled when directly attached to an MKS Kontainer. I just add a 0.313m Kontainer Tank on top of my cryo tank stack, and everything works, even after the small tank is full. What's weird is I've made resources flow to the cryo tanks after later removing the MKS tank from the craft, so there seems to be some level of patch persistence, but I'm not sure under what conditions it would reset. Regarding balance, I'd suggest consistency with the Ore-to-LH2/Ox conversion efficiency difference between the COT-125 and -250, but I don't have heartburn with the current stats as I have no sense of scale for how much water there is to work with at a given harvesting site before the well goes dry. So what's the etiquette in this situation? Should I submit a Pull Request (with credit to you) on MKS GitHub or should it be submitted as an Issue with ref to this thread? If this gets accepted for MKS, I'd probably submit a similar request on CryoTanks for the resource flow patch.

Wow, that was fast! Unfortunately, I think I lack the skills for applying patches. Can you PM me instructions on exactly where and how to apply? I was hoping it was just editing a .cfg file for an existing part, but can't find it. Also to get this as an official part of the mod, should this maybe be a Issue or Pull Request for RD? UPDATE: Nevermind instructions, I figured it out and will test later. Still think it should be part of MKS though. Thanks for the help!

I wasn't sure where the best place for this request was, but since MKS is resource harvesting intensive and already has the appropriate drill parts, I'd like to suggest adding the H20Splitter Resource Converter module from the Convert-O-Tron 250 to the Convert-O-Tron 125. I know the COT 125 already splits Ore into LH2 and Oxidizer, but it seems incongruous that the most basic compound in the solar system can't be turned into the most easily separated propellants for cryogenic and NTR engines. Having the small ISRU crack Water would facilitate sample return probe missions at locales where Ore is below the Drill-O-Matic Jr's harvesting threshold. If anyone is aware of a part pack that includes a small Water-to-LH2/Ox converter (and works in 1.3), please let me know.

Good catch. I added an Issue in GitHub.

Thanks! While on the subject of exotic, high-powered, NTRs, if it hasn't been brought up before, check out "Pulsed Nuclear Thermal Rocket" - not to be confused with Orion nuclear pulse propulsion - on Wikipedia. It's a concept for a TRIGA-like reactor that can run higher propellant temps (and therefore higher exhaust velocity and ISP) without vaporizing itself in the process because the neutrons heat propellant directly. It's also radiator intensive; you essentially have to flash cool it in between pulses. Highly amenable to trading ISP and thrust, so it would fit perfectly with KA and NFP. Unfortunately, it's a REALLY new concept and it's hard to find much material that isn't behind a subscription wall.

Unfortunately, the mass of the Neptune got transcribed as well. The stats make the Eel an unrealistically tiny (but not light), more expensive, and slightly more powerful, co-generation capable LV-N. I was really looking forward to the lightweight NTR for smaller, unmanned craft and NASA "Peewee/SNRE"-based NTR Mars/Duna missions and would still like to see an engine with the stats noted in the post on 18 April. If there's a demand signal for a co-generation capable, non-trimodal LV-N (I'm actually all for it), I'd recommend a dedicated 1.25m engine part for that purpose. I put in an Issue on GitHub earlier.