DStaal

Even then, there's multiple possible paths - There's a good argument for floating cities on Venus instead. (A bubble of breathable air would float in Venus's atmosphere right at around the 1atm pressure/20-25 Celsius range, which conveniently is a fairly wind-free zone. Build a blimp with the living areas inside, and it would float right at the habitable range. It's a viable method to terraform the planet, and arguably would be easier and better than trying to terraform Mars.)

As an alternate idea to the above (and somewhat tongue-in-cheek): Wait until there's a sale at GOG, then buy and play that version. While they have an automatic game-downloader tool, you aren't required to use it for any of the games bought through them. I'm playing in 1.6 - I've had minimal issues running using the 1.5.1 versions of mods.

The update for this posted to SpaceDock contains HullCameraVDS instead of Haystack.

MOLE has one as well, IIRC.

Well, the only real reasons we don't use atomic engines in real life so far is because of treaty limits which would cause an uproar, and that for the trip to LEO they aren't that useful, nor are they all that useful for small probes. (As there's a high minimum mass to the engine.) If you scale up to where you can afford the mass for them, they're really the universal choice if you can get past the politics. (Well, you might be able to use solar/electric in the inner solar system, but the burn times for that are huge.)

Both of those should happen after the catch-up... However there is a gotcha on the catch-up: It happens in 6-hour chunks. If you don't have storage for everything for at least 6 hours (and I recommend 13 if you're using the logistics distribution), then you'll run out and recover repeatedly during the catch up. So add some bigger batteries if EC's the problem.

Honestly, all of the ones you've mentioned I believe work just fine already in 1.6. I tend to go with the latest version unless there's a reason otherwise. Personally, I copied my GameData folder over from 1.5.1 to 1.6 (minus the Squad folders) and haven't had any new trouble... Though there's probably some mods I have installed that I haven't actually hit their use-case yet.

