DStaal

What you want is the wear mechanic that was recently depreciated from USI-LS - except applied to every part, instead of just to some, as it was in USI-LS. Interesting concept - it's not really 'life support' mod per-se, as you aren't really talking about Kerbal life - you're talking about equipment life.

Two comments on that: First off, as part of the integration process with MKS, Allista putting out pared down bundles of CC and GC - which should be enough to avoid the problem in the future. Secondly: I run an install with both. The only actual problem that I see is if both are applied to the same tank and you try switching resources on that tank. (You can get the tank into weird states - where it doesn't have resources, or has two sets, etc.) I believe current GC actively avoids putting itself onto tanks with IFS already installed, and I haven't seen the actual issue come up in a while - but if you were to conditional your global MM script to only apply to tanks without the GC module then it won't matter which set of patches gets applied first. (Well - it will matter, because only one set will get applied, but the only issue will be which tank-switcher people get on the stock tanks.) We probably should also suggest to both of you to make sure your 'apply to stock tanks' MM script is visible, clearly labeled, and distinct, so it' easy to remove. (I haven't checked - just saying it's going to be needed.) Then users can use both as by dependencies - and it's fairly easy to choose which to apply to stock parts.

Hmm. I do run a fairly modded install - likely culprits are Ship Manifest and Connected Living Spaces. I think I have a KSP version around without at least one of them - I'll try a test.

I added a Github issue for this as well, but I wanted to mention here: Checking a workshop for engineers appears to only happen at physics load. This means you can't transfer an engineer into a workshop and then start construction - you have to leave the scene between the two steps.

It's because RoverDude hasn't bothered to change it yet... (I believe there's even a GitHub issue on the subject.)

I suspect that since you're concerned with the effects of Configurable Containers, the MM file you'd be looking for is in that folder.

What it sounds like to me is that he's planning on redoing it again - I say keep with what we have at the moment, and rethink if/when he releases his redo. (But yes: If he's thinking the warehouse is the part that has it, then it should probably be the garage when that happens. At the moment, I more got the feeling it was the coordination office part that has it - which is the central hub.)

I've launched lopsided rockets in one launch, easily. (Try sending a Karibou rover with some Duna modules to the Mun - 3.75m launcher stage is far enough back to compensate, but a 2.5m transfer stage will need you to run RCS to stay on point.) And really the attitude control for *semi* lopsided is where this is more likely to cause issues: You end up burning more fuel to compensate as your engine wags all over the place. I've had to redesign rockets repeatedly to compensate, either by giving more fuel or some other way. Or you can have the opposite: Have a burn that takes advantage of the Oberath effect, and uses less fuel than a naive calculation would account for. Bon Voyage simulates driving a rover - what it does is check if you have 'enough' EC generation to drive, then moves the rover's location directly. There's no fuel use to compensate for - and yet getting that 'enough' EC generation calculation right has been an issue that's been tweaked several times since the release, and still has people asking for adjustments. There are lots of corner cases. There's been at least one mod out there that tried it, but nothing's done a great job.

This is one of those things that sounds simple, until you start thinking about it. How much propellant have you used? What happens if you ran out for this stage? How about if the rocket's thrust isn't centered, or you don't have enough attitude control to keep it on-point? These all actually require you to be running physics on the whole vessel over the burn to answer correctly. And of course all of this is complicated by the fact that rockets more than 2km from your current viewpoint *don't exist.* They are just markers saying 'if we switch to this, load in these resources to create the rocket'. So, it's one of those things that sounds easy and would be nice - but is actually very complicated and done the way it's done in KSP for a reason.

If you need really heavy-duty reaction control wheels, you might want to take a look at USI's FTT. It's got a couple.

I'm leaning towards 1:B as the option to go with: Focus on LS patches in isolation for the official KPBS release, and then have this patchset adjust things when it's installed. Hopefully it won't be huge amounts of differences in most parts.

(Note that I have no idea what I'm talking about in specific - just a general programmer's knowledge of how these things usually work.)

You're assuming I only care about how *Github* lays things out. Most important to me is my local repository - which happens to be a folder in my active GameData folder. Yeah, that dual-stream stage 2 is sounding like the most likely option. And I'm thinking I don't really want a 'full' release until we get to stage 2 - I'll do a 'beta' release in this thread once I get dboi88's textures merged in and the docs written. (I've got the readme mostly done.) On the greenhouse specifically: I mentioned I like the idea of having at least one mode of it being a food+hab bonus - a 'garden' that produces useful food but is also a place to hang out and get a feel for something that's not steel and dirt. Not sure if we want that instead of one of the normal three, or if it should be a modification of one of them. First thought: Personally, I want to pull the recycler out of that part entirely - Keep the purifier, but there are other recycler parts; this increases their range, but doesn't supplant them. That then frees up some space and mass - some of that will be used by industrial efficiency parts in stage 3, at least for MKS. And the flip side of that is that PL is only MKS, not LS - so for a pure LS patch we can ignore the Admin Module(s) as irrelevant. I'm also suspect of the direct hab months, though I'm less set on that. But this part is quite likely to be the biggest difference between 'just USI-LS' and 'MKS': What I'm thinking for it would be all efficiencies and admin modules, pulling Kerbals out of their bunks when they need to do paperwork and stuff - which should take space and mass, I just haven't had time to run numbers. (Honestly, I've barely got time to think at the moment.) So, for the moment compute it as pure USI-LS: Hab(s) and purifier, as that's the next patch that needs to be written. We can override in stage 3.

The main point of using machinery was to offset mass - if don't need it for that, then we can approach things a different way. Mostly just mentioning because I had included it, and it would have been a 'resource' as far as that spreadsheet goes. But yeah, either a table here or update this table: https://github.com/DanStaal/KPBStoMKS/blob/feature/Life-Support/Parts_Table.md Which I setup as a work-in-progress table. Whichever works best for you. There used to be a way - though from looking at it I think it's either unused or depreciated entirely in the current version of MKS. I decided to give the 'Planetary Control Module' 2km - but not PL, which remains a Central Hub exclusive. Yep, doing the .version file and changelog off the Release branch is the idea - that way we can play in the Dev branch. And do think the download should probably have the 'GameData -> KPBStoMKS' hierarchy - but I don't think Github should have it. Github just has the KPBStoMKS folder, and putting that in a 'GameData' wrapper is part of the release process. That keeps git clean of 'extra' folders, and makes it simpler to keep track of, IMHO. (And I expect making a .version file is super easy - how else can you get dozens of lazy mod makers to include it? )

A quick check of numbers, and I think KIS is computing the volume of the 'bounding box' - so the total length, times the height at tallest, times the width at widest. Assuming the tapers add 0.8m to each end, you get the KIS numbers from RoverDude's numbers. The KPBS parts are closer to filling out the whole rectangle, so for the non-deployable ones you can work with the KIS numbers as a general guideline. (There's probably a way to work out the exact fill percentage.) I did have one resource storage listed on my table: Machinery. That was the 550. But it sounds like the mass problem won't be as bad as we thought it was. Thanks for running things through. I can't focus on this to well at the moment, but it sounds like we're in decent shape. Oh, and thanks @dboi88. I have no idea why I couldn't get that to work for me; that looks pretty close to what I had...

