PocketBrotector

Yeah I suppose so, though the question mark-laden documentation does not give me a lot of confidence in its accuracy. Also there's still possibly a question of which patches are applied first within each pass (e.g. if two both have the AFTER keyword.) Hopefully using edit-or-replace will make it work correctly regardless of the order of application - though I still need to confirm it's working as suggested by the same wiki.

You definitely want a recycler (science lab) and converter (greenhouse) for interplanetary missions, as the mass you "spend" on those parts will be saved (and then some) on the mass of the supplies you don't have to bring. Similarly, hab multiplier(s) (cupola) will enhance the effectiveness of your hab space (hitchhiker cans). On a different topic... I was posting a USI-LS config for KPBS on that mod's thread, and @Kowgan pointed out that my configs were at risk of conflicting with the catch-all config included with USI-LS. There is some uncertainty as to the exact order in which ModuleManager applies patches. Consider this example of a custom config and its interaction with LSModule.cfg... If the custom config runs first then LSModule, MM filters out the part when LSModule runs, because it already has USI_ModuleLifeSupport, so everything is fine. If LSModule is applied first, then we end up with two different USI_ModuleLifeSupport and USI_ModuleFieldRepair modules on the same part, along with competing quantities for ReplacementParts - not good. Then I considered adding the !MODULE[ModuleLifeSupport] filter to the custom config as well, which would prevent the duplication... but instead, if LSModule is applied before the custom config, the part ends up with completely generic modules and ReplacementParts quantities instead of the hand-chosen hab space/hab multiplier/recycler values. So instead I am playing around with the edit-or-create function ("%") in ModuleManager. As I've never used it before, this is just an experimental first pass - but here is a generic template. This should create the relevant bits if it happens to be applied before LSModule; if LSModule goes first, it overrides the generic values instead - no interference or duplication, and nothing missed. I guess the question now is - what's the best way to test it to confirm everything is working correctly? Most of these modules aren't exposed in the VAB UI, so I started by saving a craft and then inspecting the .craft file; but that's sort of maddening, and I still don't know the order that the patches are actually being applied, so I can't really say for sure if it's working correctly in every scenario.

I thought it shouldn't, as the LSModule filter should exclude everything that already has a ModuleLifeSupport. Now that you point it out, I suppose that we could have duplicates depending on the order in which patches are applied. I have so far found ModuleManager's internal workings to be slightly opaque, so I think I'll have to look into this further to make sure everything is getting the correct values and modules. Thanks for pointing this out, as I've been creating a number of patches for various mods and I'd hate to get them all wrong

Nils277 was kind enough to mention my UKS/USI-LS compatibility patches for KPBS in the OP, so I updated them and actually created a release this time. These config files incorporate all USI-LS core functions (life support recyclers; habitation space & multipliers) and most of the functions of the "Duna"/"Ranger" module series from UKS (cultivation, logistics, storage). See the readme for details, give it a spin, and report any issues.

For those who are interested - pull requests have been accepted by Nertea to incorporate USI-LS configs for his excellent Station Parts and Near Future Spacecraft mods; I think they're just pending the next releases, but you can grab them from the GItHub repos in the meantime, and here are a few more for other mods. On that note... @RoverDude, I'm guessing that ReplacementPart consumption is going to be removed from recyclers across the board in LS? Just need to confirm before I submit updated pull requests . Also, can you verify the preferred rate of Water consumption on the 90% recyclers? The LSModule file mentions 0.000002 per crew capacity, but the Kerbitat uses 0.005 for a crew capacity of 5.

Would it be possible to make the reactors (or at least the tiny one) surface-attachable? I find that I typically need a reactor of a given capacity, but its size doesn't fit anywhere in the vehicle stack. For example, the 0.625m reactor is sufficient for most purposes short of UKS-style heavy industry or NFP-scale electric engines - but I don't usually have any 0.625m nodes handy. Right now it is stashed in a service bay by itself, but it would be neat to have the option to mount it radially (without kludging with a cubic strut), or in a service bay that doesn't have interior nodes, a la Near Future Spacecraft or the Taurus HCV lab.

I have made a patch for anyone who wants to use the habitat pack with USI Life support. The inflatables get habitat space (proportional to their mass as usual) while the orbital orb gets a recycler:

