DStaal

Bon Voyage requires the craft to be landed and have at least 3 wheels on the ground before it will attempt to operate. It's explicitly for rovers.

Looks good. (Haven't actually started KSP, as that takes ~30 minutes for me, but I like the restructure. Thanks.)

The suggested change would actually help a lot - I understand the point that's is a small group who actually get impacted by this, but at least then it's only one level of checking, instead of having to dig multiple levels. (USI and WBI both do something similar - one high-level folder, and the separate mod folders inside it.) The settings inside the mod folders I recognize I'm arguing against the wind. Pretty much every mod that keeps mod-level settings (as opposed to save-level settings) stores them inside the mod folder. I can see how it likely evolved that way - but I still think it's *wrong.* Settings should be stored separately from data, so they can be kept while data is updated, and vice-versa.

MacOS. By default, if you copy over it's *replace,* not merge. (There is a way to get merge, if you're aware and remember it.) Which is good for mods 90% of the time - If the mod changes internal organization, or if it drops files, they'll get removed, so having a cleanup is a good plan. It's just there are a few mods like this out there. (And there are the mods that store settings inside the mod folders.)

Whatever design works best - I was thinking basically use a handmade clamshell fairing covering the entire payload (which can then be re-closed for reentry) but if you can make something smaller that works, that would be good. (If it's just the docking port and not the whole thing, you might see if a shielded clamp-o-tron helps. A larger clamshell would only be needed if you actually need to make the whole center fuselage aerodynamic.)

How about a robotic clamshell using Breaking Ground hinges and structural panels? Would that be able to shield the docking port?

You might want to take a look at this as a base to work from: Near Future Electrical also has a similar feature.

The plugin is part of the mod, if you have NFE installed and working, you have the plugin.

Is there a chance to move this and the Kip Docking Ports mods into separate directories under GameData? At the moment manually installing both is somewhat awkward. (Unless your system does a 'merge overwrite', you'll have to merge the folders yourselves.)

Honestly, if you're just having trouble with launches, try this mod: It's simpler than MechJeb's ascent guidance, an generally works better in my experience. It doesn't have all the features of MechJeb (and you'll still want MechJeb), but it does launches well.

Neat trick, I'll have to stash that someplace. (I could, but I don't think the rare use is worth installing homebrew at this point.)

Yeah, but `tree` isn't a standard macOS utility, and this was better than trying to come up with a set of screenshots in the Finder.

A quick question: Is this folder structure right? danieltstaal@MacBook-Pro GameData % ls -R NavyFish Plugins NavyFish/Plugins: Docking Port Alignment Indicator ToolbarIcons DockingPortAlignmentIndicator NavyFish/Plugins/Docking Port Alignment Indicator: DPAI_RPM.dll PluginData DockingPortAlignmentIndicator.dll RPM Configs DockingPortAlignmentIndicator.version moduleDockingNodeNamed.cfg ModuleDockingNodeNamed.dll NavyFish/Plugins/Docking Port Alignment Indicator/PluginData: DockingPortAlignmentIndicator NavyFish/Plugins/Docking Port Alignment Indicator/PluginData/DockingPortAlignmentIndicator: DialogPlain.fnt alignment.png prograde.png DialogPlain.png appLauncherIcon.png retrograde.png RPM_background.png directionArrow.png roll.png RPM_helpscreen.txt gaugeBackground.png targetPort.png RPM_mainscreen.txt gaugeForeground.png NavyFish/Plugins/Docking Port Alignment Indicator/RPM Configs: DPAI_RPM_BasicMFD.cfg NavyFish/Plugins/DockingPortAlignmentIndicator: PluginData RPM Configs NavyFish/Plugins/DockingPortAlignmentIndicator/PluginData: DockingPortAlignmentIndicator NavyFish/Plugins/DockingPortAlignmentIndicator/PluginData/DockingPortAlignmentIndicator: NavyFish/Plugins/DockingPortAlignmentIndicator/RPM Configs: NavyFish/Plugins/ToolbarIcons: DPAI.png Note both `NavyFish/Plugins/Docking Port Alignment Indicator` and `NavyFish/Plugins/DockingPortAlignmentIndicator` directories.

It works with any resource that's transferrable and has storage with the modules enabled. As nothing in the USI mods use any of those resources they don't provide parts which handle them - but there's nothing stopping you from creating an MM patch to add the modules to a part which can store them, or to add those resources to a part that has the module.

(Or remember that USI-LS is actually a separate mod, and don't install it...) MKS should cause no problem mid-save. USI-LS - no problems if all your Kerbals are on Kerbin. If they're out on missions, they'll probably start wanting things like supplies and living space they don't have.

They had test versions built before we got to the Moon.

There are lots. What size/shape are you looking for?

If you put them in CRP mode, they'll have storage for the resources, but there's no support past that at the moment that I can recall.

I think MechJeb can do this. Been a long time since I looked at it's launch modules however.

Each type of command pod has it's 'forward' in a specific direction. You need to make sure you have one pointing the way you want it before you launch... Three solutions for you: Send up a small probe core or docking port, attach it with an an Engineer and KIS. (Docking ports always have prograde as their face, to help you dock.) Install TCA, and use it to land. (It will ignore the 'forward', and work with the direction the engines are facing.) Land anyway! It takes some flying, but I've done it...

And to be Restock-compatible, apparently. Sounds like something you could submit to:

No. KSP doesn't work that way - ships not in the current physics bubble (of a radius about 2km from the current ship) are unloaded and take no actions. If they're orbiting something, they'll continue in the same orbit. If they are landed they'll get reloaded in place. (Likely moving a small amount when the terrain and their location regenerates.) If it's flying in atmosphere, it will crash. There are some mods that modify that, but no mod allows the ship to do multiple actions when not in the physics bubble. They either move the ship (along a mod-determined path that really doesn't exist - they're just moving where it will re-create next time you visit it) or they hold the ship in place. In both cases all the mods really do is modify the ship's location, they still aren't taking actions.

Picures, logs, etc. will all help people understand what's going on.

I just wanted to say: I haven't followed the development of an upcoming game this closely since EV: Nova. You've got a lot to live up to here.

I think we're probably getting a bit off-topic - but I do want to point out that in one of the early interviews Nate referred to 'the refactor', and implied that it became much more than a straightforward refactor. Which says to me that they intended to keep most of the same behavior, just cleaning up the code, but have found themselves going much further than that.