DStaal

This isn't a great shot of it, but in the foreground you can see a Konstruction build utility vehicle in this: The main base itself was sent up in about half a dozen pieces and assembled from there using Konstruction ports, with some KIS usage where needed. For reference, here's how that base started:

The trick here is that the UI works the same way in either the VAB or out in the world: You have two buttons, one which allows you to cycle which drill head to switch to, the other to perform the switch. (And you can switch through all of them one by one, if you want by just pressing the switch button over and over.) The 'resource1=>resource2' button, if it's the one I think you mean, is the button that actually performs the switch. You switch from the current resource1, to the intended resource2, directly. The other button allows you to switch what 'resource2' is. The reason for this is that when you *aren't* in the VAB, switching drill heads costs MK and SP. And you obviously don't want to pay that cost more than you have to - so you don't want to cycle through options, you want to go *directly* to the option you want. So having the two buttons allows you to choose which resource you want to switch the drill to, and then switch to it. In the VAB there isn't a cost - but the mechanics are otherwise exactly the same.

Recovery percentage is completely dependent on the distance from the launchpad/runway. I think Kerbal Konstructs can add more launchpads, and allow them to count for that distance calculation - but basically the counter is to land as close to the KSC as possible.

Fair enough. Just wanted to mention it as an option if you hadn't thought of it.

Yeah, might want to switch to the BS 13623 (British) standard instead of the NEMA 15-class standard type plugs you've got.

Nice. Are those plugs going to be compatible with SEP's plugs?

The 'Classic Stock Resources' configs from Angel-125 override the 'Community Resource Pack' configs for ScanSat. What you need to do is remove this file: GameData/WildBlueIndustries/ClassicStockResources/Templates/Utility/Scanners_SCANsat.txt Then you'll be able to use CRP resources again. I'm not sure if this is the best design decision on @Angel-125's part, but on the other hand I do see that with ScanSat's limited number of resources there aren't enough resource ID's for both the CRP resources and the Classic Stock Resources. Maybe this should be a Patchmanager config? Either way, know that they don't play well together, and changing the setting in the WBI control panel doesn't change which resources you can see in the world.

I just want to say - that's gorgeous.

That's another mod entirely, OSE Workshops:

Also worth noting is that the KSPedia entry for Scansat has images of all the VAB information screens for all the parts. So you can pull them up there if you need to.

They aren't actually all that large. And IRL, it's quite possible that the price increase (miniaturization) of going smaller wouldn't be worth it, especially as there may well be a reliability/maintenance question as well.

Sounds good to me. Thanks.

On one hand, I like the feature, as it will remove that huge list of mods at startup for me. On the other hand - it's a bit blunt. Those overrides for instance - 95+% of the time, they'll be right. But there have been cases in the not so distant past where a few mods would break on a point upgrade, so that blanket statement wouldn't be correct. I'm trying to think of a good 'except these mods' syntax, but I'm not sure what it would be.

Is there a receiver on the vessel? I don't see one. Power isn't just sent to all nearby vessels - just all nearby vessels able to receive it. Another Power Pack (even without fuel), or a power coupler, even a fuel cell will have the receiver. (Among others.)