I think I'm having an issue with underperforming recyclers. I've got an Akademy with twelve scientists and three Pioneer modules (plus four inflatable habs and two inflatable ag modules). With all of the pioneer module's recyclers turned on, I would expect supply consumption to total 48.6 (16.2 per kerbal per day * 12 kerbals / 4 for the 75% recyclers). Actual supply consumption is 63.2 (though if I turn on the inflatables' recyclers, I can reduce it to 53.3). Are there supposed to be diminishing returns with multiple recyclers?

Here is a ModuleManager patch to add USI-LS hab and recycler functions to the Taurus parts. The science lab and passenger cabin get recycler and hab-space functions, respectively, as they are big versions of the stock parts which get those functions from USI-LS. The HCV itself has nice bay windows, a bit like the cupola, so it gets an equivalent hab multiplier. Edit: use the link, not the spoiler text, due to overzealous automated censorship on the part of the forum software, per Kerbas_ad_astra's note below.

I am doing some launchpad tests and seeing my habitation timers count down much faster than I would have expected. Basically I left a vessel occupied on the launchpad for a year, and at the end the hab timer had counted down by over four years. I know that there was a similar issue reported earlier, but that was for a base that was overfilled with crew, and may have had too many life support recyclers running. I've only got life support turned on for a single Pioneer module, and my kerbals have a ton of space (this is a ship that's supposed to be considerably over-engineered for interplanetary trips, so everyone has lots of room.) Is this a bug, or expected behavior due to wear? If the latter, is there a way to get a true estimate of how long the habitation will last, including with wear?

Already pretty much possible, I think. Any ship with a sufficiently great habitation space/multipliers will set the hab timers to very high values.

You should add ReplacementPart storage (following the examples in the LSmodule file) or else you will probably get weird behavior as the habs wear out. I've submitted pull requests to Nertea for USILS patches for his Station Parts and Near Future Spacecraft pods; you can review or grab them at those links. Most parts got hab space (including the ISC utility cabin, which is analogous to the stock Hitchhiker Can). The SSP large cupola and observation module got hab multipliers instead, since they are big versions of the stock cupola (stare out the windows and relax...) The Near Future two-person pod is heavy for its intended orbital operation, so I added a recycler there. And here is one for Porkjet's Habitat Pack - the inflatables get hab space, while the orb (which is rather heavy for orbital work) gets a recycler.

I'm thinking of using the guidelines in LSModule.cfg to whip up some MM configs for other part packs (mostly Nertea's). Would these be considered for inclusion in the USI-LS releases? Also, thinking out loud on an earlier vessel design... I have a design that consists of cupola, kerbitat, pioneer, hab ring, and orbital ag module. A round trip to Eeloo takes about eight years. For a crew of three, it's pretty easy to pack enough fertilizer to last that long (less than five tons if my math is correct.) But the hab time is showing as only 1457 days (with everything inflated); at this point, I already have the best of everything (hab space, hab multipliers, etc.), so it looks like I would need to start doubling up on kerbitats, hab rings, etc. to make it out there. Eeloo is hard! Or at least very hardware-intensive.

These look great! I had been looking for some nice big NTRs for some time, but I didn't realize just how badly I wanted them until Nertea published some The Liberator in particular seems very very good. Having Isp that high without sacrificing thrust more than makes up for the low volume of LH2 and the need for refrigeration. I am looking forward to seeing the patch to convert these to LF (just as a matter of personal preference) so that I can see what kind of performance is balanced against the stock Nerv.

Your best recycler functions as a cap on your recycling effectiveness. Currently the best recycler is the pioneer module which can reduce supply consumption by 75% for up to five kerbals. If you have more than five kerbals, you can supplement it with other recyclers (not necessarily additional pioneer modules - you could have kerbitat/aeroponics or inflatables, for example) to bring the total recycle rate back up to 75%.

Sure thing. I am running 0.3.4. Here are the values I'm getting with a Pioneer, Kerbitat, inflated hab ring, and inflated orbital ag module: 1 crew - 53y,27d 2 crew - 13y,295d 3 crew - 6y,117d 4 crew - 3y,270d Screenshots here.

Release notes for UKS indicated this should already be possible. Unrelated: I'm getting some curious results from hab multiplier parts. With just a cupola and one kerbal, the build aid is showing a hab time of 559 days. Also for larger vessels, hab time decreases very quickly as additional crew members are added (for example a crew of two has a hab time of ~1/4 that of a crew of one.)

