DStaal

Two things are likely to be a problem there. First off, this mod is localized, and 1.2.2 didn't have localization, so all the text will be gibberish. Secondly, there's some animated parts that rely on an DLL, and typically those need to be recompiled for each major version. So I'd expect most of the parts to work back to 1.3.x, but at least the text to break on anything older than that.

The point is that the most convenient and obvious place is actually a bad choice. Since they've developed some magic liquid metal techniques for the cargo door, perhaps they could use it on the docking port as well? Just extend a bit further and it works around the issue. (Or put a node/slot for it someplace.) I hadn't noticed that the gravitic engine has built-in RCS, I'll have to try that out. I figured landing legs were low priority, and I agree on that. Just wanted to put in a vote that they should be on the list someplace. My thoughts would either be to have simple extending sticks that you can put down, or repurpose the heatshield legs from DSEV that nearly fit.

Played around with this a bit yesterday in 1.4.4, just to try it out. Had some issues with a sticky keyboard, but generally it flew well. Went and landed on Minmus. (Then got a key stuck and flew off into interstellar space...) It does take some planning to deal with the static charge... A couple of quick notes: First, the attachment node on the top of the reactor is a bit high - sitting above the reactor a bit. Could probably be lowered, so parts don't float in mid-air. Second, where's the static-charge dissipating rod supposed to go? I want to attach it to the top of the reactor - but that would get in the way of docking. (Unless the docking port could extend further?) Also, this needs some conformal RCS ports. The ones you have included are great, but look pretty ugly stuck on the edges of the saucer. (Maybe build them in as part variants to the sections?) It also needs a good set of landing legs - wheels are fine early on, but this should have a tripod from the engine or something.

Do you have any life support mods installed? I know they often have a per-Kerbal EC drain. (Do you have any Kerbals aboard?)

Near Future Electrical has some storage parts as well: Kerbal Planetary Base Systems also has a set of parts for using, enriching, and storing Uranium, but they may not be as suited for transport:

A fair number of gameplay-extending mods like this one will technically work with the stock tree, but are really designed with the CTT in mind. The stock tree just doesn't have the depth of tech nodes needed to support extended gameplay.

I believe these checks only check to see if the kerbals are in the *ship*, not the part. (Since there are some parts with those processes that don't have seats for Kerbals, and it reduces the total number of Kerbals required for large bases.)

Current version works fine (and is compiled for) with 1.4.x. RoverDude just hasn't updated his thread headings.

I believe drills are a known issue for Ground Construction.

I know the REKT part has them all eject at once if you stage the decouplers, but you can release them one at a time via the right-click menu.

In case you didn't see - Kobattos reviewed already: https://youtu.be/SosK_BmGRkw

I do think it looks good, and sleek enough without doors. (Which would be a possible problem for an escape pod - if you're in an escape pod, it's because there are things going seriously wrong with the ship you were in - are you going to rely on the doors working?). If you can get it so it doesn't look like it was cut out with a set of big tin snips, I think it should be fine.

Please no. Preventing people from being stupid is futile - and this thing just cries out for warning lights and service handrails. (And yeah, on this part I think the polygon count on the curves seems a bit low.)

Put the decouplers on the shroud. (REKT has a similar part with several decouplers built in.) Leave the top of the pods as docking ports - then you can rescue them (when they can't deorbit themselves) with a dock.

Which of course leads to the question of why they're docking nodes in the first place. Decouplers would be role-appropriate. And if you wanted to replace the pods you've used, you just have to send an Engineer with a wrench.

It's also significantly harder to control than the Mk1 pod, doesn't fit nicely on a stack (even with the fairing from the heat shield it looks a bit awkward), has a lot less torque, and carries significantly less EC and Monoprop than the Mk1 pod. I've flown it a few times. Believe me, if you want to launch into space and back the Mk1 is a far nicer pod to work with. (Orienting for a circulation burn with even a small upper stage attached is *very* annoying.) But for the stated job of being an escape pod on a space station, it works fairly well. Yes it's cheaper and lighter, but that fits for an escape pod.

Installing this mid-career is not recommended, though it doesn't break anything. What happens is that parts you've already unlocked that move will be present in both places in the tech tree, presenting what's largely a visual glitch, and allowing you to use parts that you might not have been otherwise able to unlock. For you, I'd avoid installing it this late in your game - but it won't actually hurt your game to do so.

NO. MKS and Kerbalism do not work together. This is well-known. RoverDude has no plans to offer Kerbalism support. Trying them together will break things.

What makes you think they should? MKS explicitly lists that it doesn't support Kerbalism.

That's not the KER window, or the MechJeb window. I think it might actually be a stock feature - I've noticed it as well, and it might be something brought in in KSP 1.4. (The KER window, should you bring it up, has a button to switch between atmospheric and non-atmospheric modes.) If you want to see which it is, try a very small probe with a Xenon thruster, or something else that produces essentially no thrust in atmosphere, but produces a moderate amount in space. Then compare the info to the expected. (Or bring up the KER window and compare.)

Yep, 0.2.4. And yes, I haven't unlocked the fusion reactor yet - I just barely unlocked the drive, and it's my highest tech level. I won't worry about it then.

Could probably slope it, if you wanted. BTW: I'm just unlocking the parts - are you supposed to be able to fly from Kerbin at this level of tech? I'm running out of GravityWaves extremely quickly - and the generator says it's running at about 28% efficiency. Is this normal, and something's going to be unlocked? One last thing: When placing a part with a tooltip in the SPH, (haven't built one in the VAB), I get multiple pop-ups of the tooltip, all in exactly the same place. (Making it look like closing the window doesn't do anything.) I am having fun though.

I did a quick test myself - pretty much seeing the same as you. Ran out of EC on the way down, way before I needed to release the chute. (Again, USI-LS uses EC - may either want to write a config for USI-LS, or just up the base EC.) The one other thing is that it spun widely on reentry, and couldn't keep the heat shield to the front. (Using the KOOSE heatshield.) Reentered from about a 120,000km orbit this time, with monoprop to spare - though I needed it during reentry to keep the capsule oriented.

Comment based on a quick test: The cargo bay's floor needs to be lowered, just slightly. (Helmets clip into the closed doors, even when right against the core.)

Best page I know of is probably here: https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering Though you should probably check out this section as well: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax#mod-dependency-checking However, it's best to think of ':FOR' as something different than a conditional application directive - because it's actually unconditional. 'NEEDS' or the rest require the mod named to be there to activate. 'FOR' instead declares the mod. The only time you should be using ':FOR[modname]' is when you're the author of modname - because by using that, you've said 'this patch is a part of 'modname''. As such, it's rarely needed - but it is useful when mods are in sub-directories under a common folder in GameData and have no DLLs, or if you're making a large pack of parts and want to organize them into sub-mods internally in KSP for various reasons. The single most common bug I've run into when looking at mods is miss-using the ':FOR' directive. And it is a headache-inducing error, as it causes *other* mods to misbehave.