NASAHireMe

Thanks for the answer, Stochasty. I gradually figured this out myself by sending a couple of ion probes to Kerbol and playing with gravity assists along the way. Setting up assists so that you end up in a resonant orbit afterwards is the trickiest part, because the game engine isn't precise enough to calculate post-encounter trajectories with consistency. Going through the encounter at various timewarp speeds will screw it up, for example. Each gravity assist also tends to have a small radial component to it. It twists the orbit slightly, either clockwise or counterclockwise. You've gotta then correct that radial twist at your deep space maneuver to raise your periapsis back up to Moho. All this would be a lot clearer and easier to visualize if Conic Draw Mode= 0 displayed the encounter as it would appear during the actual encounter. Instead, the lines are hard to parse because Mode=0 doesn't approach reality until you get close to encounter. I was able to get the probes to 1GM from Kerbol (my target) using a couple Eve and Moho gravity assists, but I'm still kinda lost on HOW I did it. At least I know I can. It will take me a few more hours of thinking before I grasp it fully. Thanks anyway.

Yup, what Alshain said. If you're really, really good, you might be able to fine-tune your first free-return trajectory to get you into a second encounter. Actually, on second thought, it might not be possible. Returning from the Mun takes at least a day, by which point the Mun will have revolved quite a bit around Kerbin. One extra free-return might be within the realm of possibility; two free-returns is almost impossible.

Love it. I knew this was too obvious a problem for someone not to have solved via mod. Thanks!

Upgraded from 0.23.5 straight to Beta a few weeks ago and playing a new save. Is there a better way to find a location on the ground/in the air to satisfy a contract? I think this question has been posed already on the forums, but I can't find the thread now. I spent four hours yesterday struggling to complete three Visual Survey/Ground Survey contracts on Kerbin. I built a simple plane so that I could fly over the locations, and a rover so that I could drive from one ground location to another, but I could never be sure where the destinations were. So I spent a lot of time flailing around, driving up and down hills, making racetrack flyovers until I stumbled upon the target areas. It took forever and it wasn't fun at all. Squad really should implement some type of navigational arrow to point you in the direction of where "X0923" or "Manley's Demise" are rather than fiddling with the Map view, which gets blurry if you zoom in too much. Is there some workaround or mod? Something that displays your vehicle's coordinates and the coordinates of your target?

Yeah, since reputation is so vague, I feel perfectly comfortable with taking out all the "reputation"-based strategies in the administration building.

I wonder how many times people have to post in these "Gameplay Questions" forums before the moderators realize they should sticky Claw's radial decoupler bug thread. Because questions like these seem to come up every day on the forum.

One work-around is a cage built around your Kerbals. As the previous poster noted, Kerbals on EVA can hold unlimited pieces of data. There's no need (except for realism's sake) that your Kerbal be INSIDE the capsule when the rocket takes off from Eve. He could hold onto a ladder outside the capsule all the way from lift-off to orbit. To make sure he doesn't fall off, you can build a cage using cheap and light structural parts that will literally corral him to the outside of the spacecraft. It's kinda cheaty, I know. I once had to do this on accident, when I placed a light in the middle of a ladder so the Kerbal was stuck below the light. He rode that ladder all the way to Tylo orbit

Best answer I've found for this question is Metaphor's journey to Moho here. He beats even Macollo's transfer to Moho by using aggressive use of gravity assists, even more extreme than MESSENGER. He uses eight-- that's right, eight -- Moho gravity assists, plus multiple Eve gravity assists to match Moho inclination and to lower his Kerbol periapsis so that Moho capture takes only 63 dV (!!!!!). I haven't seen anyone yet on the forums beat his numbers. Total dV of the mission is 7217, of which 4500 were the launch to Kerbin orbit itself, and another ~1200 were landing on Moho. He explains his technique for launching into an inclined orbit down the page in that link. It's basically an expansion of the core concept hinted at by LethalDose above: it's more efficient to launch into an inclined orbit rather than change once you're already in orbit. Personally, I've learned a LOT from viewing Metaphor's images of his journey, esp. in regards to planning multiple gravity assists. I recently completed a mission of sending a ship really, really close to the sun by using 5 Eve gravity assists and 4 Moho assists. IMO, mastering gravity assists is the 'key' to mastering this game. Once you fully master it, you can pretty much move from planet to planet at will.

FINALLY installed 0.90 (I'd been playing 0.23.5; too lazy to upgrade). Had to delete my GameData folder and re-run the patcher b/c I had duplicate parts in the VAB. Starting the game over is going to be fun, and it means this game will inevitably suck yet more hours away of my life, when I ought to be teaching myself to code or something useful. Already completed seven basic contracts (just completed Kerbal-in-orbit recovery) and upgraded my launchpad. Building up my funds and science. Next up: Mun mission! Btw, it's true, if you're an experienced player the higher difficulty settings (currently playing on Hard) mostly just make the game grindier rather than more challenging. But that's to be expected. Wish the higher difficulty settings had different contracts than the easier ones, or something like that.

If you want a great answer for this in regards to Moho, I highly recommend Metaphor's journey to Moho documented here. He/she managed to land on Moho with only 7217 dV, of which 4400 were launch to Kerbin orbit itself! Reading his discussion and the images of his gravity assists were the 'aha!' moments for me in which I really understood how gravity assists work in gameplay.

That is very strange and sounds like a bug to me. I don't think I have the answer, but I can try to narrow it down: 1. How did you view the ISPs for either the LV-N or LV-909? By right-clicking on them and viewing the readouts? Because then, such a dramatic drop, resolved by simply focusing on another vehicle, is almost certainly a bug. 2. Fuel lines? 3. Did you update MechJeb to be compliant with 0.90 (or whatever version you're playing)? 4. Do you have a .craft file?