I dug into the new habitation logic and this is how I think it should be working: Hab Total = (Crew Capacity + Additional Kerbal-Months) / Current Crew * (Total Hab Multiplier + 1) Total Hab Multiplier = sum of each (Part's Hab Multiplier * Part's Crew Capacity / Total Crew Capacity) Unfortunately this doesn't actually match the readouts that I'm getting in the VAB supply window, so hopefully someone can correct what I've gotten wrong. I also logged a Github issue because my habitation time for a given crew size was declining as I added crew capacity. I think that's because it's actually "diluting" the effectiveness of the Kerbitat's hab multiplier, though more testing may be needed.

Yessir. At first I was a bit wary of the extra variables, but in the end I needed about twice as much life support mass as I would have pre-update to build a viable, flexible interplanetary shuttle for smallish crews. With UKS it was critical to pile on as many multipliers as possible to boost both habitation and recycling/conversion, but the final part count was still modest.

I just got done digging through the logic in the source code, so I may be able to bring some clarification to the habitation formulas. If these descriptions are useful perhaps they can be the basis for a wiki page or whatever other documentation is created. Total hab time = (sum of all parts' Kerbal-Months + config's base hab time [default one month or thirty days]) * (sum of all parts' hab multipliers + 1) * (sum of all parts' crew capacity / number of crew) * config's hab multiplier [default 1] Breakdown: Kerbal-Months are specified on a per-part basis. The only stock part with any kerbal-months is the Hitchhiker Can, which has 12 months. UKS adds the inflatable hab modules (3.75 KM's for the surface version and 6.25 KM's for the orbital version) The base hab time is specified in the config file. Default is one month (thirty six-hour days.) Parts with hab multipliers only exist in UKS at the moment; the Kerbitat has a multiplier of 3, and the Aeroponics module has a multiplier of 1.25 The config file's hab multiplier is 1 by default. All vessels within 150m are considered when calculating habitation and recycler mechanics. So I just built an interplanetary ship with a kerbitat (hab multiplier 3, crew capacity 2), inflatable hab ring (kerbal-months 6.25, crew capacity 10), and five additional crew capacity. With three crew, my habitation time is: (6.25 + 1 kerbal-months) * (3 + 1 hab multiplier) * ((10 + 2 + 5 crew capacity) / 3 crew) * 1 = 164.333 months, or 4930 days, or 11.57 years.

I've got something similar, I think... I have Vessel 1 on the runway (with plenty of Supplies); when I go to launch Vessel 2 from the launchpad, all of my crew from Vessel 1 go MIA. Not sure if I am missing something here.

I whipped up some configuration files to use these parts with the USI Kolonization mechanics. Feedback appreciated: https://github.com/LouisB3/UKS-KPBS_Compatibility

Chiming in on this... Several of the parts have mismatched mass values (the dry mass vs the FSFuelSwitch basePartMass). Also the adapter plate and short wheel bay seem to be too heavy. In summary: [TABLE="width: 637"] [TR] [TD]Part[/TD] [TD]Volume[/TD] [TD]Mass[/TD] [TD]MassFS[/TD] [TD]Depth[/TD] [TD]Notes[/TD] [/TR] [TR] [TD]Kontainer (2.5m)[/TD] [TD="align: right"]20,000[/TD] [TD="align: right"]3.20[/TD] [TD="align: right"]3.20[/TD] [TD="align: right"]8[/TD] [TD][/TD] [/TR] [TR] [TD]Full Wheel Bay[/TD] [TD="align: right"]10,000[/TD] [TD="align: right"]2.00[/TD] [TD="align: right"]2.00[/TD] [TD="align: right"]4[/TD] [TD][/TD] [/TR] [TR] [TD]Short Wheel Bay[/TD] [TD="align: right"]2,500[/TD] [TD="align: right"]1.50[/TD] [TD="align: right"]1.50[/TD] [TD="align: right"]2[/TD] [TD]Storage should be 5000 by depth. Mass should be 1.0 to match full wheel bay[/TD] [/TR] [TR] [TD]Adapter[/TD] [TD="align: right"]1,250[/TD] [TD="align: right"]1.00[/TD] [TD="align: right"]0.65[/TD] [TD="align: right"]1[/TD] [TD]Storage should be 2500 by depth. Mass should be 0.5 to match full wheel bay[/TD] [/TR] [TR] [TD]Cargo Crate[/TD] [TD="align: right"]2,500[/TD] [TD="align: right"]0.40[/TD] [TD="align: right"]0.40[/TD] [TD="align: right"]N/A[/TD] [TD]Equivalent to 1.25m Kontainer[/TD] [/TR] [TR] [TD]Cargo Tank[/TD] [TD="align: right"]2,500[/TD] [TD="align: right"]1.00[/TD] [TD="align: right"]0.40[/TD] [TD="align: right"]N/A[/TD] [TD]Mass should be 0.4 to match FSFuelSwitch and crate values[/TD] [/TR] [/TABLE]

