DStaal

Here's the patch I use: @PART[ALCOR_LanderCapsule]:HAS[MODULE[ModuleConnectedLivingSpace]]:NEEDS[ConnectedLivingSpace] { @MODULE[ModuleConnectedLivingSpace] { @impassablenodes = none } }

Pic of the base?

The models for that greenhouse were released for fairly wide use by zzz - There's a mod that adapts them for USI-LS as well.

USI-LS Nom-o-Matic.

Warypoints are a stock feature, I believe, so there should be some way to set them in stock. I find a combination of ScanSat and Waypoint Manager works well.

That's definitely in the 'supply a patch and RoverDude will include it' camp. I think there's an old patch in there, but I'm not sure how well it works at this point. MKS is definitely made to work best with USI-LS, but aside from Kerbalism I don't think there's any reason it couldn't support another LS mod - but RoverDude has plenty to keep himself busy with stuff he *does* use, so anything else would only be supported if someone else submitted it.

Yep. Well-known issue: Inflatable parts and KIS inventory don't mix well. My latest base - made mostly of Ranger parts - has several KIS containers sitting on the ground outside just for this purpose.

That will work until you update any mod or change any file in GameData. Then the ConfigCache will be outdated and will regenerate from the source files. Better would be to do the same via an MM patch.

Catch-up runs the vessels in the current physics frame with all models and physics in a reduced mode, from what I understand. Background processing would run *every* vessel, all the time. If your game slows down when you enter the range of one of your bases, think about what it would do if you were in range of *all* of them.

Nope. It gets processed in 6-hour batches - but it will do as many 6-hour batches as it needs to to cover the time you were away. So as long as you have enough space for each batch, you can stay away for as long as you want. (Which is where the 13-hour recommendation comes from: PL will only half-empty a container, and you need 6 hours of *empty* storage during the batch, because PL only fires once per batch. So 13 hours worth of storage means you'll have enough storage free to perform each batch, with a small margin just in case.) Not yet. Planetary to space is part of whatever RoverDude's working on.

IIRC my build for that - there should be the one attached directly to the base, and the one attached on the outside of the mini-hab. Intended deployment is to put the anchor hub out near the one directly attached, and then pull the one off the mini-hab and use it on the anchor hub. Note that to detach you need to open your Kerbal's inventory, hold down 'g', click on the tube, and drag it (without unclicking, ideally) to a spot in the inventory. There isn't a button.

I actually have a request on this, since the topic's come up... Currently the standard is: GameData/<ModName>/PluginData/<files>. This has the benefit of being easy to install, but has severe disadvantages when upgrading, and it's easy to inadvertently delete all your personalization data, saved information, etc. It also complicates the 'clean install' instructions of 'remove the mod's folder, and replace it with a fresh download', in the cases where the mod uses persistant data that the user might want to keep. I would like to propose the use of this format instead: GameData/PluginData/<ModName>/<files>. This is slightly harder to install, as you may need to merge PluginData folders - but only slightly. And it gives great advantages in upgrading and replacing mods, as the PluginData folder will naturally be preserved. (And for the truly clean reinstall, it will only add a slight additional piece, in removing the PluginData sub-folder.) Overall, I think this would in general reduce the load on the users, as the upgrade action is preformed most often, vs. the install 'truly clean reinstall' which are performed only intermittently.

There's a couple of possible bonuses you could be referring to - If you mean the Kolonization bonus that gives passive background effects, then space stations do count, and pretty much any MKS part will help it accumulate. If you're looking for the Kolony Rewards that you can get, which are partially based on the Kolonization bonus, then you need to collect them from a Pioneer module. (I haven't tried collecting them from in space myself. I'd think they should be possible, but I can see them not being either.) And space stations around Kerbin would count towards Kolonizing Kerbin - which can't be Kolonized because it's your home.

(Sorry I didn't get much time to KSP yesterday...) Yep. Though I could get you a list from the KSP logs: And I'll look into it more deeply eventually - Just warning that it may not be soon. (KSP debugging time goes to KPBStoMKS at the moment.)

You'll probably want to start here: Though note it basically doubles-down on the parts in multiple categories - it allows you to create your own categories, and by default will have multiple overlapping categories. It makes it easier - IMHO - because you can find a part whichever way you think of it.

Probably - but honestly, at 160+ mods, a half-hour startup time, and this ship (while nice and fun) not really fitting into my current career, it's likely to be low priority...

I'm having an odd issue in the last couple of releases: This is on entry into the SPH - it doesn't appear to affect the VAB. Note the one part embedded in the floor and the lack of *anything* in the button bar. (And the lack of blizzy's toolbar...) If I remove the Coyote Space Industries folder from GameData, everything is normal. Not sure what's going on.

For early game, my solution would be to only have antennas for communication to ground stations really - although from my understanding if every antenna is on the same channel, the end effect is that the game behaves exactly as stock: You can relay through other ships on the (universal) network, or just talk to home.

I use a radially attached part to know where the 'front' of the DIY kits are - orientation I believe is the same as the ship in the VAB. Which I think is your issue with the tall kit - orientation directions change between the VAB and the SPH. You've got a kit that is building a ship designed in the SPH, and the kit was built in the VAB, I believe. From my experience, this is a temporary problem as the ship will be oriented correctly upon launch/finalization. (Which is going to be a problem for you, as that is going to hit something when it finalizes I believe... Whether the Ranger modules or what I assume is a mining pod, I'm not sure.)

Just to add to the above: Install the most recently updated *last*, and have it overwrite anything that it needs to. That way you end up with the most recent files. (But typically if you grab the most recent version of USITools and install it last, you'll do fine - it's the main 'common dependency' across all of USI.)

As far as I know - not really. There are some ways to add/move bases on Kerbin - but only at KSP load, not anything dynamic. (And they all operate as if they are one base.)

Is it configured for KIS storage? (It's normal for it to have 0L capacity when it's not in KIS storage mode - KIS can't handle storage being added or removed from a part at run-time, but can be made to handle it being changed.)

Looking good. I'd love to be able to roll up the different sections in the control panel - but that's a minor request at most, it looks fully useable here.

A possible template to look at for that would be the Karborundum+Ore fusion drives in the K+ pack. And because I'm seeing it again, and I’m not sure where it's coming from: Adding a resource to KSP does not require a dll. It hasn't since Ore became a thing - RoverDude wrote the KSP resource system to handle arbitrary resources in .cfg files. (But I agree, adding your own resource is a lot of unnecessary overhead if you can find another way.)

The way that would work is to have the parts that extract/refine the resource appear late game.