DStaal

And I have at least one mod that includes a passable one. (Or optionally passable at least: NFC.) But if it wasn't designed that way, why should it be? Sure it *could* be designed that way - but a lot of things are easier to make if they aren't designed for that, and there's no reason why the designers had to build it that way. (And: It would be *safer* to not design a crew tube through a spinning gyro...) For this type of situation I use a radial probe core - it's an extra bit of computer, which makes sense to me. But anyway, as I said: Different philosophies. I tend to be fairly conservative about which parts should be passable - and depending on how I'm feeling about it I may even write in full restrictions. (The 'BuffaloCLSHack.cfg' is an exception: It's easy to accidentally build a Buffalo rover that's attached through the frame instead of through the main body, so I made the frame passable just so I don't have to worry about which attach nodes are being used.)

Here you go: https://github.com/DanStaal/KSP-Configs/tree/master/CLS But I can tell you and I have very different philosophies on CLS support - I'd assume the picoport and the 2.5m probe core are impassable and design around that, for instance. To me if you're just going to make everything passable, why bother installing it?

On the first: I'd probably add a line saying 'passable = false', just to be sure the module is fully initialized. (I personally have about twenty personal CLS patches - although some of them have been incorporated upsteam by now, as I do tend to submit them to the authors.) On the second: Not that there are *two* connected spaces in the list on the right: The two buttons the width of the UI window. I'm guessing there's something in between the the Orca and the habitat that isn't CLS enabled - so therefore it's not part of the same connected space. (It should be visible in the other connected space.)

I've read that. Still didn't understand your objection. Wanting to learn.

It's on every part with a 'ModuleConnectedLivingSpace' module - even if the part has been marked as 'passable = false'. So you need to add that to the parts. That looks good to me. You say it's working, is that a typo? If it's working, there should be no problem. Do *not* use FOR, unless you're sure you know what you're doing. It doesn't mean what you think it does, and mis-use of it is half the issues I have when installing mods.

I do find it interesting that you refuse to use a mod because of *two* parts that you could remove from it. (I'm assuming the parts you have issue with are the antigravity pads - if you have problems with other parts I'm confused.)

Vessel B needs storage for ore. Local logistics can pull ore to it, but as far as I understand PL requires *attached* storage. I sometimes manually initiate the local logistics transfer to the vessel doing the push to PL as well - If there's no demand on that vessel for the resource, automatic local logistics won't kick in. I might actually just attach a KAS pipe between vessel A and vessel B, if it were me. Simpler all around.

Most common reason for this problem is accidentally attaching the tubes backwards. Worth double-checking.

My solution is to design the station with a docking section and expansion sections - the docking section gets normal ports, the expansion sections get construction ports. Or you could just use construction ports everywhere.

Quick note: The config for the BOMP-L makes it a probe control point - not a probe itself. (Been looking for an excuse to use these, but so far that's been the size I've been needing.)

I don't think there is a way to identify on the mod level - however, if they've specified a manufacturer or have a coherent naming scheme on their parts, you can use that to filter.

Up to you. It was one of the first mods I installed, so I can definitely say a newbie to the game can handle it if they want.

Well, if you want to put up a list I'd be willing to take a look. It'd at least give a starting point. I will admit my testing so far has been with the XLs, mostly because that's what I was working with.

Also: It might be worth deleting your MM caches. It'll mean a bit longer startup next start, but they could influence this as well.

The other thing I can think of would be if you installed a tech tree mod - especially if you installed or removed it after you started the career. CTT is usually safe from this type of stuff, but it's at least messing with the same things.

It's definitely something that's handling EC differently - it handles fuels just fine (that I've noticed...), even in the Mission Support mode it handles Monoprop. It's just the EC it's missing. Anyway - if no one else is seeing it I'll chalk it up to some mod interaction - and put on my 'track this down when I get some spare time' pile. It's only really a problem for a very specific use-case, and even then I can work around it without much trouble. (Just sit on the pad a while...)

They play perfectly fine together. Near Future Electrical does contain a patch to switch USI reactors from their normal operation mode to working like NFE's reactors - but it can be removed without issue. With the patch in place, the two sets of reactors operate the same. Without it, they operate differently - which might be what you want.

You might want to take a look at USI's reactors - they behave the way you want, providing only as much power as needed. (If you have both them and NFE, you may want to remove the NFE compatibility patch to let them use their own mechanics.)

Hmm. I can think of a couple of ways to turn it into a challenge - either issue each part as a separate section, or do a whole-list challenge and pick favorites for each section. I'd argue for a challenge what would need to be provided would be good, well-lit photos of each stage of the base: Starting at just landed, then any/each deployment phase. Bonus for craft files.

I note the 2.5 ring decoupler doesn't have CLS support - you need help writing the config?

Per a recent discussion in the main MKS thread, I was wondering if people might be interested in working on a tutorial/walkthrough. My idea would be to step through setting up a self-sufficient colony on Mun/Minmus using multiple base sites - and having different people work on the different base sites. Point being both to spread out the work, and to make sure the bases aren't all built in the same style - this way we can do a better job of showing that there's more than one way to do things. Reason to do it on Mun/Minmus is both to make it easy to work on, and to make it a 'first step' for new players - the idea being that if they walk through all the parts, they'll have a good base to work into the rest of the system, while also being close enough to 'home' to be able to recover from mistakes. We of course would want to make sure we touch on all the main mechanics of MKS, but part of the point of doing separate bases is to show that you don't always need/want *all* the mechanics in play at every location. As general scope, I'd think of the following progression: A medium/term scientific outpost. (MPL and Ranger habitation+recyclers, supplied from Kerbin initially, grows to include a greenhouse?) Mining outposts - starting out unmanned, grows to manned. Industrial base - second-level resources, grows to third-level. Colony Hub - long-term colony staging and supplies; Med Bays, full-scale food production, etc. Might want to do a dedicated mobile GC-builder and/or Lode Harvester in there as well. Thoughts? Good idea? Bad? Something people are interested in working on?

Just wanted to comment that I made the changes for this in the patch we're pushing upstream to KPBS.

The incremental (á la EL's incremental builds) sounds like a good idea to me: it models the act of kitting it out over time, instead of doing it all in one frenzied moment. I suspect it would be a lot of coding work to implement however. The giving the storage in the part itself doesn't make sense - as the whole point is that they are *collapsed* and not taking up the whole volume they enclose, so saying they should still hold the materials that would be in that enclosed volume is a bit non-sensical: It doesn't have that volume yet.

Um, quick question: What's the *expected* behavior when you delete files from GameData while KSP is running? Because 'random weirdness' would kinda be my expectation...

Show us your GameData folder - I'm guessing something's borked in your install.