Great mod! CTT would be harder to use without it. Bug report: I get this line crossing through Meta-Materials: My mods: [TABLE="width: 231"] [TR] [TD]AsteroidDay[/TD] [TD][/TD] [/TR] [TR] [TD]CommunityResourcePack[/TD] [TD][/TD] [/TR] [TR] [TD]CommunityTechTree[/TD] [TD][/TD] [/TR] [TR] [TD]DatedQuickSaves[/TD] [TD][/TD] [/TR] [TR] [TD]ExtraplanetaryLaunchpads[/TD] [TD][/TD] [/TR] [TR] [TD]Firespitter[/TD] [TD][/TD] [/TR] [TR] [TD]HideEmptyTechNodes[/TD] [TD][/TD] [/TR] [TR] [TD]InterstellarFuelSwitch[/TD] [TD][/TD] [/TR] [TR] [TD]JFJ5_Flags[/TD] [TD][/TD] [/TR] [TR] [TD]KAS[/TD] [TD][/TD] [/TR] [TR] [TD]KerbalEngineer[/TD] [TD][/TD] [/TR] [TR] [TD]KerbalJointReinforcement[/TD] [TD][/TD] [/TR] [TR] [TD]KIS[/TD] [TD][/TD] [/TR] [TR] [TD]KSP-AVC[/TD] [TD][/TD] [/TR] [TR] [TD]MechJeb2[/TD] [TD][/TD] [/TR] [TR] [TD]MechJeb2 Embedded[/TD] [TD][/TD] [/TR] [TR] [TD]ModuleManager[/TD] [TD][/TD] [/TR] [TR] [TD]StageRecovery[/TD] [TD][/TD] [/TR] [TR] [TD]StockBugFixModules[/TD] [TD][/TD] [/TR] [TR] [TD]TriggerTech[/TD] [TD]KerbalAlarmClock[/TD] [/TR] [TR] [TD]UmbraSpaceIndustries[/TD] [TD]ExpPack[/TD] [/TR] [TR] [TD]UmbraSpaceIndustries[/TD] [TD]FTT[/TD] [/TR] [TR] [TD]UmbraSpaceIndustries[/TD] [TD]Karibou[/TD] [/TR] [TR] [TD]UmbraSpaceIndustries[/TD] [TD]Kolonization[/TD] [/TR] [TR] [TD]UmbraSpaceIndustries[/TD] [TD]Kontainers[/TD] [/TR] [TR] [TD]UmbraSpaceIndustries[/TD] [TD]LifeSupport[/TD] [/TR] [TR] [TD]UmbraSpaceIndustries[/TD] [TD]ReactorPack[/TD] [/TR] [TR] [TD]000_USITools[/TD] [TD][/TD] [/TR] [TR] [TD]Workshop[/TD] [TD][/TD] [/TR] [/TABLE]

I made a couple of configs to tweak the big NTRs. Increase the mass and remove the gimbal to keep these engines consistent with the 1.0 LV-N { @mass = 36 !MODULE[ModuleGimbal] {} } @PART[FTT_Engine_375_04] { @mass = 15 !MODULE[ModuleGimbal] {} }@PART[FTT_Engine_375_03] Change the fuel type to stock and reduce the Isp to 800 (basically a de-Near Future patch) @MODULE[ModuleEnginesFX] { !atmosphereCurve {} atmosphereCurve { key = 0 800 key = 1 185 key = 2 1 } @PROPELLANT[LqdHydrogen] { @name = LiquidFuel } } } @PART[FTT_Engine_375_04] { @MODULE[ModuleEnginesFX] { !atmosphereCurve {} atmosphereCurve { key = 0 800 key = 1 185 key = 2 1 } @PROPELLANT[LqdHydrogen] { @name = LiquidFuel } }@PART[FTT_Engine_375_03]{ So with both of these, the 2.5m NTR is equivalent to five Nervs, and the 3.7m NTR is equivalent to twelve Nervs. Useful for big stockalike freighters.