impyre

Using a fuel-balancing mod works very well; however, a little design consideration will ensure even fuel consumption also. Just ensure that each engine has its own fuel supply (with the same amount of fuel) and that tanks are placed in symmetry. If you must, you can use decouplers to strictly forbid fuel flow (and many parts allow you to disable crossfeed, which will accomplish the same goal). Fuel lines can help as well (to a point anyway). Uneven thrust limiter settings will cause uneven consumption as well.

Here's a craft that burned 1301 m/s of dV from a 72km x 72km orbit. And here's the exact same craft (with same dV) launched from 570km x 570km. As you can see, both attain a straight escape trajectory equally well (the higher orbit escape is noticeably straighter though). And both attain about the same altitude for solar apoapse (though the higher orbit had a slight advantage). Had I used alex's calculator (which I linked above) I'd have noticed that the ejection angle is significantly closer to the desired angle for the higher orbit... In this test I burned both vessels at 150 degrees to prograde. Had I compensated in the ejection angle for the higher orbit, it would've attained an even greater altitude advantage over the lower launch. As I said before, launching from a higher orbit means that it takes less dV to get the desired escape trajectory (and thus the same craft will arrive with more fuel)... but this comes at the cost of additional fuel delivered after reaching the parking orbit (but if you're going to refuel anyway, might as well make it worthwhile right?) the only case in which this information is useless is if you intend to go directly from launch to interplanetary transfer with no refueling (which when combined with staging is indeed the most efficient, if cumbersome, method). edit: can someone please explain how to use spoilers to me? - - - Updated - - - The advantage isn't hugely significant, but it is noticeable. The difference between 70km circular and 550km circular (when going to duna) is about 200 m/s dV. Of course, the further you're going to be going, the more significant that advantage becomes. Bear in mind you can go much higher too... launching to duna from an orbit similar to minmus (say if you just barely escaped minmus) would only require 664m/s as opposed to the 1060m/s required from LKO. For those of us with refueling bases on minmus, this is a huge deal. One last thing I'll mention, 100m/s dV worth of fuel in a large interplanetary ship can translate to 2000m/s dV for landers and such (depending on relative sizes it could be more or less). This means that if you leave from a higher orbit, you extend your dV budget for landers significantly.

