DStaal

Yay! Thanks. (Then I'll get on making PRs for mods to make some of these little things optional...)

Nice. Thanks. (Though I don't actually see a download for it on GitHub - there's source code bundles, but not a release bundle.)

Or it might be a joke. Best to ask in the Stage Recovery thread, since that's the mod you're looking at.

The two I was thinking of are: NFE has a patch to integrate USI's reactors to NFE production mechanics. I always remove the patch - I was going to suggest using this mod to help manage it. MKS has a patch to integrate with EL - I was going to split it into two (one for the resources, one for the parts) and set them up as optional via this mod. Another that immediately comes to mind is that WBI's Pathfinder has an integration patch with KPBS. Again, it'd be nice to make it easier to make optional. Or OPM's increase of the stock antenna's power. I could probably go on for a while, as I think of them. In most of these if Patchmanager had existed since they were created I can see them as would likely to have been using it from the start - but Patchmanager didn't, and adding it as a dependency to make the mod work as it has in the past will be more likely to cause issues to users. While I was typing this up, another thing occurred to me that might be nice (though is likely complicated...): The ability for patches to declare themselves mutually exclusive with another patch. (My MKStoKPBS set is incompatible with Pathfinder's integration, for example.) But I can see that getting really complicated to implement, and is definitely an edge case. The 'default active' I'd consider a more normal case - it means a mod can support this mod without requiring it.

Yep. Both I'd consider fairly normal - with or without KAC. (And yes, the latter would likely be because you left the thrusters running.)

Then you have to match all the animations to the same setting, and get the setting you want... preset angles is often easier in practice. On the other hand, this is a *rover* by design. If you want to move horizontally it's far easier and more fuel-efficient to just land and drive. I'd see rockets like this mostly useful for two situations: Initial delivery of the rover to a new planetiod, and occasional 'jumps' over otherwise-untransversable terrain. For neither of these do I see any pressing need to swivel the rockets horizontally - If you're close to the ground, you want to be both level and going slowly so you can land (or are just taking off from a likely slow/stationary start), and if you're not close to the ground then you can alter the angle of the temporary spaceship safely. In-game, in real life, and in model it's all easier and more sturdy to not try to swivel in such a manner.

Liking the idea. One thought, however: Am I correct in thinking that in the absence of PatchManager all patches will default to 'Not Applied'? If so, could there be consideration given to having a path setup that would allow the patch to default to 'Applied'? I'm thinking I want to submit PR's to a couple of mods to support this system - but I don't want to change current functionality if possible, and the patches that interest me on it are 'default applied - remove to unapply' patches.

I hadn't tracked it down to a cause, but I was seeing *something* causing me to not be able to control ships even on the launchpad with nothing but stock antennas. I just went in and disabled commnet...

Are you moving when you start? 1.3 has a bug where atmospheric resource gatherers don't work at zero speed.

Hmm. Not sure if copying it out of an old KSP version and posting it as a part 'mod' will be kosher - that's probably redistributing Squad's assets.

I'm guessing that's a preview of *this* mod: WBI already has a 'parts can break' option...

Without MKS, I don't think so.

Gypsum is a route to fertilizer in MKS, and Hydrates is an alternate route to Water. Both are essential resources for long-term colonization under MKS/USI-LS, and therefore have multiple routes to increase your odds have have one available on your planet of interest.

BTW: The 'Clamp-O-Tron Shielded Docking Port Jr.' doesn't have the right sized docking node in the .cfg - By the config, it docks to the normal clamp-o-tron, not the jr.

It's a carryover from KAS - basically it turns them into a version of the stock external fuel duct, IIRC. That is: fuel will automatically flow through it directionally.

No problem. I'm not sure what I want to be doing in KSP at the moment - I was playing a real career, but my contracts just reset for the second time so I'm a bit lost.

Have you activated it? It takes EC to run, so it only runs if you've turned it on, by clicking the 'Life Support' button.

This actually is sounds like the type of situation that AirPark was designed to handle:

I suspect it can get a bit finicky on the exact conditions around docking/undocking, as which ship you're flying can change as you dock/undock. This particular case was more of a staging issue - they staged away some habitation, so their current ship lost hab.

Unless of course they've already been stuck in the lander for a week on the way back from Minmus...

BTW: Which copy of RetractableLiftingSurface should we keep from the downloaded zip: The version that's in the top-level GameData folder, or the version that's inside the SHED folder?

The spreadsheet and video are actually on the wiki - albeit not from the an easy-to-find page. (Understandable - the page itself needs updating.) It's here: https://www.youtube.com/watch?v=a0oqO3xbswk As for what habitation models: It's the ability to stay sane while cooped up in a tiny metal box far from any kind of escape. The fact that home is just outside your window is useless if you can't open that window - 'cabin fever' is about being in close confines, especially with other people, and is known to affect people in far more hospitable circumstances than a spaceship. (Hence the common term - from being locked up in a cabin through the winter.)

I think you might actually be referring to Planetary Base Systems parts.

To further this: While running down an unrelated issue, I found some code in @Snark's Indicator Lights which grabs the installed professions and their effects: https://github.com/KSPSnark/IndicatorLights/blob/master/src/Kerbals.cs (I also added that link to the issue.) I'm not quite sure enough of myself to try to merge that in into a PR, but it should be fairly straightforward...

...And it's 'part', not 'name'. So, what should be a working patch: @RESCUE_POD_TYPES:NEEDS[KSPRescuePodFix] { part = rektkm1a part = rektmk1d part = rektmk1n } (Note: I've already submitted a PR to REKT on this issue - I'm putting this here as a 'better community docs' response. You should be able to copy the above into an MM file, replace the part names with whatever you want, and use that as a template for compatibility.)