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.

Weird. Are you sure you didn't use a probe as your command module? Even if you put manned probes on after that, they will be empty. A manned pod needs to be the first thing you choose. Or maybe you hit F2. But that hides all GUI (hit it anytime to toggle). Or maybe the game thinks your screen is wider than it is and your view area is cropped. But then you'd probably be missing some other stuff, too.

I'll help. Emailed Tada. You can get a lot of Kerbals up in one launch if you take the time to march a bunch off the launchpad, ready the ship you want them to board, then have them walk back and climb into it. But that is zero fun. When my turn comes up, I'll make sure to include more of whatever's needed; crew, fuel, or whatever. EDIT: Provided email address failed, even on the second try when I checked carefully. You can email me at nickringer at gmail dot com.

Kerbals on a ladder? Anything under acceleration (ASAS causing more than very small adjustments counts)? Throttle turned up (whether engines are firing or not)? These things won't allow you to quicksave, so I'm pretty sure they won't let you let the flight keep running while you go back to the space center. There may also be an 'about to crash' sort of barrier to it, as with planets and moons.

Does this mean not using the large command pod, either? It's large, but "as many Kerbals as you can" would otherwise mean having a bunch wait around on the launch pad and then climb ladders into empty 1.25m pods you've placed on the entry ship. Maybe, since Kerbals don't add mass inside command pods, just having a bunch of empty ones could count?

For big vessels built in space, intended to hold LOTS of fuel and with a drive stage, I use action groups to undock multiple ports at once. Just like staging, but unfortunately with no kick to get the detached part off. I should throw in some sepratrons I guess. When I'm playing with Kethane, I keep a group for deploying drills, toggling the converter, and unleashing my massive, throbbing solar panels. I guess it's nice for toggling stuff like ladders when you have a bunch (tough to click the little bays) but lights and landing gear already come with hotkeys. I would love action groups to enable/disable fuel tanks themselves. Sometimes I want to carry a big fuel tank into orbit but only need a really small amount of fuel left in it for orbital adjustments/docking. So I let it drain into the lower stages to make my payload lighter. But since I have to disable Oxidizer and LiquidFuel with a mouse click each, I'll end up with some unusable fuel (which I also can't dump). I'm sure I could also think of ways to quickly redirect fuel flow through external fuel lines using action groups.

Docking several ports at a time is tough, but since you have 6 there, they should be more or less forced into place. Also, what Wait said is true; right-clicking one will give you the "Undock" and "Disable Crossfeed" options if they're actually connected. If everything is in fact correctly docked and you still can't get the crossfeed working, it's probably a part hierarchy problem. If I'm not mistaken, the docking port on your core doesn't just have to be a child part of the tank (you attached the port to the tank), it also has to be BELOW it, since this is how fuel normally flows; from the top tank downward. Maybe your six smaller fuel tanks on the core think they shouldn't automatically pump fuel through the docking ports, because the ports are on the top. You have the core sideways in the editor, so I can't tell. I also highly recommend the Quantum Strut; it's one of only 3 mods I use. The requirement to place new ones in EVA is cool and somewhat more realistic, too; you have to work for your space-built awesomeness! A similar mechanic for attaching fuel lines in space would be the best. Since it took you so long to make, my heart goes out to you if you can't get this ship up and running. I have built something similar that had natural fuel flow from the core out to all docked drive engines, so it's definitely possible. However, that was my second attempt, the first being foiled after several hours when I made my docking approach and realized I forgot to place any docking ports on the core

Make the rover bisymmetrical and have it hang from your lander stage. Then you can just decouple it and it'll drop a meter or two onto the surface. The rover itself should really go light. Use a probe; command pods are heavy. Have some wheels, a little battery storage, and solar panels; the little flat ones are good, because they're less likely to get ripped off if it tilts over. A light or two won't hurt, but wheels take up enough electricity that you might want to just keep it to daytime driving. Make sure to land CLOSE to where you want. It's disappointing how slowly rovers move, but KSP is granting us a lot more than real life; Curiosity probably isn't capable of more than 1m/s.

It depends on the body. If you have something that rotates very slowly, like Moho or most of the smaller moons, it will take hours to cover all longitudes. I addressed this by taking a polar orbit to covering an orbit or two at a given longitude, adjusting my inclination to move east slightly near the equator, then readjusting to a polar orbit. Of course, this requires fuel and some attention (I scanned Moho while watching a movie and bumping the orbit over every few minutes). The most efficient way to 'bump' the polar orbit east or west would probably be to make a normal burn at 45 degrees south, then make an antinormal burn at the 45 degrees north, assuming you're traveling north in that portion of your orbit. If you decline 4 degrees, the next polar orbit would be 1 degree east, right? Damn it, I just use the map. I suck at orbital mechanics, however. I never fully understood why a polar orbit can't naturally rotate in the same way a body spins; why is it relative to the ground? A planet's own rotation is relative to its parent body, right? I suppose as you orbit one thing, you are also in a child orbit of its parent. Can anyone explain this to me like I'm 5?

Holo, the chart you linked is incredible. And I gotta say the less compact version you made is much, much clearer. When multiple arrows lead to one item, is your intent to say "either of these could lead to this mission as a logical follow-up"? Because that makes it less linear, and I like that. It would be pretty weird as a player to achieve a lunar orbital probe and move straight on to a series of Laythe missions, but the game is all about openness (at least in sandbox). I suppose when funding is implemented -- assuming you're not going to get more money until you have some small successes -- it'll keep the missions in reasonable order. I understand you're just laying out YOUR space program there, but if you tricked out that chart with ALL the possibilities it'd be k-k-k-killer. Can your software implement some sort of color-coding or grouping for less significant tasks? Like where you have "Tylo Resource Scan" there might as well be a bunch of other Tylo-related tasks like landing or setting up a station. If we're talking "things you can do in the game" rather than "things useful for the purpose of extra-Kerbin habitation".

Holo, I like the flowchart. I'm afraid if you expand it to include a similar number of objectives for each body it'll be staggeringly large. I bet if you find a way to arrange it to look more linear, it'll be a little cleaner. Think Civilization tech tree -- which also wouldn't be a bad way of unlocking missions in the game, in my opinion! How's this: First, here's a rather abbreviated 'map' chart from Kerbin to each other body. You can make one of these from any starting point. Given the delta-V requirements of each transfer and circularization, this could be the basis of a system for allocating money to missions. The bodies are listed in green; on each of these, many further objectives could be chosen (e.g. circularize, land, map); each of these is also a starting point of another such map, should one mission go multiple places. Here's a chart of every objective I could think of for each body in the game (including some which aren't yet implemented). A mission might involve many of these, even for more than one celestial body. It doesn't really have much for Kerbin, which as the game's starting point, should really be granted its own set of smaller and simpler missions. As many have mentioned above, these fit nicely into the learning curve up to reliably achieving Kerbin orbit. If I get bored later I'm absolutely whacking out a tech-tree style mission list!