Not really. It takes less dV to obtain a trajectory with the same angles from higher altitude. If you don't believe me, you can try for yourself. Spend 1200 m/s at 70km x 70km orbit, (where orbital velocity is already something like 2300 m/s) and then spend the same dV at 500km x 500km and see what happens. "Gravity losses" are higher the lower you are (where the pull of gravity is stronger), and is also related to the amount of time spent in the gravity field (which will be lower if you start from higher up). In any case, you don't really lose energy to gravity once in orbit, you just trade one form of energy for another. Arguably the most efficient method (even though the question isn't really efficiency here) is take-off directly to munar flyby, and burn an oberth maneuver to get the proper escape.

AlextheBodacious was making reference to a technique used to stop vehicles from wobbling just after docking in space. Just after docking, vessels can wobble (especially if each has its own SAS module and stability assist is enabled). Disabling stability assist and timewarping (*not* physics warp) will help stop this before it destroys the vessels. He didn't realize that you were talking about during launch/burns.

I'm reading the question as: "If I have a craft with a given dV, will it benefit from a higher or lower orbit." And the answer to that (as well as so many other good questions) is that it depends. Gravitational pull decreases with a square root function, so the further out you are the less you'll have to fight against gravity (but you get less benefit for each additional km of altitude). Furthermore, the way to really look at this is in the form of energy. The higher an object is, the more energy it will have. All orbits of the same period have the same total energy. A perfectly circular orbit maintains a constant balance between kinetic and potential energy, while a highly elliptical orbit trades potential energy for kinetic energy as it approaches periapse and trades that kinetic energy back to potential energy as it approaches apoapse. This having been said, the greater the orbital period the greater the stored energy... and the greater the stored energy, the less you need to add to get an escape trajectory. So if I'm interpreting your question correctly, higher is better. However, it does take fuel, time, and energy to get there... and as others have pointed out, if you're going to simply go for a transfer there's no need to circularize at 800km. Higher orbits will allow you to more easily take more fuel with you (and spend less getting escape) at the cost of additional launches and efficiency. - - - Updated - - - http://ksp.olex.biz/ see this link for dV's and more.

I have quite a few mods that add both parts and unique uses for those parts... so I tend to get both efficiency and looks.

Also, this may go without saying, but if you want to build something complicated in orbit out of smaller pieces... your payloads will generally have some docking solution on the bottom and the top (so that once detached from the launcher, something can be attached at both ends). Lastly, I prefer structural fuselage to build structure in my vessel. It's lighter than beams and girders, and sturdier.

I use what I like to call the "wagon train" method. As described here: http://forum.kerbalspaceprogram.com/threads/113703-I-d-like-guidance-with-setting-up-a-future-Duna-base As for orbital construction specifically, I do have a couple tips: 1) Use the biggest docking ports available. 2) Tri-docking by using the three-way adapters and three docking ports is much stronger than even the larger docking port by itself. 3) Using sections that interlock (like building a cube) will greatly increase rigidity and mobility. (There's no need to combine #2 and #3, but you could) 4) Consider supplies if you use life support (regenerative technology really extends supply time and decreases mass). 5) Consider sending a second ship (probe controlled) that has very lightweight return vehicles, and leave everything else behind. (This will reduce the total fuel required for the return trip) 6) RE: KAS, use the KAS struts, they are your friend. 7) As for linking up, standard docking procedures apply. It's helpful to ensure that the ship which takes up the piece to be docked (the tug) can leverage lots of torque for controlling all that dead weight, though adding RCS or SAS to every part you dock can improve the mobility of the finished ship.

I use a method I call the "wagon train". Instead of building one huge ship, build several smaller ships. I usually send up two mining modules, one comms module, one science module, and however many infrastructure modules/crew modules/return modules I'll need. I like to also include an emergency module that contains things which may help me mount a rescue or extend how long my kerbals can survive in the event of the unthinkable. - - - Updated - - - You can send these all off in the same launch window (they are usually pretty good for a few days), and with excellent placement in orbit, you can essentially just execute a transfer burn for one, switch to the next, execute its burn (rinse/repeat).

I also double-click to keep the info up. Word of caution, double-click very slowly. Double-clicking will work to keep the info up, no matter how much time passes between clicks (just as long as you don't click anywhere else between the first and second click). If you double-click too quickly, you may inadvertently change the camera's focus.

I was beat to the punch, but I was going to say SAS. I have had this happen... the biggest issue is when having your pilot hold retrograde (when your velocity gets near zero, it moves about wildly). The easy solution is to just switch back to stability assist before velocity gets too low.

I came on board at .23.5... I'd heard a couple people mention it in the same tones that I'd heard just before I discovered minecraft and spent a chunk of my life playing that. So when I seen it on sale, my curiosity got the best of me. And then I spent 777 hours in KSP... it quickly unseated my previous favorite steam game from it's throne at the top of my "hours played" list.

I agree with Alshain. I played with FAR before I switched to NEAR, but I hadn't used FAR for very long (just long enough to get frustrated at being unable to understand how the craft design was affecting the graphs... and how that was representative of flight... and how easy it is to stall... and how craft can be stable across some speeds but not others... not to mention how easy it is to shred your craft). By comparison, NEAR was much easier to adjust to and more intuitive (if you're used to stock and not an aero engineer). I have been contemplating trying FAR again though.

I concur with many of the others, aero, performance improvements/bug-fixes, tutorials/scenarios. (And for me that's in order of importance)

Added the new graph, decided to do something a bit more comprehensive rather than just doing a few points for each engine/vehicle weight combo.

Quite simply, inclination by itself isn't enough to fully describe an orbit. Your inclination is the angle that your orbit makes with the equatorial plane. Think of it like a disc. Once you have an inclination, your orbital plane changes (and can be rotated around). This rotation is where the longitude argument comes into play, the longitude of ascending node is the longitude at which your orbit will cross the equatorial plane (and is presumably written with respect to the parent body's prograde vector). Imagine taking your orbit and rotating it around the north pole, this is the adjustment of the longitude of your ascending node. Adjusting this is a very difficult task, which is why at launch you must take care to match the target plane (not just its inclination). tl;dr I'm not sure if I'm describing this well, so I'll give one more example. If you think of a satellite dish, pointed up at an angle and imagine the rim of the dish as an orbital path... the angle that the dish makes with the ground is its inclination. If this dish were attached on a post which allowed the entire thing to rotate, this rotation would be like changing the longitude of the ascending node... if it were pointing east, and then rotated to point south this would represent a change of 90 degrees in the longitude of ascending node. - - - Updated - - - Here's what I do, I'm too lazy/impatient to wait for the correct time to perform the most efficient launch (directly into the correct orbit)... so I simply launch on a low equatorial orbit (as if going anywhere else really), then burn so that my apoapse rests on the ascending/descending node of the target orbit. Once at apoapse I burn to match inclination and raise my orbit until it crosses the target orbit's periapse or apoapse. Once there I use a combination of prograde/retrograde/radial burns to match my target orbit perfectly. It's a bit more complicated, but it's not terribly inefficient (just marginally inefficient). The reason I use this method is because it really reduces the guesswork and potentially difficult piloting that can go with trying to launch directly into the desired orbit. It makes it relatively easy to eyeball.

...*invisible*... You just have to know where they are.

I use NEAR, and it does simplify some things. I had this problem: When the plane can go fast enough to fly, it can't turn... and if it's going slow enough to turn it cannot fly. This means your lift-to-weight ratio is too low. Experiment until your plane can take off at around 80m/s. Once you can do that, you'll immediately notice a big difference in the way it flies. Other than that, just ensure that center of lift stays behind center of mass at all times. I find that raising center of lift a little above the line that runs through center of mass and center of thrust adds a bit of roll stability. As someone else said, adding forward canards can also help improve mobility (but be warned that your plane's ability to adjust its angle of attack can outstrip its ability to generate lift with highly maneuverable craft). The most stable vessel will have maneuverability that is slightly less than its lift capacity(max pre-stall AOA)... reducing the chances of stalls.