What type of gameplay are you looking at adding? I notice you have Pathfinder - I’d add MOLE for the early orbital-science experiment labs. (And the *extremely* useful parts - even if they don't look all that different.) But beyond that, what are you thinking? Life support might be an option - Pathfinder/MOLE's home LS is Snacks, but you could also work with TAC-LS or USI-LS. (Thought the configs for that under Pathfinder/MOLE need updating.) MKS has a complex supply chain - but Pathfinder is developing it's own as well. If you're looking for just parts that are different, you can take a look at Kerbal Flying Saucers - It's technically pre-release, but it's fairly stable and integrates well with other WBI mods. (Though the engines are late-game parts, intentionally.) There's lots of things interesting - but it depends on what your interested in.

If you're going to rely on CCK, it's easy: Add 'cck-lifesupport' as on of the 'tags' in the config.

Interesting. I've been pretty CRP/MKS centric, but I'll be keeping an eye on this.

I'd say the games it supports are Windows-only, except that I play some of them and find myself locked out of some mods because of it... As for Proximity and Total Time - check to make sure you've got the latest version (and that there hasn't been a new maintainer) and that the version you have is for 1.6. If it's not for 1.6, likely it's just that the mod loads but is broken in the new version - you either need to wait for an update of the mod, or look in to updating it yourself. Or look for another mod that does something similar, but is updated. I know Total Time is being maintained by LinuxGuruGamer, and he hasn't updated it for 1.6 yet. (However, I was seeing that issue under 1.5 - I just was having enough *other* issues with my 1.5 install that I didn't track it down to report it.) I don't see a current maintainer for Proximity.

I've heard good things about Nexus mod manager, and wouldn't want to dispute that - But I can't run it, since it's Windows-only from what I can tell, and there's going to be a fair share of other KSP players who can't run it either. So supporting it would just be more overhead and hassle (even if it's minimal) for mod authors. The MM errors are listed in the KSP.log file if you're interested in tracking them down for mod authors. In most cases they'll be because MM started throwing errors and ignoring some syntax instead of silently ignoring the syntax - which means the actual behavior of the patches hasn't changed, it's just that MM is telling you about it now. (The main culprit has been multiple FOR/BEFORE/AFTER blocks, which all declare what order the patch should be applied in. Since a patch is only being applied once, having multiples doesn't make any sense, but was fairly common as people had trouble understanding what was going on.) If the errors are yellow they can be ignored if you want.

For most, that would be a *third* avenue of release, and one that doesn't support all the platforms that KSP is available on. (And may not support the platform they play on.) CKAN gets enough flack, I doubt this will gain traction.

Also note that pure-parts mods will mostly still work. Wheels have had a major re-fit so none of them will work, and there were some changes to the aerodynamic model - but the latter doesn't affect most parts. Pretty much everything else should work, if it's just 'import a part model with these specs'. (Localization was also a major change, but it's opt-in, so older parts still work.) So the main mods you need to look for are ones that use a DLL.

You're running into a limitation of the KSP game engine: There is only a 2km bubble of the world actually in existence at any point in time. Anything outside that bubble doesn't actually exist - it's just recorded and it's trajectory computed. Mechjeb or KOS can't operate on them as they'll drop out of the simulation. (And as an addition - anything 'in flight', that is in an atmosphere, will just be deleted once it drops outside that bubble, as the trajectory for an unpowered debris is the ground. Note that you can't switch to another craft if your current craft is under power, which it would need to be for sustained flight.) Your options are to either keep both within 2km of each other for the necessary burns for the core to orbit and the start of the recovery, or to use FMRS to work around the issue by doing it's timeskip trick allowing you to control each piece. If you want to go with the 'keep both within 2km' option, it's doable - basically you need the booster to have enough fuel for the entire gravity burn to orbital altitude, plus it's landing. Don't detach the booster until just before the circularization burn. You can likely do the burn manually and then immediately switch vessels back to the booster for re-entry and landing - depending on the length and amount of the burn. No mods needed for this, it's just timing dependent - and you can't do it with boosters discarded at other points in the launch, due to the KSP's game engine's limitations.

I think he's confusing FMRS with StageRecovery - StageRecovery is a bit magical, although the magic is reasonable. But if you're dropping stages in atmosphere you need FMRS to be able to do the 'two flights at once' needed to do the recovery. If you're dropping stages outside the atmosphere, in theory this could be done without mods. (Drop booster as you leave the atmosphere, circularize payload, switch to booster before it re-enters, fly it back down.) But you'll have to manage your flight profile carefully.

You always manage the 'now why didn't anyone think of that before?' mods.

And fourfa's post reminded me of another: MOLE has a combo chute/RCS part in the 0.625 size. (Designed to fit the main MOLE pod, and to go with the combo docking port/drogue chute in the mod.)

I finally got around to looking into something's that's been bugging me (that there weren't any fuel tanks), and found something odd... As far as I can tell, the fuel tanks will *only* have fuel storage if InterstellarFuelSwitch isn't installed. Fuel capacity is added in as a part of MM/StockTextureSwitch.cfg, which only applies if InterstellarFuelSwitch isn't applied. TextureSwitch/NSS_MM_FSTextureSwitch2.cfg, which is the InterstellarFuelSwitch patch, only applies textures, not fuel. StockTextureSwitch.cfg also *only* adds LF/Ox fuel to the parts, with no option of LF, Monoprop, or Xenon - all of which have engines. Unless I'm missing something entirely?

Someone else who reads the thread before starting! Yay!

Neither this mod nor MKS would allow those on their own - but MKS is designed to work well with KIS, which is what you need to do both of those:

I found them - they're in Dr. Jet's Chop Shop:

Inline Ballutes aren't exactly parachutes. They're tuned more for the reentry phase, to help you avoid heat shields. (I've used them for areobraking on ships that weren't atmospheric capable...) And RealChute is a complete parachute overhaul. I don't have the time to find it at the moment, but there is a mod which has a modular parachute system: An inline mount, and which holds specially designed parachutes (there are multiple sizes, listed by weight) and drogue chutes that fit into it. It's my go-to for when I want real inline parachutes at this point. (And I don't feel like dealing with RealChute.)

Ok, let's start small here. You need to mine ore. This is a decent first step towards a colony - as it's a first step towards making fuel, and a refueling depot is a good starting point for a colony. To mine ore, you need a drill, and a tank to put the ore in. A drill requires EC, and generates heat. Therefore a minimal mining station has the following parts: Drill Solar Panel/Fuel Cell/Reactor Ore tank Radiator You may want to add an ISRU as well, and tanks for output LOX/Monoprop, as ore isn't all that useful on it's own. That will take more EC and radiator capacity as well. (And yes, Ore isn't needed in any MKS production chains - but MKS doesn't add a production chain for fueling your rocket, so Ore is still that chain.) Now, you're using MKS, which adds more of all of the above - but in the end pretty much any will work, as long as they're sized to work together. From an MKS standpoint, the main question you have is: Will the base start out manned, or not? If it's unmanned, look for the automated drills and ISRU. They get better efficiency without a Kerbal, but don't improve with a Kerbal. If it's manned (or you can put up with very slow mining for the contract and will send Kerbals later) you'll want to look at the other drills and ISRU's, as they are more efficient with an Engineer/miner in place. However, then you'll also want to add some workstation with a seat to the mining station. (If you're starting unmanned and going manned, one of the Ranger series airlocks is a decent choice - just note that if you're using USI-LS you'll want to add habitation to the site when adding the Kerbal to the site.) On the separators: MKS doesn't add a drill for every resource it uses, as that would be a huge number of drills. Instead, each drill can be changed to separate out a specific minable resource - so you need to set the separator to 'Ore' for your ore contract. This can be done in the VAB for free, or out on site by an EVA'd Engineer for a small MaterialKits/SpecializedParts cost. You never see what's separated out otherwise. (Except if you go through the 'Dirt' chain, which adds a step, and is inefficient. But often useful in early stages.) I hope that gets you pointed in the right direction.

I believe what Angel-125 does is *change* the amount of KIS space - not add or remove it. That is, the volume is very low unless it's in KIS storage form.