Snark

Okay, that makes no sense-- it's not possible to "deplete" an area of resources in KSP, they're infinite. Is it possible that you accidentally timewarped or something? (Also, just a side note, it's "Minmus" and not "Minimus") Yeah, that will be a problem. Mining is super slow if you don't have an engineer on board. Put an engineer on those craft. The higher the engineer's level, the faster it will mine. Anyway, I think this answers your questions: - if the problem is "mining is too slow": put an engineer on board - if the problem is "mining rate is inconsistent with what the map says, so I can't find a good place to mine": use a surface scanner to scan the biome

Hello, is this the right room for an argument? (sorry, couldn't resist) Short answer is: going to LKO (low Kerbin orbit) first is much easier from the standpoint of piloting and mission planning; direct ascent requires a lot of skill to get the precise trajectory you want. as far as dV requirements are concerned: as long as your LKO is pretty low, in practice there's very little difference in the dV requirements for the two. Very high TWR craft may do a bit better on direct ascent, very low TWR will do much better with LKO-first. Therefore, my advice would be "go to LKO first." It's a lot easier in terms of skill, and you won't really do much better in dV if you try direct ascent. My impression is that that's what most KSP players do. Tools such as http://ksp.olex.biz/ are very handy for planning your interplanetary ejection burn, and also give you an easy way to play around to see, for example, "how much difference does it make if my Kerbin orbit is this altitude or that one".

^^ This. That's what confused me in the initial post, I didn't realize you were trying to use that marker for docking purposes. Ignore the marker, it's not useful for short-distance work. The highlighted sentence above is the crux of the matter. How does it prevent docking? Can you describe your usual process for docking? Just for reference, mine looks like this: 1. Rendezvous with the target (end up very close to it, at zero relative velocity). 2. Select the docking port on the target that I want to dock to, choose "Set as target". 3. Select the docking port on my craft that I want to dock from, choose "Control from here". 4. For convenience, switch briefly to the target and rotate it so that its docking port is facing directly at my ship 5. Switch back to my ship and rotate it so that it's correctly aligned (i.e. its docking port axis is parallel to the target port's axis), though it may not be quite perfectly positioned yet (i.e. could be a bit off-center). 6. Turn on RCS, press caps lock to turn on fine-control mode (because that makes RCS better, for interesting reasons that for brevity's sake I won't go into at the moment), and thrust gently prograde (i.e. towards the target), up to ~0.2 m/s. 7. If I'm off-center (i.e. if the target marker isn't perfectly centered in the crosshairs on the navball), use RCS to thrust laterally slightly to correct. The target will start drifting towards the navball center. When it gets there, I'm perfectly lined up, so thrust laterally again to kill the sideways speed and I'm heading directly towards the docking port. 8. Dock! Note that none of the above steps involve "look at the little yellow target marker in the main window", which is why I'm curious why the placement of that marker is causing docking problems for you. Step 5 is the only moderately tricky part, because eyeballing the alignment can be difficult. That's the place where a docking alignment indicator mod can be really helpful. My personal favorite is this one: http://forum.kerbalspaceprogram.com/threads/54303 ...it's super lightweight, has no UI to clutter up the screen, does exactly what I want it to: any time that my target is a docking port, it just adds a little red icon to the navball indicating the proper alignment. With this mod, step 5 is trivially simple: just rotate my craft so that the red icon is centered in the navball cross-hairs.

I notice that you mention "long range scanner" and "medium range scanner", but I don't see you mention "surface scanner" or "biome lock". Have you used the surface scanner? There's a feature that you can't get accurate information from the orbital scanners for any given biome until you "unlock" that biome by taking a surface scan there. (This is by design.) The usual progression looks like this: 1. Put a satellite with the medium-range scanner (the big clamshell thing) into a polar orbit so that you can see the orbital map. This gives a general overview of what the resource density is, but it is only an average for each biome, and won't tell you what the concentration is at any given spot. If this is what you're working from, you'll get a rude surprise when you land, because the actual concentration will likely be quite different. (At this stage, using the hi-res scanner is useless.) 2. Use that map to identify which biomes have high average concentration. For any biomes that interest you, land a little lander that has the surface scanner on it, and click the "run analysis" button. This will "unlock" that biome, and now the orbital map will give actual concentrations that you can use for planning where to land your miner. 3. Ignore the hi-res scanner, it's pretty much useless. Yes, it will give you a hi-res piece of information for any given location (after you've unlocked the biome), but there's no way to save that information or do anything useful with it-- for example, it doesn't update the orbital map, or anything useful like that. Unless it gets redesigned, it's pointless. The other thing to be aware of is that resource mining depends on engineer skill level. Put a high-level engineer on the ship, and it'll mine ore fairly quickly. Don't have an engineer (or try to mine unmanned), and it will mine very very slowly.

He can't do that, because there's practically no oxidizer available. All his fuel is just LF with no O, which means the LV-Ns are his only option. So all he could do is either try to take the whole shebang, or ditch the lander. Going home in the lander by itself just isn't an option. It sounds as though he has plenty of dV if he ditches the lander, the only disadvantage being that then he wouldn't be able to control his ship for most of the journey: as soon as he departs Duna's neighborhood, he's incommunicado and therefore uncontrollable (because RemoteTech) until he gets right near Kerbin, which means no mid-course correction burn possible. My money would be go for it. Set up a Duna departure burn that takes the nuke ship right to Kerbin, and just live with the uncontrollable middle part of the journey. If a mid-course is really needed, just send a rescue craft with a relay antenna on it that gets close enough to give control of the ship long enough to make a correction burn.

Yes, that works-- I've done that, too. I find it to be really tedious, though-- takes forever to get the thrusting done. Having reaction-wheel torque craft separately attached to the asteroid allows firing on continuous thrust and is a lot more convenient. For me, at least. Until the kraken strikes and makes me regret succumbing to temptation and using the klaw because I'd really really like to play with asteroids. Gosh darn I wish they'd fix it...

I'm trying to understand what you mean by "the GUI shows the other port as the target." How can you tell? Does the nav ball show the target marker in the wrong place, or something? i.e. can you be a little more specific about what you mean by "shows"?

Yes, but how do you steer it while you're thrusting? Unless the CoM line-up is perfect (which in practice it never is), there will be a smidgeon of torque error while thrusting, and you'll need some sort of torque authority to correct it. The problem is, if you put that torque authority on the thing doing the thrusting, it causes it to bend in a way that makes the thrust torque worse. This results in a positive feedback loop that causes the runaway waggle problem. So it's helpful to have a way to torque the asteroid that doesn't include torquing the thruster.

I actually prefer to have 'em diverge, i.e. one points off to the left and one off to the right. It creates two widely-spaced spots of light on the ground, so that if there's significant slope, one of the lights will be visibly farther away than the other and I can see the slope better. I can judge height-above-ground pretty well, too.

...So you're actually orbiting Duna retrograde? i.e. westwards, opposite the direction of Duna's spin, Ike's orbit, and Duna's orbit around the sun? Ew, that makes life harder. Just out of curiosity, how did that happen? Anyway, water under the bridge at this point. I assume that the big red arrow that you've drawn from Duna indicates its orbital direction around the sun? You want your ejection from the Duna/Ike system to be opposite Duna's orbital direction, in order to lower your solar periapsis down to Kerbin's orbit. The fact that you're orbiting opposite Ike's direction makes an Ike gravity assist considerably less effective. Offhand I'd say that if you do any Ike assist, you'd want option B, since that gives you the maximal boost opposite Duna's orbital direction. However, it's not at all clear to me that you get that much of a benefit (or indeed any benefit at all)-- it would mean giving up a fair amount of Oberth-effect benefit from Duna's gravity well, which is deeper than Ike's. Some more options to consider: Personally, I like the idea of ditching the command pod and sending them home in the hitchhiker module. Yes, it means no orbital corrections between Duna and Kerbin. However, a well-executed burn from Duna should have no problem taking you close in to Kerbin where you will have control again (especially if you don't play around with Ike). You could also consider a hybrid approach between "send them home in the hitchhiker" and "send a rescue mission": that is, send them home in the hitchhiker with the best burn you can manage from Duna, then launch a "rescue" mission that intercepts them before they get to Kerbin. The rescue mission wouldn't even have to match velocity or dock-- it could whizz past at kilometers per second at a distance of a few thousand km, and simply serve as a RemoteTech relay that would give you control over the ship long enough to do a correction burn. It could be small, cheap, unmanned, and (because really light) have a lot of dV. In the it's-so-crazy-it-just-might-work department: You could send them home on EVA. A kerbal's EVA pack has a ridiculously overpowered dV of several hundred m/s. Launch them in the ship, then when you run out of rocket fuel, they go EVA and complete the boost. Yes, it would be a hassle (you'd have to do it separately for each kerbal, and you won't have navball or maneuver nodes)... but they'd live forever in legend and song!

One way to mitigate the bending-claw problem: Make it so that the thrusting craft has no torque authority at all, and is thrusting straight at the asteroid's CoM. That is, make sure that the thruster has a locked gimbal on its engine, and has disabled all reaction wheels (including the command module, if it has 'em). This means its thrust axis stays lined up straight through the asteroid's CoM and flutter is minimized. Of course, it also means that the craft is useless for steering the asteroid (i.e. rotating it to the desired orientation), but you can make up for that by attaching other craft that have plenty of reaction wheels but no active engines. They do the torque, the thruster does the thrust. That said: I personally find the claw to be so horrendously buggy and game-destroying that I've completely sworn off it forever, or at least until Squad has the bandwidth to fix it. But the above technique worked well for me until I got so frustrated with game-destroying bugs that I swore off the claw.

Well, yeah, no argument there! But if the landing's picture-perfect so there's no touchdown torque, then it doesn't really matter how many landing legs there are, anyway, unless the craft is super top-heavy. It's a handy discussion for "how to design for when things don't always go as planned." Also, touchdown torque doesn't have to be from horizontal momentum-- you'll get it when you land on a slope, even if heading straight down. (And landing on a slope is exactly when tipping tends to be the most dangerous.) So it's still a worthwhile topic of discussion. Yes, it's set-and-forget. Here's my problem, though: The only time that I'm in much danger of tipping (and therefore might care about roll orientation) is if I'm landing on a slope. And personally, I find it annoyingly difficult to eyeball exactly which way the slope is going as I descend-- I can get the general gist, but until I'm really close to the surface, my visual estimate is often off by several compass points. (I can mitigate this somewhat by putting a couple of spotlights on the lander, angled down by about 45 degrees. Great for night landings, but they also help even in daytime by giving a couple of visual reference points. But it's still tricky for me.) Maybe others are better at eyeballing slopes than I am, but for me, that makes it so that if I want to adjust roll for the optimum case, I can only do that in the last few meters of descent, when I tend to have my mental hands full. So I design for that by giving my landers 4 legs, and making them very squat, so that my roll orientation doesn't matter so much.

This is a bug that can happen with certain mods (UKS does this). Some people advise using a klaw to bring the whole thing down, but I avoid that like the plague because the klaw's so buggy-- it seems like it always screws up my save and I have to revert. I generally just resort to editing the save file to turn the craft into a Mk1 lander can. It's a simple one-line edit; just go into the save file (make a backup copy in case you mess something up), search for the "Fredbert's Wreck" (or whatever it's called) to find the vessel, find the first PART in the VESSEL section, find the "part = " line where it says it's a HECS or whatever, and replace that so that it says "landerCabinSmall" instead. Then load the save and you're good to go.

The good news is that it's not super finicky-- you have a pretty big margin of error, at least with small/light craft. My experience is that anything over 25 km is safe, and anything under 35 km will aerobrake to the surface in one pass. So if you aim for around 30, you should be just fine.

Congratulations, glad it cleared up! Just wanted to highlight jkool702's excellent advice, in case it got missed in the thread: it's an excellent fallback plan that provides insurance against any sort of unexpected electricity shortage: ^^ This. The fact that you can activate/deactivate batteries, the same way you can do for fuel tanks, is really handy. A convenient VAB design technique: put one extra battery on your craft somewhere, and disable it (or you could disable the electricity supply on the command pod itself). That's your "reserve"; it's safe and can't be drained by anything until you activate it. If you ever run out of power, just wait until you need it (for maneuvering, landing, etc.) and then enable the battery.

First good argument for 3-footed landing I've seen in the thread. For the non-mathematically inclined, what ajburges just pointed out is that 3-foot can help when you land, if you're careful to set your roll correctly so that your first contact is two feet. That is, for a craft with any number of feet: - the best-case scenario for first contact is that you touch with two feet perfectly aligned on your trailing edge, then settle down so that the "forward" feet on the opposite side touch down. - the worst-case scenario is the opposite, where you touch down with one foot perfectly aligned on the trailing edge, then settle down. ajburges' excellent point is that a three-footed lander maximizes the benefit of that best-case scenario. That's a good point, though I find that in practice, I have better luck with 4 feet. Reason: - taking advantage of this effect requires you to have the roll axis perfectly aligned, otherwise you lose the benefit. I find that juggling pitch, yaw, and velocity keep me mentally occupied enough that I prefer not to have to worry about roll, too. - when I set up my suicide burn, I generally end up coming just about straight down to the surface, so that this benefit is minimized. So the real answer to this thread is: 3 feet can work well for you, and so can 4. There are good arguments on both sides and it's not a slam-dunk either way, since it depends on variables such as your skill level, your landing style, the slope you're landing on, and the design of your craft.

Congratulations on your first Mun landing! Some tips for landing there (to come in handy for your rescue mission): Step 1: Munar approach. Sharpy's advice covers this this pretty well. Fine-tuning your orbit for low munar periapsis doesn't require much dV from your rocket if you do it early when you're still a long distance from the Mun. (Reason for wanting the low periapsis: to save fuel, it's an efficient use of dV for the next step.) Step 2: Orbit Mun. As you approach, set a maneuver node right at periapsis that burns retrograde until you are in a very low circular orbit. Do this burn when you get to it. (I'm assuming here that your kerbonaut is pretty much on the equator, and you're approaching in the equatorial plane, so that you don't have to do any inclination adjustments on approach-- if that's not the case, you'll have some additional work to do before descending.) Step 3: F5. This next step is tricky and you may need a few tries. Step 4: Begin descent. This will be trickier for the rescue than it was for your first mission, since you care about where you land (don't want your poor kerbonaut to have to walk dozens of kilometers or more...) Set your stranded kerbonaut's vessel as your target. Wait until you're maybe 30 longitude degrees west of target, then place a maneuver node around 10 degrees west or so from the target's location. This will be a retrograde burn that puts you on a descending trajectory to impact the Mun near the target. Make it so that the projected impact point is a smidgeon east of your target (i.e. so that you're projected to overshoot slightly, like a km or two). Step 5: Pre-landing. This is the most critical and tricky part, since it eats up the most dV, and if it's not done "just so", has the most potential for Bad Things (waste lots of fuel, land too far from target, crash). The ideal way to land is called a "suicide burn", and involves waiting until the last possible moment and then starting a hard burn that brings you to a stop right at the surface. That's a hard thing to judge, since if you start your burn too early you waste fuel, and if you wait too long you go splat. Here's a handy way to set it up: Place a maneuver node right precisely at the surface of the Mun, at your projected impact point. Drag the retrograde handle and just hold it there until the projected orbit shrinks to nothing and the prograde/retrograde markers on the node start flipping back and forth. Look at the "estimated burn time" indicator on your nav ball. You'll start your burn when it's a bit less than that time remaining until the node-- for example, if the indicator says that the estimated burn is 20 seconds, you'd wait until you're, say, 16 seconds or so before the manuever to start the burn. When you're burning, keep your craft pointed surface retrograde, and burn until your surface velocity has reduced to something manageable. Step 6: Landing. At this point, if the tricky and finicky previous step was done just right, you'll be moving pretty slowly and mostly vertically, not very far above the surface. Now just land as you would normally do. Hopefully you've got plenty of fuel left for the return trip. Happy landings!

I usually aim for about 30 km myself for such situations, and it seems to work fine. If the returning craft is like you describe, it comes down just fine, uses up maybe ~100 units of heat shield (perhaps a bit less), comes down with no problem.

I keep seeing references to "NaN virus" in this and other threads... what is it? From context I kind of get the idea that it's not an actual virus but a tongue-in-cheek term for a bug which, if triggered, somehow does something to cause corrupted saves that propagate the problem. However, I've never encountered anything like that, and I've put in an awful lot of play time since 0.23.5. What triggers it? Enquiring minds want to know how to avoid waking the kraken...

...and if you're lucky, the Klaw won't destroy the universe or cause other infernal shenanigans. It's notoriously buggy. Maybe you've had better luck with it, but it breaks my game about 3 tries out of 4, just simply not worth the hassle to me. When I run into this bug, I just edit the save file to turn whatever-it-is into a Mk1 lander can, then proceed.

I suspect there's no "formula" in any meaningful sense of the word, at least not one that you could deduce by trial-and-error experiment. If I were a software engineer (which I am) and given the task of making names + professions act like this, by far the simplest and most reliable thing I could do would be to just take the hash code of the name and then modulo-3 that. For a non-programmer, you can think of it as a deterministic random number: the same input (name) will always give the same output (profession), but there's no way to predict which profession a given input will generate without actually doing the math, and the math is complicated enough that you're unlikely to be able to reverse-engineer it. You just need to know what math the code is using. That's not to say that that's actually how Squad did it, I have no idea what they did; just that it would be the simplest thing to code, and programmers are typically big fans of Occam's razor.

Not necessarily. I started with 3-legged landers (because "tripods are stable" and "three legs have less mass than four"), and quickly shifted to 4-legged designs because my threes kept tipping over. There's a reason why cars have four wheels. Picture your craft's footprint on the ground. I'll define some terminology for purposes of discussion: CoM footprint: The spot on the ground directly beneath your center of mass. Support polygon: The shape made by connecting the feet of your lander with straight lines. For a typical three-legged lander this will be an equilateral triangle; for a typical four-legged lander, this will be a square. Ideally your CoM footprint will be directly in the center of the support polygon. Maximum support radius: The distance from the CoM footprint to each leg (i.e. to the vertices of the support polygon). Minimum support radius: The distance from the CoM footprint to the sides of the support polygon, i.e. the length of a line from the CoM footprint to the midpoint of one of the sides of the support polygon. This will be shorter than the maximum support radius. The more feet your lander has, the bigger the minimum support radius. The issue with three-footed landers is that they have the smallest minimum support radius. Four-footed landers have significantly larger ones. When your craft starts to tip, what makes it fall over is when the CoM moves outside the support polygon. Four-footed landers have a bigger "safety zone" within which they're tip-proof, because they have a bigger minimum support radius than three-footed. Note that one of the big reasons for tripods doesn't apply much for KSP: A tripod can always have a stable, no-wobble footing on any surface, whether it's uneven or not, whether the tripod legs are exactly the same length or not. A four-legged object (like a table) can wobble, either if the legs aren't exactly alike, or if the surface it's sitting on is uneven. However, in KSP, typically "uneven surface" isn't an issue. Your landing site may be sloped, but it's typically a flat slope, unless you're unlucky and come down right on a ridge line. This is due to the relatively low level of surface detail on KSP planets. This means that one of the biggest reasons for tripods simply doesn't apply; and even if there is a slight ridge where you come down, the legs' suspension tends to make up for that anyway. Moral of the story, it's not a slam-dunk that going three-footed will be more stable.

That's... quite a contraption. Really, for anything that's tip-prone, there are only two answers (not mutually exclusive): Lower the center of mass, or widen the support base. From the screenshot, it looks as though it would be pretty easy to widen the base-- you have your landing legs mounted on short girders. Just replace those short girders with long ones and you'll buy yourself a lot of stability. To lower the CoM, figure out ways to move the heavy parts lower. For example, those LV-N's are really really heavy, and they're right up at the top of the craft-- anything you can do to move them downwards would help.

Goodness, that's quite a beast! A possibly silly question, but is there a reason to need to do this, or is it just for fun? (I can see needing a fuel truck for bases on other planets, but Kerbin can provide all the needed fuel at launch...) I seem to recall reading on the forums somewhere that airplane landing gear has an improbably high weight tolerance (though I've never tested it myself)... maybe worth an experiment to rest most of the vehicle's weight on some landing gear?

This is true... however, you can adjust for that by turning on "fine control" mode (caps lock is the default key for this). When fine control is enabled, RCS does something very nice: it causes the individual ports to auto-adjust their thrust proportionally, to keep the center of thrust lined up with the center of mass. Thus, for example, in your last "bad" example ("not equidistant from CoM"): if you pilot that ship with RCS when in fine control mode, the thrusters farther away from the CoM will fire at lower thrust levels, with the result that you get smooth, torque-free lateral thrust. A really nifty feature that is often overlooked.