Thanks!

the argument of periapsis is one of the most difficult things to adjust (but usually doesn't result in the inability to fulfill a contract, I'd recommend checking other requirements). Radial-in/out will "rotate" your orbit around a point that is decided by where you are along your current orbit, and the specifics of your orbit. Try creating a maneuver node with a significant radial-in/out burn, and move it around your orbit. Here's the basic process: 1) Pivot your orbit until the argument is correct (altitude may be off). Maneuver nodes can help here, radial burns adjust this. 2) Burn prograde/retrograde at the appropriate times to match the orbit exactly. This *must* occur at peri/apoapse in order to avoid changing the argument. 3) Once close, argument can become a bit jumpy (especially for a circular orbit), use a combination of prograde/retrograde and radial to adjust the height of your peri/apoapse to the desired point without changing argument. If you're approaching your apoapse, radial-out will shift it ahead of you in your orbit, and radial in will shift it backwards. 4) Note that the more you are angled towards radial, the less the burn will affect prograde (and vice versa). Use this fact to make the smallest possible adjustments to whatever orbital attribute you're trying to alter (in addition to decreasing throttle limiter and using capslock for fine control). Once you practice a bit, you'll get the hang of it. It's kindof a balancing act when trying to adjust one thing while keeping another the same. Again though, for contracts which describe a "circular" orbit, argument of periapsis/apoapsis is displayed, but generally ignored. - - - Updated - - - Wow, you're *way* off... with extremely inclined target orbits, the best bet is to try to match the inclination directly from launch. Forgoing that, the second best method (though more costly) is usually to enter an extremely elliptical orbit and execute the inclination change at apoapsis.

I didn't know you could do that... o.o

This is a really solid solution. Jeb approves of dropping things on purpose. A powered descent will give you the most control, you can treat it as if it had no atmosphere for most purposes... of course it will increase the fuel requirement though. I generally use drag and chutes to slow me down until I have a periapse beneath the surface, and then use engines for more control. When I do rely on chutes, I use multiple chute stages for Duna. The first stage of chutes has *way* more drag than I need for landing, to help grab the thin upper atmosphere and slow my horizontal velocity. Once I have less horizontal velocity than vertical velocity, I cut the first stage chutes loose and deploy the second stage. The second stage provides less drag (to avoid ripping them off), but plenty to land safely. By timing when I activate each stage, I can usually put it down pretty close to where I'm aiming. RCS or small engines can help adjust beyond that point if necessary.

Could you please create a logo for me? I'd like something rather simple, but sleek and futuristic. Something like the spacex logo, or the ARCA logo (ARCA is my favorite). http://www.arcaspace.com/ I'd prefer it have a transparent background if possible (not sure that's possible with flags in KSP) or just white background otherwise.

Precisely. If you've got a really heavy vehicle (such that changing from lv-909 to nuke doesn't change percentage of mass by very much) then favoring ISP will be more important... but this isn't always the case. Neither can it be said that swapping to a lighter engine over one with better ISP is not often beneficial, because in many cases it is. The problem with the nuke is that on really heavy vessels (where it's ISP is much more important and its weight less important) it doesn't have sufficient thrust to perform in a manner that most people will find satisfactory (I am *not* doing a 20 minute burn in three kicks); however, once you get to lighter vehicles where its thrust is more acceptable, it's weight becomes a big problem (and you'll probably get better dV out of a lighter engine). There are roles for which the nuclear engine are ideal, but it isn't always the most effective/efficient for a given build.

For what it's worth, I use steam (as I do for most all my other games)... but I'm very sad that I use KSP with steam. It's the one game I won't really play for more than a couple hours without my mods... and if it were up to me, I'd put off updating until my favorite modders caught up (points at Roverdude, stupid_chris, and too many other awesome folks to name) So I'm kinda jealous, I wish mine was non-steam. (You'd never hear me say that about my other games.) I know I could play offline, but that's just annoying (and keeps other things from updating).