Yep, that should work. They might even take the supplies from your rescue ship directly if you get close enough. (They will if you're landed - I'm not sure if that's been disabled or not for orbiting ships.)

Yep, that sounds like fuel flow/priority issues. Fuel won't automatically flow through radial nodes, or KAS pipes. Other resources might, depending on their settings.

One note: KAS pipes support fuel transfer, but not fuel flow, so fuel doesn't flow automatically through them. On the second: Yep, you're totally making that up. You can switch in the editor between resources for free, but out in the world they cost MK and SP.

Yeah, if you haven't had anything using it, know that USI-LS uses EC. I thought to mention that when I was planning the post, but forgot to put it into the post. You could mostly balance the RCS by adding thrusters near the edges of the side cutouts. (Or completely balance by moving the current roll control thruster inward to the side cutouts as well.)

For the interest, I downloaded a copy off of Github, and tried it out. Launched to low-orbit (80km), and returned. Thoughts: The combination of unbalanced RCS and no reaction wheel makes it extremely hard to keep oriented. My de-orbit burn ended up being done in ~5 pieces, as I had to re-orient between each one. I did run out of monoprop - but only after I'd reached a return orbit. A bit better flying and it might not have been a problem at all, even from a higher orbit. (But note this capsule is hard to fly at the moment...) The capsule (plus stock 1.25 heat shield) oriented itself pretty well on re-entry. Which was good, since I was out of monoprop. On the other hand, I *barely* had enough EC to deploy the parachute, and I deployed at a higher altitude than my personal preference. From a higher orbit, I'd be seriously worried. Perhaps a bit larger batteries? The parachute obviously needs work. (I didn't actually manage to land - as the parachute summoned the kraken and put me on an interstellar trajectory.) I used about 25 units of ablator on reentry - though that was a shallow reentry from LKO. Still, even from reasonable high orbits 50 units should be plenty, I'd think.

This mod and the mod you linked to are entirely independent. This mod creates a toolbar, which mods can put buttons on. That mod makes it easier for other mods to allow options to the user on where buttons should be placed: This mod's toolbar, or the stock toolbar. That mod is a required dependency for many mods. This mod is almost entirely optional: If you want the floating toolbar, grab this mod. If you want everything in the stock toolbar, you don't need it. (I think there might be one or two old mods that still require this mod and are updated, but only a couple.)

A pure stock alternative is to use a claw, and retrieve the entire part. But Rescue Pod Validator is designed for this, if you don't want to go through trying to build something to bring down some huge part just to rescue one Kerbal.

First off, the inflatable storage module is a special case, so none of the normal MKS inflation rules apply. Second, there are two things you're going to need to inflate that module: Number one, is that you're going to have to send someone - an engineer - on EVA. They can then inflate the module from outside. Secondly, you're going to need MaterialKits. (Also EC, but you have that.) MaterialKits are used to provide the structure and interior of the inflatable module. Now, you don't actually have to have them all there at the same time - you can do multiple inflations over time, and your Kerbals will 'partially assemble' the inflatable each time. (Though it won't be usable - or change appearance - until it's fully assembled.) Also, you don't have to actually have the MaterialKits onboard - they just have to be nearby, in a container with logistics enabled. Then your Kerbals can scavenge them and put them into place. Storage modules are immune to all this because they're just empty shells, so there isn't really any needed interior. (Also, it means you can use them to hold the MaterialKits you need to build the rest of the base, and gather portions of it by disassembling unneeded parts from landing rockets and the like.)

On the other hand, our perception of the Kerbal world is filtered not only through our own senses, but through our limited interface. RGB monitors can produce a respectable subset of the colors humans can perceive, but it's only a subset - and if Kerbals can see more colors than we can, our monitors likely wouldn't be able to project those colors anyway. Personally, I'd say there's a reasonable chance they have different color vision than we do. At the very least, they probably shift towards more differentiation in the greens, given the coloration of their world and themselves.

Sounds good to me. Ablator is rarely a concern, really. (Though it would be 'realistic' to not have more than needed, as mass savings.) D/V and EC are the main limiters I've found using REKT and USI's escape pods. (Less so on USI - the pods are more expandable, though they don't look as nice and are harder to use, especially in conjunction with CLS.) Figure you need at least enough EC for a full orbit at the top of the design altitude. (Which will give a bit of margin. On the other hand, some LS mods also use EC per Kerbal...) I like the exposed idea - even having a couple of (red?) parachute packs entirely outside the 'main' pod profile - as long as they fit within the cradle. (These pods will be awesome with a cradle, IMHO. I can almost see them launch from a nearly-sleek ship...)

Nice to see it's got traction in your head. Some design thoughts, based on playing around with @steedcrugeon's REKT: You could if you really wanted add in some conformal solid-rocket de-orbit engines, but regardless you really need RCS for clearing the vessel you've just escaped from, and then re-orienting to a reentry profile. Think about the 'design altitude' of these - How high an orbit do you expect to be able to return safely in them from? REKT tends to work well in LKO, but barely has the d/v for more. These to me look like they should be able to handle 'low high orbit' - the 250-500Km range where things are still 'close to Kerbin' but count as 'high orbit' for science recovery - which I find is a useful place for a station. But note that the pod will need appropriate d/v, EC, and ablator for returning from that altitude. Control - they need a probe core, so non-pilots can use them. Which means EC - but see above. How long does it take for the pod to detach, enter the atmosphere, and reach parachute height? It needs enough EC to last. All of the above assumes you're somewhat near Kerbin - or maybe Duna, Eve, or Gael or something. Do you want a deep-space version? You could swap the heat shield with a life-support pod + solar panel. How about an airless world pod? Those need a *lot* more d/v - the REKT can barely squeak to a Minmus landing on it's own. (REKT also has a cryo-pod, which is interesting - but Deepfreeze's EC requirements cause some issues. I loved the docking nodes you showed in other thread. If you go for them, it'd be nice to think about outer diameter. (Though it sounds like you are.) Another quick thought: You could add the de-orbit engine to the heat shield. Have them poke around the edges, and it would keep flexibility and staging correct. (I'll admit I'm thinking the base pod and some bottom extensions at this point - heat shield for atmospheric, emergency life support for deep space, and possibly a lander of some sort for airless worlds. The last would be the hardest to design and balance.)