I've found that it's less hassle to quickly assemble a cheap rocket with a lab+parachutes to recover all the data in one go, rather than transferring to pods. As you know, you can only take one copy of each data inside a pod, meaning if you want to maximize collection, you've got to land several pods... or just one lab. You can lift a lab, a probe core, and a few parachutes to orbit with a couple cheap SRBs and maybe a small liquid stage. I've saved this as a craft called "Lab Lander" and it only costs a few dozen thousand funds.

How do you perform multiple gravity assists on a single body to lower/raise your Kerbol-centric ap/pe? For context, I know how GAs work in theory. I use them as much as possible on interplanetary missions. I've also mastered calculating resonant orbits so that I know when I will encounter a planet for a second gravity assist. What I've been struggling with is reconciling this: "If the secondary body already marks the apoapsis of our orbit, we cannot go any lower than that: to slow down we need to exit the secondary's SoI from the rear, but our pre-encounter trajectory is already crossing the secondary's SoI from front to back", taken from Part 2 of Stochasty's excellent post on gravity assists, with this: , which used two Venus GAs to lower its orbit to Mercury's, or Metaphor's awesome eight-Moho-gravity assists voyage to Moho. Both examples seem to lower the Kerbol periapsis by performing a GA off of a higher body, which violate the first rule.The answer has something to do with: 1. To perform a good GA, you can't approach a body exactly tangent. 2. I need to play around with the different conic draw modes more. The trajectory displayed in Mode 0 approaches reality the closer you get to the encounter, but before then, the trajectory lines don't match up with the planet pro/retro lines. Anyone with a simple explanation?

Beechcraft Starship. I love how elegant it looks.

My New Year's resolutions for 2013, 2014, and 2015 were to learn to code. I've had a rough going the past three years. I'm reasonably proficient in C++ and HTML (altho I don't really consider HTML a true 'coding' language), and basic in JavaScript. What should I do next? Limitations: I'm not going to pay more than $300, so a physical class like General Assembly is out (also, I don't have a car). Online lessons are great for theory, but more than anything, I need projects. Simple ones (like a basic game), then harder ones, then even harder ones. And I need them to be solved and open and preferably ANNOTATED WITH COMMENTS so that I can check my own progress when I reach a stumbling block. I've found that having the source code is useless if it's not annotated so that a beginner can understand it. Otherwise it's just as useful as Shakespeare in Yiddish. I know that languages are tailored to the task. I guess if I had to stipulate an end objective, it'd be: 1) having the ability to generate scripts to automate stuff, do some basic data crunching, etc. Example: script that scans Twitter API and pulls out all tweets with certain words. 2) make a website tool. Maybe even for KSP. Like if I could replicate AlexMoon's trajectory optimizer, complete with graph and all, and have it hosted on a website, I'd be extremely satisfied. So, what should I do? Suggestions for languages, projects, resources, books, etc. Should I keep going w/JavaScript and add JQuery (the logical step, and one that is fairly easy to do)? Or should I switch to Python (easy to learn, intuitive, variety of uses)?

I built and launched a Laythe VTOL spacecraft. It's got a science lab and all the science components so that I can knock out all of Laythe's science in one go rather than sending multiple landers/spaceplanes. It's currently in transit to Jool. RV&Docked my third Tylo lander to my orbiting Tylo base. The first two landers were barely mission-capable. I upped the TWR on this third craft, so hopefully it'll make that long descent process a little better.

Yeah, nvm. That's a huge ship to be powering with Xenon, btw. My probe weighed less than a ton, so my single Xe tank was more than enough dV. Yeah, it comes out to 5598 dV.

Tsiolkovsky's Rocket Equation is the single most important equation you need to know for KSP. According to the Wiki, xenon gas has a density of 0.1 kg/unit, so your gas weighs 2720 kg, or 2.72t. dV= 4200*9.82*ln(21.43/18.71)

If you're asking about the actual concept of 'patched conics', view the Wikipedia page and this thread. If you're looking for an explanation of the various conics draw modes and limits as they apply to Kerbal Space Program gameplay, check this Youtube video Edit: After some thought, I think the Youtube video and this thread is more applicable to your question. Basically, the different draw modes are ways to visualize on the Map Screen your spacecraft's trajectory. All of them say the same thing, fundamentally, but represent your trajectory in different ways on the Map. Each one has its uses (esp. mode 0, which allows you to plan gravity assists and close-approaches within your target SOI), although some people may prefer one over another. Unlocking so that you can use Mode 0 is pretty much essential if you want to do any interplanetary travel. That way you can Focus View on your target body, see where you trajectory is in relation to the body, and fine-tune your trajectory from very far away, minimizing dV needed.

