sirklick

asmi: I am working on expanding support to B9 and BASE inflatables. What was your method of assigning storage values to stock?

123nick: TAC and Ioncross are both nice life support options, however both have various issues which have taken a long time for their perspective authors to address. Options, redundancy, and competition are all necessary in community such as this (support goes away/different play styles etc), arguing that some arbitrary number of mods is enough comes off as both silly and petty. I for one prefer the UI of asmi's Life Support over the two you mentioned. I am going to be very direct here because you are out of line. In general, forum comments such as this can be construed as "all your work is for crap, give up trying to improve our options". Hiding your offensiveness under a veil of directness ("honestly in my opinion") is cowardly and not helpful. It is also a ridiculous statement to begin with. What other opinion would you be speaking from other then your own? If you do not see the need for it or prefer another life support mod by all means CHOOSE another, but this snide off handed comment is detrimental to the KSP modding community. Any response to this other then an apology to asmi will be ignored by me, so please do not further derail this thread with a response.

I know you are busy squashing bugs etc (priority), but I thought this nicety/balance issue worth mentioning for future consideration. The Big 2.5m O and CO2 tanks visually communicate that they are much higher volume then they actually are (10 small tanks plus a sphere tank possible in the middle while still allowing for support structure should provide ~4700 units of storage and mass > 2.3 based on small tank values). I am adjusting my own with MM to compensate, but the current default makes 5 small tanks far more mass efficient then the large -the only drawback being increased part count.

Thank you asmi for the fresh life support mod. I really like the direction you took with the interface, especially the global view. While I know this is a new release, do you have any extended goals for this that you don't mind sharing?

Excellent work sarbian, I know it wasn't easy figuring out how to keep everyone "happy". I have been using the dev releases for the past few days without hitch.

It seems like my initial idea -as presented- may be ill-conceived in that it would require a bit too much overhead and complexity to reopen all configs just to read that first line. If Majiir's wrapper solution would allow similar scoping functionality using the built in node system, it would be preferable to my own. As a bonus, this would allow using custom MM and MM proper in the same config without conflict. One concern that this solution would not cover would be the issue of the user having an outdated version of the globally scoped MM. This -from my understanding- is the issue that sarbian originally wished to fix with his solution. Ultimately, with the ability to specify scope in configs, modders and plugin developers should probably be discouraged from including MM proper in their packages and just link to this thread as a dependency. This way as long as MM proper is kept backwards compatible, the original scope of "MM as a mod to the way KSP handles configuration" remains, while allowing for the use of custom or old locally scoped versions to be used with and distributed as a part of mod/plugin package.

Thank you Majiir for shining some light on the process that lead to Sarbian's original decision. I really do not believe anyone meant to be harsh, though it is obvious the MM holds a special place in all of our rocket fueled hearts. I am part of the camp that was distraught by the change made, but your post has softened my original shock somewhat. Though I hate to suggest an "Internet Explorer" like way of providing compatibility, perhaps MM could include the ability to parse the first line of each configuration file which includes some information about MM scope. Ex. (One way) 1. NO LINE or MM selector - assume 1.3 compatibility (at least temporarily) perhaps MM_LOCAL_PREFERED could be the assumption for missing scope. 2. "//MM_LOCAL" - current dir/sub only -ignored by Root assume cfg will be parsed by local MM 3. "//MM_LOCAL_PREFERRED" - Use local/subdir MM if found otherwise assume Root will handle modifications. 4. "//MM_LOCAL_%NAME%" - Named instance of MM within local/subdir 5. "//MM_GLOBAL_%NAME%" - Named instance of MM within dir tree. 5. "//MM_GLOBAL" - Root MM only This would place a lot of responsibility on moders/developers to properly choose a scope, but would be transparent to the otherwise confused user. The implementation, especially for #3, might be kind of tricky - I have not spent the prerequisite time learning how MM (plugins in general) interact with Unity so this is really just a guess.

