Ringer

Yep, not using quantum struts would result in destructive ASAS anxiety attacks. I just tried another design -- with one port per 'arm' as you said -- and it worked! However, this required switching vessels and trying to give them the same roll, and a pretty lengthy, sub-0.1m/s approach. Due to the greater distance between docking ports, it's easy for only one arm to attach; I probably need the roll to match within a degree or two. Now to do this about 7 more times, or until my laptop can't simulate the parts anymore! Update: it starts lagging with just 3 of these

So I'm good with docking. I decided it's time to try something huge and needlessly complex. I tried THIS ONE and THIS ONE. Each is composed of two more-or-less identical vessels, meant to dock in two areas (with multiple docking ports at each). I was unable in either case to get all the docking ports to register as docked; pretty good alignment isn't good enough. I thought having more docking ports would shove them all into place, but the game has no problem aligning 3 ports on one 'arm' and 1 on another, even though the vessels are very rigid. It should work geometrically. In case it isn't clear from the pictures, I'm going for something a bit like this: DD DD DD DD || || || || ||===[]===|| ||===[]===|| || || || || DD DD DD DD DD DD || || ||===[]===|| || || DD DD DD DD DD DD || || || || ||===[]===|| ||===[]===|| || || || || DD DD DD DD ...where the D's are the docking nodes, and each H-shaped vessel is 4x symmetrical, viewed from the side (so there are two docking nodes between each connected vessel. I feel like I've set myself up for a good challenge here. I want to make a huge interlocked behemoth! Any thoughts on how to make them fit together a little better? Anyone else want to try along with me?

http://imgur.com/a/GwenY Here's what I just described. Let's see if it launches... Edit: The answer is yes, but it would cost at a good deal of fuel from my transfer stage to circularize the Kerbin orbit. Anyway, hope that gives you some ideas! Edit again: I did that anyway, performed the most wasteful orbital transfer ever (probably 1-2k dV in adjustment burns), and realized I forget landing legs, but it worked! The ISP of those nuclear engines is such a blessing; a bunch of dV to spare, landed on Moho. CHECK IT

The problems I've had with Moho involve the orbital transfer. Its inclination SUCKS; calculating the circular orbit transfer gives you Sun periapsis/timing far off from Moho's actual position, so the adjustment costs about another thousand dV. Since I don't know how to calculate the transfer better, I've always had to do this. There's a lot to be said for engineering a rocket's stages to have the right amount of thrust and dV, but I usually resort to the "more Rockomax" strategy. Since cost isn't an issue (yet), all that matters is being able to attach another stage that can accelerate up the one you already have for a little bit longer. So all that matters in that case is stability. I'd use asparagus staging for the transfer stage. Nuke engine stack in the middle, and two pairs of nuke stacks radially attached around it. If you get that into Kerbin orbit, you should be able to make the transfer and use up one of the asparagus pairs, leaving you 3 engines and (hopefully fully) stacks to adjust your transfer and achieve orbit around Moho. The final, central stage should be sufficient for a landing (I'm talking a one-man pod here though). For getting those 5 engines and stacks into Kerbin orbit, 4 Rockomax (orange) tanks with Mainsail engines, and maybe some solid boosters, should be well sufficient.

Not to mention you can't time warp appreciably fast below 600km. I used to put another vessel in a high orbit just so I could switch to it and warp to wait for an optimal transfer with the lower-down ship in question. These days I launch everything interplanetary to 600-650; it's a good enough place for a station as well.

Is it okay if I use MechJeb (only informationally, to determine phase angle)? I can even jettison the related part once I get to Jool, and delete the debris, if you want. I wouldn't use it for auto-pilot though: what challenge would that be!

Seriously, don't worry about fuel crossfeed. Even girders can do it. I have never thought about it, and I have never once docked things together whose fuel couldn't be pumped between them.

Fuel tanks just have to be connected in some way, as long as every part between them is 'fuel crossfeed capable'. Almost all parts are, including docking ports, so your fuel tanks can be pretty much anywhere. I should mention that you alt+right-click both tanks you want to use, as it took me a long time to find that out. I recommend your station: - Is on or near the equator, for convenient launches after refueling - Is on the flattest terrain you can find - Is on a very big deposit (Kethane converts to much less fuel) - Has lots of extra docking ports: you never know what you might come up with later - Has a lot of solar panels, because conversion and mining take up a lot of electricity. So much, in fact, that mining at night on battery power hardly buys you any extra time. - Has multiple drills, because one large converter can convert Kethane at least 4 times as fast as one drill mines it - Docks from its sides, because it is damn nigh impossible to land on top of a surface station - Has an easily detachable rover or other craft for delivering fuel to vessels that want to refuel On that last point, I used to use a sort of rover with a carefully placed, protruding docking port at a measured height above the ground. It was a 3/4 rockomax tank with landing gear wheels and rockomax small radial thrusters on front and back to move around. It could roll up and very easily connect with the Kethane mining rig at the same level with a normally placed port to refuel. The plan was to give ships inline docking ports so they could land on the Mun upright and a safe distance from the mining rig. Then, the 'rover' could bring the fuel up and use its measured-height port to dock with the inline clamp and refuel the ship. This didn't work at all, because it called for more perfectly flat terrain than the Mun can offer, and translation (RCS) is not an option on the ground, so adjusting horizontal line-up with the ship's port meant driving away, turning, and driving back. I only got it to work once. In my later, much better design, I used a lander with small radial thrusters that it could use to tip itself over and deploy wheels. It'd refuel, tilt itself back upright, and take off to low Mun orbit to refuel the waiting ship. This used considerably more fuel, but it didn't cause loss of hair/sanity

I have never found such an option. My workaround is docking each component on the side opposite its command pod, then ejecting the pod via decoupler. You can then go end its flight if you don't want the debris hanging around. If you want to save its pilot, just EVA him into the station; I usually just erase them such that they may fly another day. The Quantum Strut mod is also very useful; in my opinion they're too easy, but station wobbling is a major problem. You could play like a real man and go to the part.cfg file for command pods and set rotPower to 0. On one hand, station wobbling probably wouldn't be a problem anymore. On the other, it'd be far more challenging (in space you'd rely entirely on gimbals and RCS) and realistic. A little crew capsule can't actually turn a ship around, at least not without a lot of electricity to provide a small amount of torque with a gyroscope. Maybe the in-game explanation is Jeb, running excitedly along the inner walls of the capsule, like a perverse, dangerous hamster wheel.

I built a kethane-detecting, -mining and -converting ship with loads of fuel capacity, five nuclear engines, and one lucky pilot. Its capabilities allowed it to travel, land, and perform EVA's, without assistance from other vessels, to Mun, Minmus, Duna, Ike, Dres, Pol, and Bop. I might have been able to land on every single solid body in the system. Then I went to Tylo. We shouldn't have gone to Tylo.

For example, every instance of 'resource scan' can be categorised as such, and everything under 'Laythe' is also a category. They're already arranged by celestial body (approximate location in chart). I keep thinking of your flowchart as something that might be implemented in career mode, even if it's never explicitly shown in the game. Everything in the category for Laythe missions would be totally unavailable until you complete early missions around Kerbin (demonstrating basic orbital flight etc.) and discover Laythe (with whatever telescope research is going to be implemented later). And none of the 'resource scan' missions would be available -- not even for Mun and Minmus -- before you acquired the appropriate technology for it. It'd be cool to have something in-game like that chart, showing your completed objectives and 'available' missions: describing, I guess, what your space program has shown to be capable of. It'd start with only a few items and exploding into something like yours. Damn, speculation is fun. I might have to make my own

Birds. Especially if they are scared away by the roar of engines or landing craft. Some simple schools of fish perhaps. Aurora. I am entirely unsure from what angles and places they are visible or what actually causes them to become visible, but they'd be cool. More vegetation. A few different kinds of tree, maybe some smaller plants depending on how much you allow for terrain scatters. Bunch some of the trees into forests. Would be really interesting if trees could be collided with in one way or another, maybe destructible. Rain, even snow. Cities could be rendered differently based on distance: within 2.25km (as with other craft) the buildings could be individually rendered with some lights and features. Within say 250m, could show citizens (as in the VAB) and/or vehicles. Outside of 2.25km, just render buildings as simple rectangular prisms. Since from space you're able to see relatively small features like the launch site landing strip, a city would be pretty well visible, but just a texture feature that lights up at night should be a sufficiently cool effect.

I find the provided rover wheels frustrating. Sure, I've made a decent Mun rover with medium wheels, but it's not traveling any appreciable distance. 1 lat on the Mun is probably like 10km and as unrealistic as it is, I want a vehicle that can reliably zoom around at 100m/s (if I'm not mistaken, that's 360km/h or 225 mph). I wouldn't mind the realistic slowness if I could just set the rover to automatically drive in a straight line for hours, but I have to hold the 'forward' key the entire time I want it to keep going, just to keep it from slowing down. I've been messing with the part.cfg files and tripled each wheel's 'speed limit'. To compensate for my version's increased abilities, I doubled the power consumption. Now I want to similarly increase the wheel's power, or torque, or whatever makes the rover go, but I don't know what variable that is. Here some of the part definition for one wheel: MODULE { name = ModuleWheel hasMotor = true resourceName = ElectricCharge resourceConsumptionRate = 1.0 canSteer = true controlAxisType = Forward steeringModeType = AutomaticSteer brakeTorque = 180 brakeSpeed = 1.0 impactTolerance = 65 overSpeedDamage = 60 WHEEL { wheelName = wheel wheelColliderName = wheelCollider suspensionTransformName = suspensionTraverse suspensionNeutralPointName = suspensionNeutralPoint damagedObjectName = bustedwheel rotateX = 0 rotateY = 1 rotateZ = 0 } steeringCurve { key = 0 18 key = 15 6 } torqueCurve { key = 0 170 0 0 key = 2.5 100 0 0 key = 12 0 0 0 } } Can anyone tell me: - What do the variables under torqueCurve and steeringCurve mean? - How can I change them to increase the wheel's ability to get things moving? - Should I turn DOWN steeringCurve to make high speeds safer? - Should I also alter impactTolerance? If it's in m/s, I don't think there'll be a problem I'm gonna do some experimenting on my own soon, but if anyone has had success with these, lemme know

Batteries. For reference, most of my space stations built in lowish Kerbin orbit, which also have lights to power, use up about 800 ElectricCharge at night. On the Mun, the time you spend in darkness should be much less, although you may be eclipsed by Kerbin for longer periods. Still, 8 batteries don't weigh much. Use the smaller ones; they have a much better charge/mass ratio, and they light up! It'd be cool to keep one battery pack as a reserve; disable its flow at launch, and if your electricity runs out, you can choose when to flip it back on. However you aren't able to do ANYTHING once your probe core loses electric flow, so no cigar. Of course, you could always get into a stable orbit to make sure an eclipse isn't about to happen before you try landing.