Yep. Known oddity with how KSP handles things, and how USI-LS handles things. Don't worry about it really - the effects aren't being applied until you bring physics into range, and when you bring physics into range your EC production is updated.

I've always really liked the 'Quadrapoodle' from the Taurus mod. (The mod itself is somewhat out of date, but there's a set of patches in the thread.)

This type of thing is a common enough error that for the most common classes, I have a script that auto-scans anything added to my GameData folder to check. ':FOR' is badly named, and people tend to think of it with the common meaning of 'for when $x is satisfied', instead of 'this part is for $x'.

I look forward to them. As for the animations: If it were just a stand-alone animation, I suspect there would be no problem. But in this case an animation deploys *only* when something else happens: The crew capacity increases, an IVA is changed/added, some resources are consumed, etc. That's where I think the problem lies. However, I'd admit I didn't do a very thorough investigation - I just tried the two most obvious MM options, and found that while the resources were consumed and other changes appeared to occur, the animation didn't play. Feel free to poke if you want.

?? The most common monopropellent in the real world is hydrazine, with H2O2 being a decent second place - both are typically fed over a catalytic bed into the thrust chamber. Even RCS thrusters tend to run on one of those (H2O2 being more common in that usage) or variant LFO mixes like monomethylhydrazine/nitrogen tetroxide. Compressed gas might be useful for a cubesat or something, but you aren't going to get much dv out of it in a large-scale use. (Unless of course you're using it in a non-space application - where you can recompress gas between thrusts.) As I said, that was just the first I found recently. I believe I remember reading about one a while back that used a platinum (or similar) catalyst to encourage the reaction - Assuming that's a real catalyst, the only fuel the cell needs is H2O2. As far as I can tell, it's likely these have a higher power output - but you'll have to replace the aluminum block in them occasionally. Either way, the point is that if you're storing an unstable chemical you can get it to break down, and if you know what you're doing you can get that breakdown to output energy in a variety of ways, and monopropellents tend to be very unstable chemicals.

Awesome.

Can you ping-pong back and forth? (From the end, replay the animation backwards so things don't magically appear - they get replaced.) (Just an idea...)

And that has stopped us before?

Ok, did a pass on the logistics. I think I've got it, but I'll be playing around a bit to test. Anyone else is free to do so as well - Sometime soon I'll update the readme, changelog, version, and put out a stage-1 release unless people spot any glaring bugs.

Which actually brings up a question I have: Would it be possible to put in a limiter (that is: A slider you can adjust) for the processing rates for the modules that can have their efficiencies increased by Kolonization? The thought here would be that you might want to run a base or site at the 'rated' output, so that your heat-rejection/power/resources are adequate to the task, at least until you build out.