NathanKell - I like the idea of keeping as many of these mods separate personally. You can use stretchy tanks and this mod together quite nicely without some sort of combination of the two. I know that doesn't enable dynamic SRB's but this allows the mass to be altered without scaling, making any scaling done mostly aesthetic. The Stretchy Tanks modder does not seem overly enthused about collaborations or expanding outside of the fun things he likes doing with KSP (can't blame him despite his apparent curtness with others who wish him to implement tie-ins). The moment modding KSP becomes too much like work, is the moment we lose support for the mods we love. yongedevil - fantastic job, thank you very much for this and all of the work you put into it. Neat potential feature you may or may not feel like implementing would be the ability to alter the thrust curve over time similar perhaps to the mechjeb ascent autopilot editor.

I have made very limited use of the Kethane mod as well. I did have a save with a Minmus fueling op for a short bit, but ultimately ended up rarely using it. Min/maxing rockets for specific payloads is enough fun that I don't actually get out there and explore as much as I probably should. That being said, I did do a quick study of the Kethane numbers and they are not as crazy as I originally may have thought. The algorithm that Kethane uses for computing output of fuel per unit of Kethane is inputDensity/outputDensity*outputRatio. The only values to set are the input units, energy expenditure, and the output ratio. Perhaps I am slightly masochistic but my first inclination in attempting to find the proper balance was to look at the chemical composition of each of the output fuels and come to some possible real world analog for Kethane. It did not take too long for me to realize how futile and yes stupid this approach was. Within the realm of the Realistic Fuels mod Kethane is a magical petrochemical slurry and Kerbins are crazy advanced in chemistry and chemical breakdown/assembly. So with realism mostly out of the door, my thought is that convenience may be the best way to balance the numbers. LH2/LOX mix ratio is 73/27 or some such right? Since Kethane allows you to convert to multiple fuels at once, why not set the input values so that the output is of at least roughly that ratio assuming LH2 and LOX conversion are running at the same time. This seems to be the Method Majiir is using for the stock fuels.

I had updated the Kethane config with this , but I am still unsure about the conversion values balance so left them as they were.

birrhan - 500 m/s is over 1100 miles per hour (way too fast for a parachute), the stock parachute has too much surface area for use at that velocity. There are a couple of possible solutions to your problem. 1. Slow yourself with a burn (100m/s or so) and then deploy main 'chute. 2. Use the lower resistance parachute first and use a radial main 3. Come in less steep and give yourself more time in atmosphere to slow down. You also may want to look into mod parachutes since KSP is severely lacking in parachute diversity. Drogue parachute ex. http://forum.kerbalspaceprogram.com/showthread.php/28063-Radial-Drogue-Parachute

Starwaster - Nice, I like the simplistic look of one giant tank. 15 tanks is quite a bit of LH2, is 8k dv all you really get from that? What are you using as the core structural component? It is difficult to tell from that last picture.

I was unable to find a working Kethane config that works with kethane 0.7.7 so I converted the older MM-MF config to work with the new Kethane Module format. I hope this easy edit helps someone. Overwrite the contents of KethaneConverter.cfg with this and save. @PART[kethane_2m_converter] { MODULE { name = KethaneConverter HeatProduction = 700 InputRates { Kethane = 9 ElectricCharge = 25 } OutputRatios { LiquidH2 = 1.2 } } MODULE { name = KethaneConverter HeatProduction = 650 InputRates { Kethane = 5.75 ElectricCharge = 20 } OutputRatios { LiquidOxygen = 0.95 } } } Also, does anyone know where the Kethane conversion numbers for MF came from? The provided values seem kind of arbitrary and not well "balanced". Specifically the ElectricCharge requirements and the computed LOX output per second is about half of the output per second of Oxidizer with over double the energy expenditure. I have my own ideas about balanced numbers here, but I wanted at least have a short discussion before editing.