DStaal

That's what I'm hoping for, I'm just looking for verification. AntennaRange does this by adding a 'EVA_MODULE'. Though there's a DLL involved as well, so...

Out of curiosity: If I have a line along the lines of '@PART[apart]:FOR[x]:NEEDS[y]', does the 'mod x exists' feature come into play even if mod y isn't installed? (And: Would it matter the order the :FOR and :NEEDS are in?)

If you include it, the second should probably depend on NFE.

The larger percentage takes precedence, up to it's max Kerbal capacity. Then the smaller effect will come into play on the rest of the Kerbals, up to it's max capacity. Continue on down. (I'd dispute calling it 'stacking' - as the term is normally used in discussing games they do not.)

I created a PR for RoverDude with the change - I used 'USISoundingRockets' instead of 'SoundingRockets' just in case someone else comes out with a 'SoundingRockets' mod.

@westamastaflash would like to see some line along the lines of: @PART[SR_Nosecone_*]:FOR[SoundingRockets]:NEEDS[AntennaRange,!RemoteTech] So he can write an MM patch that targets ':NEEDS[SoundingRockets]' instead of ':NEEDS[UmbraSpaceIndustries]' - basically, he wants more fine-grained control. When you install this mod, you'll have a folder called 'UmbraSpaceIndustries' so the latter will already trigger, but you don't have anything saying which part of your large collection of mods you have - at least, not in a way that MM understands. If I have a few minutes I may go in and make a PR on this - it sounds like a good idea to me, and you have several patches with ':FOR[UmbraSpaceIndustries]' which could be converted over without other effects. (My example being a copy-and-replace of one of them.)

I haven't actually looked at it from a Career perspective (I normally play Science mode), but the 2000 seems fair, or a bit cheap compared to other science experiments. So a small increase sounds fine to me. (And yeah, moving it to a science node makes sense. It might even go into a fairly early science node - even the Lunokhod 1 carried a sample arm.) More important to me than the ability to take more than one sample would be the ability to retract the drill once it's taken a sample - currently a scientist can do it by resetting the drill, but their is no way to do it otherwise. This can make driving a rover with one a bit awkward. (I tend to deploy a science base and then have an automated rover that gathers data from the body - single-use experiments are fine, as it'll return and the scientists can gather the data and reset things.) Even in a case where it was single-use and there wasn't anyone nearby to reset it it could be useful - it'd allow you to collect more data from other experiments. As for the augers - they aren't very useful to me at the moment. I don't play with Kethane, and the package I have only has them working with Kethane.

I mostly thought the drill bit idea might save you work - up to you if you want to use it. And yeah, they don't have core heating - though I don't think they've actually been touched since core heating was added to drills. Having heat makes sense. One other thing I thought of: The science drill is currently huge. As in an couple of orders of magnitude larger and heavier than any other science part, and quite possibly heavier than the entire rest of a decent science lander rover/probe. If you're doing updates, could you scale it down a bit? (I've got it scaled to 0.07 percent rescale factor and 0.1 ton mass in my install...)

As a UKS user, it'd be nice to have variants with that resource tree: Substrate, MetallicOre, Minerals, Uraninite, Dirt, ExoticMinerals, and RareMetals. Water, Gypsum, and Hydrates would also be nice for USI-LS. (That actually covers just about all of the CRP with spawn rates, with the exception of Alumina...) UKS 'groups' those into three drills: One for light materials (Gypsum, Hydrates, Dirt), one for medium materials (Water, ExoticMinerals, Minerals), and one for heavy materials (everything else). That's currently - @RoverDude is talking about re-designing his drills to have some sort of interchangeable bit system. If that comes to pass, it might be something that could be done here as well.

Just to say: Just because there are no crashes, that doesn't mean there are no logs. KSP always creates a log during a run. It should be in your base KSP folder with the name 'KSP.log'. Upload it someplace and post a link - then @Angel-125 might be able to see something in it. (Won't say he will, or even that he'll bother to look, but if you post it he can. )

That's a lot harder than it sounds. Basically, there isn't any way in base KSP to tell it that a part has seats but can't be used for stranded Kerbals. I believe there's a mod around that takes the opposite approach: It basically tells KSP that this is the list of parts that Kerbals can be stranded in.

Yep, sounds like you've got it. The one wrinkle that's been discussed from that is greenhouses - it makes sense from a realistic standpoint for them to have hab multipliers. They are even used for that in real life. However, giving them a food converter and a recycler and a hab multiplier (which is the logical thing to do, and would be realistic...) makes them fairly overpowered in-game. @RoverDude's don't have all of those, so you have to think about balance a bit. I think if you had a massive one and dedicated some mass to the hab multiplier (meaning it has a less capable recycler and mulch converters) it could be balanced, but be careful. It's pretty close to a 'do-everything' part.

In general a hab multiplier is things that make life a bit better - quality of life, or R&R type parts. The Kerbitat in that context has a kitchen ('food preparation facilities') and better control over the A/C ('hookups for environmental control') - quality of life, in the form of better food and a more comfortable environment. It also has a water purifier (which to me is really a separate thing than a general recycler - the normal recyclers allow you to re-use what resources you have, the water purifier uses water to extend your resources), and might be a bit OP with both, but the purifier probably doesn't take up much mass. (I've worked with units that have a larger capacity than that and were countertop sized.) They inflatables are nice, but they only affect the crew that can bunk in them, so they don't get multipliers. There's a big discussion on balancing some of these parts a bit back in the Kerbal Planetary Base Systems thread, where we were discussing balancing some station parts. It might be worth a look. Also might be worth a look is this page: https://github.com/BobPalmer/MKS/wiki/Supporting-MKS-in-your-mod#habitation. Mostly it's the same info as what's in the configs, but I put in some explanations and things to think about. My general way of thought is that you should approach it thinking of there being three types of spaces: Normal work areas - they give some elbow room, but no extras in terms of habitation or multipliers. Standard living areas - actual living space beyond what's needed to work, they give habitation time to the crew who can bunk there - but they don't help crew that can't use that space. R&R/Quality of life areas - they provide benefits to the entire crew of the ship, whether they are assigned to a 'bunk' in that space or not. Places that make living in a tin can more pleasant. You don't add anything to the normal spaces, living areas get hab time, R&R/QoL areas get hab multipliers. Parts can have some of each - just decide how much mass is dedicated to each function. I hope that helps.

The problem isn't necessarily if a mod is installed - MM's 'NEEDS' handles that case fairly well - but whether a particular mod uses LqdHydrogen. If you want to manage a list of mods that include it and have them all in some huge 'NEEDS' line, all power to you. It's just going to be a lot of work. (Unless you're thinking of doing something else than what I think you are. If you're trying to think of dynamically figuring out what fuels are used, my first thought on an approach would be to iterate through engines+RCS thrusters, checking what resources they use, and have an exclusion list for things like EC or intakeAir. Though I have no idea how hard that would be.)

Well, it at least sounds like you've got MechJeb to work. Hard to know for sure from that description - you don't mention which autopilot, the settings, the design of the ship, anything. MechJeb is good, but it's not magic, and it can't handle every ship. My suggestion would be to take any further discussion to the MechJeb thread - and start with a screenshot of the ship in flight, with the relevant autopilot window open and visible in the image. They should be able to help from there.

While I appreciate the idea behind only showing Hydrogen and Hydrolox when they are needed, you're going to have a hard time keeping up with 'when are they needed'. I don't have KSPI-E, but I have several engines that run on Hydrogen. (Off the top of my head, I know that USI's Freight Transport Technologies have one or two, for instance.) What you really need is 'if any part of type X uses resource Y, then I want to include resource Y', but I'm not sure that's possible with MM. (And I'm sure that if it's not, it's not something trivial to add.)

Looking at your configs for RO and RealPlume: It might be a good idea to change those 'FOR' to 'NEEDS' - then the configs will only activate in the presence of RO or RealPlume, instead of activating every RO and RealPume config you may have in any other config file.

I'll be keeping an eye on this one - at the moment it doesn't offer me anything other mods don't already offer (as part of larger part packs), but I like the theme and having airlocks is useful. For the small docking port: I believe @Angel-125 worked out that you could fit a Kerbal through one - as long as they weren't wearing a helmet. So probably not something you want as an airlock.

Your two main choices for Life Support at this point are TAC-LS and USI-LS. TAC is focused on appearing realistic - resources are things like oxygen, food, water, etc. - while USI-LS is designed to feel a bit more 'Kerbal' in that it abstracts all of that into a unified 'Supplies', but it can be argued that USI-LS's inclusion of things like homesickness mean that it's more realistic overall, and it's supplies resource is scaled to include the mass of things like the clothes your kerbals wear. There's a decent discussion of the merits of the two a couple of threads over.

You're overestimating a bit - machinery gets used very slowly, especially by purely robotic bases. (Which don't produce at full production rate.) A small amount of machinery will get you a long way. However MKS is designed to need occasional shipments in, with them reducing over time. Duna is not Kerbin, and you need stuff from home to live. I'd set up on Minmus first and get a feel for things - you can make mistakes and only have it cost a few days to send up a Kontainer to fix things.

Unfortunately I'm on a very old Mac - a 2008 Mac Pro. It runs KSP fairly well (with the performance hits a nearly decade-old computer would expect...), but it won't run the current OS, and mono won't run on 10.7.5. So I haven't even really looked into CKAN.

Ok, fellow Mac user here. (Not a Steam user, if that matters.) Two things are being talked about: First off, in <path/to/KSP>/GameData/ you should have the 'MechJeb2' folder. <path/to/KSP> is whatever your current path to the 'Kerbal Space Program' folder is - I've got mine in /Applications/Games, but again I don't use Steam. I don't believe it should matter what directory the game is in. (Unless it's installed via Steam, in which case Steam probably wants to know where it is.) It was mentioned what the default location is for the game on Windows - but we can ignore that, because we're not on Windows. Secondly, once that's done, to activate MechJeb on a ship in the game, you need to attach an AR202 or a MechJebPod to that ship. The AR202 is a radially attached thing that looks kinda like a walkie-talkie. The MechJeb Pod is a full drone core pod that looks something like a 'Portal' intelligence core on a mount, and is awkward as hell to use so I would advise against it. Both of these parts should be available in the Command tab, assuming you've unlocked them. (Or are in Sandbox mode where everything's unlocked.) Once one of these has been attached to a ship in the VAB or SPH, you should see something pop up along the side of the screen to give you access to MechJeb's functions.

One thing I've noticed with the expanding docking ports is that they only operate as 'docking ports' when expanded - could that by your issue?

Yep. You need EC all the time or your Kerbals will... Whatever they do when they run out of supplies. (Basically there's a secondary supply timer for EC.)

And if you don't have any manned missions going on that probably won't be a problem.