My guess would not be phantom impulse due to part clipping. My guess would be a 'random acceleration' bug. I've been playing KSP for 6 months now, visited and landed on all the bodies, captured asteroids, etc. In the course of those 6 months, I've encountered the 'random acceleration' bug probably five or six times now (all in KSP v.0.25 or before). If my memory serves me, each case of that bug occurred when I had a spacecraft with the Klaw. This is probably the most well-known bug in the game; seriously, just Google "Kerbal random acceleration" or "Kerbal phantom forces" and you'll see many reports of the Klaw. The Klaw is notorious for producing this bug. I haven't upgraded to 0.90 yet; I'm still playing 0.25. So I don't know if they fixed the Klaw problem in 0.90. And since your craft doesn't appear to have the Klaw, maybe you've stumbled into a new bug that is unique to 0.90. But it appears to be the same bug as the old Klaw bug, except no Klaw (obviously). To fix the Klaw bug, you had to simply revert to an earlier savefile, relaunch and rebuild the spacecraft, and hope that the bug wouldn't hit you the second time around. Maybe you should try the same, and see if building and launching the exact same spacecraft produces the phantom acceleration you posted about originally.

Pecan, you're only partially right. Your statement of 'five minutes added to a two-year mission' is very disingenuous, though. Most of that time is spent time-accelerated at the maximum rate. But you CAN'T time-accelerate the parts you have to perform by hand: the exit burns (only up to 4x), fiddling with maneuver nodes and close-approach markers, waiting patiently for phasing orbits, mid-course corrections, final trajectory corrections, aerobraking (and all its' risks), repeatedly killing velocity-burning target target that RV requires, fiddling with RCS and docking, refueling, etc. All of that takes real-life time. A lot of it. Like at least 15 minutes per mission. Of which I would have to multiply to get a transfer tug back from Jool or Moho or wherever. And God help you if you don't have Kerbal Alarm Clock or MechJeb to help manage multiple interplanetary missions and crafts. You'd constantly be forgetting to do mid-course corrections or what not, and whoops, there goes your spacecraft. The original question wasn't restricted to considering cost only. Real-life playing time is way more important to me, and to many other people, I imagine, b/c funds aren't that hard to get. Second point is that since your one-off transfer stage doesn't need to have any dV to come back, you can often use a more powerful engine, which means your exit burns from Kerbin take less time. Third point, which addresses your "don't have to pay for, and launch, a new transfer section". Obviously, I have to pay for that one-off transfer section, but I'm not launching it, then RV&Ding with my mission craft. It's launched together with the mission craft in one launch. So I don't pay a time penalty that you implied. Magnemoe, what you suggested is exactly what I've been doing. The first 1000m/s burn, which gets you out of Kerbin SOI, is the most arduous part of the transfer burn, so I've been using an orange tank+Mainsail as an 'interplanetary booster'. But even then, I found that having to aerobrake, recircularize, then RV&D with my fueling station in LKO in preparation for the next mission took too much of my real-life time. I'd rather slap on that stage on my mission craft when I'm in the VAB and add a few cheap boosters to handle the extra mass at launch. I love interplanetary burns that take less than 3 minutes.

Sorry to resurrect this thread but it was linked from another thread. I think tractors and tugs are useful for missions within the Kerbin system, but anything interplanetary starts to get real annoying. Even with Kerbal Alarm Clock, you're looking at a long exit burn, up to a two year journey (to Jool or Eeloo), establishment around the target body, another exit burn, another two year transit, then a tricky aerobrake, then rendezvous and docking. Without MJ to automate, aligning close-approach markers, waiting for phasing orbits and doing docking takes tons of time. It's not worth it for me. RV and docking takes so much time if you want to be efficient. I'd rather use a pre-made transfer section that I've saved as a subassembly.

Fun fact: The small piece of cloth that you find on the headrests of airplane, bus, and train seats is called an "antimacassar". It's designed to keep unguents off of fabric.

No, you have it opposite. RCS should be placed as far away from CoM as possible to generate maximum torque. It's the same as a class-2 lever. You're right if you're using RCS for translation purposes only; then you want it right above the center of mass. But most people use RCS for both translation and rotation, in which case you use a pair of RCS blocks equidistant and as far away from CoM as possible. Reaction wheels placement is very important. The wheels impart torque at the wheel itself, so if you place it too far away from CoM you will literally cause your rocket to bend if your rocket is long and not very rigid (like two ships docked together, for example). Dont believe me? Both principles of RCS and reaction wheels are confirmed in both the KSP Wiki and real-life ships. IDK if they changed the properties of the Small Gear Bay in 0.90, but in 0.25 it was physicsless (according to KSP Wiki and my knowledge).

1/10 But I'm new to the forums, even though I've been playing for a couple months now