Zhetaan

MechJeb just compares your orbital period to the time needed to reach the next transfer node. If it equals more than five orbits (though that is user-editable), then it adjusts the semimajor axis of your orbit by the ratio of (1 + (1.25 / PhasingOrbits))(2/3). If you go with the default number of five orbits, then it's just 1.25(2/3) or approximately 1.16--but the important part is that it adjusts the orbit by enough to guarantee that a transfer window will appear within the acceptable number of orbits in the new orbit, but does not adjust by so much as to be prohibitively expensive in propellant costs. It's not really trying for milligram efficiency or millimetre precision: it's like someone who is travelling through the woods and doesn't know exactly where the next town is, but knows that there's a long river leading to it, and so knows that finding the river--which is a lot easier to do, even though it will add time to the journey--will be good enough as a first step. It's done in terms of ratios, not kilometres, because distance in kilometres has varying importance relative to your altitude. If you're at Minmus's altitude, then orbiting 100 kilometres closer to Kerbin will make a negligible change to your orbital period. If you're orbiting at 75 km altitude, then going 100 km closer will be quite a dramatic change, indeed.

Good catch. I don't have Breaking Ground, so I missed it.

No. The power production falls off with the square of the distance, as it does in reality. Electric charge production is also affected by the panel's orientation, naturally, its temperature, and whether it is an atmosphere. This means that a solar panel that is close to the sun will produce less electricity than the inverse-square intensity calculation would predict because the increased temperature reduces its efficiency and partly offsets the increased insolation. It doesn't completely negate the effect of solar intensity--panels closer to the sun will still produce more EC--but it can be important to know if you want to have a solar-powered station or something operating in that volume of space. This also means that a panel on Kerbin's surface will produce less than one in space at Kerbin's orbit. Keep that in mind if you want to use solar at Eve.

Assuming that your uncontrolled vessel is only drifting, but not spinning wildly, then you can dock with it provided that you can be both precise and fast. In the future, you should know that it helps to leave your target docking port in a normal orientation. You can see whether it is by using 'Control from Here' and watching the navball. As a vessel orbits, it remains in its orientation--it doesn't rotate to keep the same side facing the primary. Thus a vessel in orbit will appear to rotate as it revolves about the primary, but the normal direction is the axis of this rotation, so anything aligned that way won't rotate away from your approaching vessel. Obviously, adding control (even in the form of a cheap probe core) would help, but you should also know that docking to uncontrolled targets is exactly the intended use of the Advanced Grabbing Unit (the claw).

I disagree with it being cheaty; if you're expanding the tech tree, then you need to expand the science pool, and that means re-balancing everything that goes into it. You may not be modelling the change in technological capability in your game, but it's not unreasonable to think that data storage and transmission can improve immensely in twenty years: twenty years ago, some digital cameras recorded images on floppy disks inserted into the camera, and streaming video was ... well, no, it wasn't. That's a big part of it. The RA-2 is literally the worst-transmitting antenna in the stock game. Switch to a Communotron 88-88 or HG-55 (the HG-55, not the HG-5). I don't think you can warp through transmission, but you can definitely make transmissions work better. Since you're comfortable with modding and writing patches, let me give you the essential idea behind data transmission, so that you'll then be able to decide whether to use a better stock antenna or else go in another direction. Science is transmitted in units called mits. It's like a bit, but mumbled. Individual experiments have fixed mit values. This is not automatically related to the science value of the experiment--that depends on whether you're recovered the experiment before, where you did the experiment, and so forth. For example, a temperature reading always has a value of 8 mits, but the science value changes if you take the reading in low orbit of Jool instead of Kerbin. Mobile Processing labs factor the science multipliers into the conversion to data, which is a trade-off: you transmit science from the lab at a transmission rate of one mit per science point, so you need more and longer transmissions for the same mit value of experiments as you collect them from higher-yield situations. Of course, the lab multiplies the data value, too, so it's a net positive, but you knew that already, I think. Antennas gather mits into bundles called packets, and different antennas have different packet sizes. The HG-55 has a packet size of 3 mits, the RA-2 has a packet size of 1 mit, and all other stock antennas have a packet size of 2 mits. Antennas also have a packet interval, which is the time taken per packet transmission. The reciprocal of this value is the number of packets per second, and taken with the packet size gives the transmission rate in terms of mits per second, or, if transmitting from a lab, science points per second. The HG-55 has an interval of .15 seconds with a packet size of 3, and the Communotron 88-88 has an interval of .10 seconds with a packet size of 2. This means that they both transmit science from a lab at a rate of 20 science per second. Lastly, antennas have packet resource cost, which is simply the EC used per packet. I get the impression that you don't have an electrical scarcity problem and are more interested in speed, but for your information, the HG-55 has a relatively low EC cost per mit but its high transmission rate means a high EC cost per second. The 88-88 is the worst in terms of electric use per second (but the RA-2 is the worst in terms of EC per mit). Anyway, if you're transmitting something of roughly 5,000 science points per transmission (though probably less given diminishing returns), then doing it through an RA-2 will take about half an hour. Using an HG-55 will do the same thing in four minutes and ten seconds, though at roughly double the electricity per second (but at one quarter the total electrical consumption). If you should decide to mod an antenna, then you will want to increase the packet size, decrease the packet interval, or do both in order to reduce the transmission time.

Atmospheric attenuation. Here's a link to a relevant post. It's six years old but still accurate. The Gigantor solar panels are rated for 24.4 ec/s at Kerbin's orbit, as in at Kerbin's distance from the sun, absent any intervening obstacles. Intervening obstacles can include the Mun during eclipses, Kerbin itself (Kerbin tends to shade the panels a bit at night), and atmosphere. Because of this, the surfaces of the inner planets are actually some of the worst places in the solar system to use solar panels: solar panels at Eve sea level (with 5 atm of pressure) tend to be about two-thirds as efficient as panels at Kerbin orbit, and Moho's 61-day night (owing to its crazily-long rotation period with respect to its orbit about the sun) is something of an issue, as well. High temperatures affect panel efficiency, too. In the linked post, testing showed that near Kerbin sea level, Gigantors produce something in the neighbourhood of 21.5 ec/s at noon and get worse from there. Near sunrise and sunset, they make less than 1.5 ec/s. I don't know the decay curve, but there's no way that the average output is more than 90 ec/s over the course of the day. Another possibility is how many converters you are running on your converters. By that I mean to say that the Convert-O-Tron 250 has four converters on it: Monopropellant, LF, Ox, and LF+Ox. Each of those converters is a separate process, and so each will pull 30 ec/s to run. (They will also overheat the part if you try to run more than two, I think). Many players use fuel cell arrays rather than solar for their conversion processes, since the cells consume less than the converters produce, still generate respectable power, work at night, and don't break off in atmosphere. It chafes at my understanding of thermodynamics, but it's a valid gameplay strategy.

Yes, yes it is. Near space over the sun is far enough away, in relative terms, that a typical Hohmann transfer orbit is no longer the most efficient way to do it, and you're better off using a bi-elliptic transfer, instead. That's similar to what you've been doing, but your problem right now is that you're burning at an apoapsis that is far too close to the sun to be efficient. You'll want to boost all the way out to Eeloo at the least. Farther is better and, counterintuitively, more efficient, but don't go so far as an escape orbit. You'll need to keep in mind the contract deadline, too. Once you're at your supra-Eeloo apoapsis, burn retrograde to bring your periapsis down from Kerbin to the sun as you have been. This has the additional advantage of making your periapsis transit faster, so perhaps you won't burn to death (or at least get by only slightly crispy about the edges). Remember that you're not near the sun for the purposes of science experiments until you're under one million metres in altitude, so I hope you brought thermal protection. Thankfully, you can take the measurements while flying by--you don't need to circularise. The other things that you can do are all the standard advice about designing your vessel properly for the mission, so picking the right engine (for a 500-tonne vessel, it won't be ion engines or Nervs), taking only what you need and nothing else, setting up clever staging, and so forth. On an unrelated note, welcome to the forum! As newer players go, you're certainly ambitious, but that's not a bad thing. Good luck, and if you have any other questions, then please feel free to ask.

Unfortunately, it doesn't work that way. You're seriously overestimating the performance of this engine. I can show you why: we can work though the delta-V calculation backwards to get an idea of whether your guess is feasible for a vessel. Let's say that we want your guesstimated values, and since I like calculation, I'll cover both ends of your range. For 8,000 m/s of delta-V with a Nerv, we need a wet-to-dry mass ratio of 2.772. This requires a propellant mass that is 1.772 times that of the dry rocket, or a wet rocket that is 63.9% propellant. To have .5 thrust-to-weight, this rocket would need to push no more than 12.24 tonnes per engine. 3.00 of those tonnes are taken up by the engine itself, 7.82 tonnes are in the propellant, and the propellant tank takes up another .87 tonnes for a total of 11.69 tonnes. That leaves .55 tonnes, or 550 kg, for remaining payload, and of course does not account for the fact that there is no propellant tank that offers exactly 7.82 tonnes. One can string together multiple engine modules to keep the same overall performance and increase the payload, but that is the shape of the problem. For 10,000 m/s of delta-V, it works out that you need a wet-to-dry ratio of 3.58 and an attendant propellant mass of 2.58 times the dry rocket, or 72.1%. At .5 thrust-to-weight ratio, that means that you're still limited to 12.24 tonnes per engine, but now 8.83 tonnes are taken up by propellant, .98 tonnes are taken up by the tank for that propellant, and 3.00 tonnes are in the engine. That adds up to 12.81 tonnes, which is over-budget and leaves no room for payload. You may certainly choose to have a lower thrust-to-weight ratio, but it is not possible to combine the Nerv engine with a propellant load to have a .5 thrust-to-weight ratio and 10,000 m/s of delta-V.

You actually do need to install the mod before you run the game. If you try to install the mod on the fly, then you'll be disappointed. That's because the game loads its assets (including mod stuff) at the beginning when it starts up. Other issues that crop up with this kind of thing include forgetting to unzip a compressed mod download, failing to install a dependency (that's when the mod that you want needs another supporting mod to function--usually, mod makers are pretty good about including them in the download), or installing the mod in the wrong folder. For example, a lot of mods come packed in a folder called GameData, and sometimes, people install them in such a way that they get a KSP\GameData\Gamedata (or more, I once saw someone who nested it five times). When a mod comes in a GameData folder, the intent is that whatever is in the mod's GameData is what goes into your GameData--you need to copy the contents, not the folder. Otherwise, @jimmymcgoochie's link is to an excellent tutorial, and if you can't get it to work after reviewing that, then I'd say you've got a bug and should re-install.

I came along to make a similar point, so while @4x4cheesecake may be right in that most won't read the rules, I am evidence that others will and have noted the same problem. I think that there are enough detail-oriented people here that making the full rules visible in the 'Read Before Proceeding' page is worth consideration. Additionally, I'm not certain about how much flexibility the forum offers to put such things outside the wall and make them visible, but I think that there's merit in including some specific threads and posts out there, as well, such as the Good Conduct Guide and others. That said, I get the distinct impression that this was more of an administrator decision rather than a moderator one, so you have my apologies if I am directing this to the wrong people.

Yes. However, the savings are modest enough that the choice between efficiency and rocket complexity is a serious one, and there are compelling arguments on both sides. Here's an example: Let's say that you have a 45-tonne rocket being pushed by one Nerv. That's a bit low on the TWR scale (it's only about .136) but that's fine. We're not looking for good burn times here. Let's say that our fictional rocket is bearing two Mk. 3 liquid fuel short fuselages. That's 14.29 tonnes per tank when full, of which 12.50 tonnes is propellant. Let's also assume that the rocket is built with reuse in mind--meaning docking ports rather than decouplers on the tanks--so that adds .2 tonnes (for a Clamp-O-Tron Sr.) to each tank. It also adds .2 tonnes to the main vessel, but we can ignore that because we're not staging away that port. A 45-tonne Nerv rocket with 25 tonnes of propellant when full, provided that you run it until it's empty as a single stage, has a mass ratio of 2.25 and a delta-V of 6,362 m/s. Let's say that, instead, we opt for a two-stage operating paradigm. The first stage is a 45-tonne Nerv rocket with 12.5 tonnes of propellant, a mass ratio of 1.38, and a delta-V of 2,553 m/s. Then we stage away the 1.99-tonne empty tank and docking port, leaving us with a 30.51-tonne Nerv rocket with another 12.5 tonnes of propellant. This rocket has a mass ratio of 1.69 and a delta-V of 4,135 m/s. Thus, the total for the two-stage design is 6,688 m/s. That's 326 m/s over the single-stage design (that's more than 5%), and all of it comes from not needing to push around an empty propellant tank. However, 5% may not be worth it to you, especially when you consider that replacement tanks need to be sent up from Kerbin (or recovered somehow--likely for a lot more than 326 m/s) and it means sacrificing your potential propellant load until you can get those replacements. For a one-off rocket, that makes a lot of sense. For a reusable rocket (that only operates in space--launch platforms are a different matter), it makes less sense. If you plan on ISRU, depots, or other tricks to resupply, then the tank is more valuable than the propellant savings. You ought to be familiar with that side of planning: you can save propellant by not sending Kerbals, too, but the capsule is more valuable than the propellant savings of not sending one, so it goes on the mission. In like fashion, when refuelling is a part of the mission, the empty tank technically becomes part of the mission payload rather than parasitic mass.

OPM doesn't really directly affect the capability of vessels; it only extends the boundary for long-term missions. USI-LS does change the capability of vessels by increasing the necessary life support payload (and thus reducing the available payload for other things that you might have wanted to take). The amount that it affects depends on how many Kerbals you're taking, what kinds of amenities you have for them, and the difficulty settings for the mod. As others have said, there are no easy answers, but we might be able to rough out a solution space based on the kinds of things that you might want to do with such a vessel. First, I will assume that you will have enough Nerv engines to give a thrust-to-weight ratio of 0.2, and this is simply for the sake of your own sanity. The Nerv has a thrust of 60 kN, so 0.2 TWR means a maximum weight of 300 kN per engine. Take out the gravitational acceleration (TWR is a ratio of Kerbin weight unless specified otherwise) and that leaves 30 tonnes per engine (30.6 if you want to be more precise). Out of that 30 tonnes, 3 are the engine itself. Out of the remaining 27 tonnes, you can choose to use the Mk. 3 short fuselage, up to 12 Mk. 1 fuselages (though you won't actually want to use all 12), or you can add engines and divide a larger tank between them. Let's say that you use 10 Mk. 1 liquid fuel fuselages. That's 22.5 tonnes in tankage and propellant. 20 tonnes is in the propellant. Add 3 tonnes for the engine, and that leaves 4.5 tonnes for assorted other stuff. That's a payload fraction of 15%. That's a lot less than I'd like for a long-term mothership, but reusability eats into payload fraction with a certain ill-tempered voraciousness. If you need more payload, then add another 10-tank + Nerv engine module, and you'll have 9 tonnes of payload to use. The delta-V for such an arrangement (which is a wet/dry ratio of 3) will be 8,619 m/s. With no payload (or control, but this is just playing on paper), the wet/dry ratio is 4.636 and the available delta-V would be 12,034 m/s--but none of it would be useful. Therefore, you can go from 8,619 m/s for a fully-loaded rocket up to something approaching 12,000 m/s for an unloaded rocket. More payload than the maximum reduces the TWR to unacceptable levels, and less payload than just the propellant tanks and engine is not possible. Those are the boundary conditions for this design. Let's say, instead, that you want to use three Nervs and one Mk. 3 long fuselage. That tank is 57.14 tonnes (50 of which is propellant), and the engines add nine tonnes to that for a total of 66.14 tonnes out of a total target mass of 90 tonnes, thus leaving 23.86 tonnes for whatever else you want or need. That leaves a potential payload fraction (again, only on paper) of 26.5%. The total wet/dry ratio is 2.25. The delta-V of such a rocket works out to be 6,362 m/s. Unloaded, the delta-V is 11,066 m/s. Again, you can't actually achieve that, but it shows the maximum available range if you should choose to have a higher TWR with a partially-loaded rocket. Please note that I'm not certain that you can keep your Kerbals alive and sane with USI-LS for an OPM-scale trip with only 24 tonnes of available payload for life support. And, of course, using that much payload for life support leaves you with none for the actual mission. On the other hand, the propulsion module (1 tank + 3 engines) is a beautifully low part count, so you can multiply it easily. On the gripping hand, you could always send probes. Probes are cool. Remember, Mars is the only planet known to be inhabited entirely by robots.

This comes off as cheeky, but ... ... cancel the mission. That's not to say that it can't be done--I'm a staunch completist, so I'd chafe immensely at the idea of quitting a mission in my own game--but one of the things that I've learned is that KSP often likes to throw improbable and impossible missions at you. The improbable ones serve to provide crowning moments of awesome in the event that you do actually manage it, and the impossible ones serve to provide experiential learning in how to cope with frustration. Also, you've probably got years in-game before the contract deadline, so you can afford to do some other missions, get some science points, and unlock technology that will let you do this mission ... provided that it is, in fact, possible. You may want to prioritise upgrading Mission Control for the sake of more contract slots, though.

There is. The calculations don't include the Mun, and there may well be some advantage on repeated flyby assists (such as the K-E-K-K-J route uses), but here are the top five for delta-V, starting from a 75 km Kerbin orbit: Flight Delta-V Total Travel Time Departure Eve Encounter Jool Encounter Eeloo Encounter 1 3401 11.3 years Y2 : D2 : H0 Y3 : D80 : H2.8 Y6 : D347 : H3.8 Y13 : D135 : H5.7 2 3453 11.5 years Y2 : D6 : H0 Y3 : D80 : H2.8 Y6 : D419 : H2.1 Y13 : D232 : H0.7 3 3460 10.1 years Y1 : D404 : H0 Y3 : D65 : H2.8 Y5 : D384 : H0.7 Y12 : D29 : H2.6 4 3482 11 years Y1 : D420 : H0 Y3 : D73 : H0 Y6 : D239 : H2.1 Y12 : D425 : H4.3 5 3506 11.7 years Y2 : D10 : H0 Y3 : D80 : H2.8 Y7 : D51 : H0 Y13 : D313 : H1.1

Slashy! When did you get back? It's nice to see you around. Anyway, to avoid going too far off-topic: Everything in rocketry is a trade-off, so different needs emphasise different things at different times. Having 70,000 m/s of delta-V on the pad is worthless if the rocket lacks the thrust to lift off. Slashy is correct in that payload fraction is a good choice for getting things into orbit. 'Bigger = more powerful' is really not applicable here, but to get you started, it's better than nothing until you get more of a feel for it. And definitely stay away from SSTOs for now. They offer intriguing possibilities, but none of the order that I think you're looking for presently.

Others have answered this, but I wanted to mention that the KSP Deep Space Network is named for the real-life DSN, and I have included a link that will take you to a real-time representation of the actual satellites with which the DSN is currently communicating.

There are two little tricks that you need to know before you start calculating. The first is that orbital period is dependent on the semi-major axis, not the eccentricity. This should make sense if you think about it: let's say that you're orbiting the Mun at 100 km at any arbitrary eccentricity. Where is the 100 km point on that orbit? Is it the apoapsis? Is it the periapsis? Is it somewhere in between? Any orbit that has a periapsis at or below 100 km and an apoapsis at or above 100 km will pass through the 100 km altitude at least once, but without knowing more about how that orbit is arranged, the altitude and eccentricity do not help. That being said, it is true that the eccentricity is derivable from the same information that gives you the semi-major axis in KSP: the apoapsis and the periapsis. This leads to the second little trick: the altitude given in KSP is measured from the surface of the celestial body, and in order to get accurate information, you need to account for the body's radius. This information is found in the Tracking Center. It's in the Knowledge Base button that tells the planetary characteristics, (it's the one that looks like a planet with a ring around it; it should be between the one with an i and the one that looks like a planet with a wedge carved out of it) and it's the Eq. Radius parameter that should be at the top of the list that opens when you click on it. ... Or, I suppose, you can find the information on the wiki. Anyway, on to translating the Wikipedia article: Wikipedia shows you two ways to calculate what you want. The first is the calculation of orbital period from the semi-major axis, and the second is calculation of the semi-major axis from the orbital period. I will reproduce the formula here to assist with the explanation: T = 2π √(a3 / μ) Where: T = the orbital period (in seconds), π = the mathematical constant, approximately equal to 3.14159265 (I generally prefer to carry precision out farther than it will ever be necessary and round off later), a = the semi-major axis (in metres), and μ = the Standard Gravitational Parameter, a value which depends on the celestial body. It is equivalent to the universal gravitational constant, G, multiplied by the body's mass, M, and so some depictions of the formula will show GM instead of μ. The symbol is the Greek letter μ pronounced roughly as 'myoo'. The value of this number is also available in the Tracking Center, in the same place as the equatorial radius. It's listed as GM and is a couple of lines down from the radius. For the Mun, it is equal to 6.514 x 1010 m3/s2 according to the Knowledge Base button, but the more accurate value is 6.5138398 x 1010 m3/s2. Let's start with a circular Mun orbit of 100 km. That would be, therefore, 100,000 metres. (Metric prefix notation is nice, but this is astronomy. Confine yourself to base units and use scientific notation when you need it; it's less confusing that way and you'll be less prone to make mistakes.) Any orbit of the Mun will need to add 200 km to its altitude to get its true gravitational distance; this means that your circular orbit will actually have a radial distance of 300,000 metres. Since the orbit is circular, the radius is equivalent to the semi-major axis (had it not been circular, then you'd need to average the apoapsis and periapsis distances), so that's the value we want. Therefore: T = 2π √([300,000]3 / [6.5138398 x 1010]) T = 2π √(2.7 x 1016 / 6.5138398 x 1010) T = 2π √(4.145020576 x 105) T = 2π * 643.8183 T = 4045.23 seconds (optional conversion) T = 4045.23 seconds * (1 minute / 60 seconds) T = 67.42 minutes The second formula in the Wikipedia article is the same as the first, but algebraically manipulated to find the semi-major axis variable when all other information is given. It's popular for finding the synchronous altitude (using Kerbin's data to verify the stationary orbit is an exercise I leave to you), but you want a three-hour orbit of the Mun, so let's work on that. Here's the formula: a = 3√(μT2 / 4π2) The symbols mean the same as in the previous formula. I direct your attention to two things to note: first, the 3√ means cube root, and sometimes you'll see the cube root of some x-value, 3√x, represented instead as x(1/3). The two notations are equivalent. Second, note that I condensed the GM given in the wiki to the μ of the first formula. This was only for consistency. The only preparatory work needed here is to convert three hours to seconds. That's easy enough: T = 3 hours * (60 minutes / 1 hour) * (60 seconds / 1 minute) = 10,800 seconds Now we need to put everything into the formula. The rest of the parameters we know from above, so I will save some time and copy mercilessly: a = 3√([6.5138398 x 1010] * [10,800]2 / 4π2) a = 3√([6.5138398 x 1010] * [1.164 x 108] / 4π2) a = 3√([7.5978106 x 1018] / 4π2) a = 3√(1.9245479 x 1017) a = 577,534.97 m This is the answer, but we are not finished. We need to subtract off the 200,000 m of the Mun's radius. By the same assumptions as before, the semi-major axis of a circular orbit is equivalent to the orbital radius: Altitude = 577,534.97 - 200,000 = 377,534.97 m Put a vessel at that altitude and you'll have your three-hour orbit. You can round up to 377,535 m, if you like.

You're in luck. The craft organisation functionality was added to the new version that they released today. (On the link, scroll down to where it says 'Craft and Save Loading Improvements'.) Since you're on Steam, you probably already have this update.

That orbit does not have a Mun encounter, so you won't get a Munar orbit without a burn while still in Kerbin orbit. You did have a close approach (the close approach markers are directly below your vessel and directly to the right of the Mun), but from that screenshot, you have just passed that point of closest approach. On a side note, your apoapsis is very high. This means that, even were you to get an encounter, it would not be ideal. This is for several reasons. First, you're expending propellant to send your vessel to a too-high apoapsis and getting no benefit from that, so it's wasted propellant. Second, you'll need to burn to undo that velocity addition when you do get a Mun encounter, so it's actually double wasted propellant. Third, that kind of right-angle cross of the Mun's orbit will put you at a manoeuvring disadvantage when you get into the Mun's sphere. You'll end up with a lot of radial velocity and that's not often a good thing. The ideal low-cost transfer approach is along a tangent to the target body's orbit. This means that you want your vessel's apoapsis to barely touch the Mun's orbit. Burn retrograde at Kerbin's periapsis to bring down the apoapsis. However, don't burn all the way to make a circular orbit. You've got an orbit that reaches Mun orbit, so we can work with that and not waste too much propellant. Instead, burn to bring down the apoapsis to near the Mun's orbit, and as you get it closer to the Mun's orbit, an encounter should appear. Then you just need to wait.

Correct for a vessel that is inside the Mun's sphere, yes. For a vessel just outside the sphere, then you accout for Kerbin's sphere and ignore the Mun entirely. It's all one or all the other. You're actually down a body. The two bodies in the 2-body problem can be two massive bodies, or they can be a massive body and a negligible-mass body. The difference pertains to whether the mass difference is enough for you to effectively treat one body as being at rest. At a certain mass threshold, that approximation no longer holds. Also, in the real world, you'd have to consider not just the gravitational influence of the sun, but also the radiation pressure, drag from any wisps of atmosphere, the effect of uneven mass distribution throughout the celestial bodies, precession occurring because of relativity, the possible influence of Jool (I never have gotten a good answer about Jool-driven perturbations of a realistic Kerbin system orbit--probably because the Kerbin system isn't completely stable in realistic physics), and other factors. It's less a hole and more a piecewise-smooth function with derivatives equated at the boundaries to effect an equally-smooth kinetic energy handoff at the transition within the limits of the fact that the velocity vector is changing direction. In less technical terms, it's a discontinuity in the strictest sense, but it is deliberately engineered to slot into the space in as smooth and unobtrusive a way as possible (while also allowing for the fact that there's a massive body there, obviously). You've got the right idea. However, I would point out that, like most things KSP, there's a mod for that. It's called Principia and simulates n-body physics.

In real life? Surprisingly, yes. However, that's dependent on the fact that there is no such thing as a perfect rendezvous and that gravitational interactions are affected by tidal forces from the sun, non-uniform mass distribution of the celestial body, and other perturbations. Comet C/2012 S4 (PANSTARRS) has a calculated aphelion of something around 8 light-years--though that owes more to the error in measurement than to astrophysics--but it is not escaping. It is listed as a near-parabolic comet. The technical term for deviation from a Keplerian orbit (since Kepler so unhelpfully took the term anomaly for himself) is osculating orbit, and the osculations can absolutely perturb something into a capture (or an escape, or a crash--which is the eventual fate of nearly everything in low-Earth orbit). In KSP? Also, surprisingly, yes--but it depends on exploiting the nature of the game. It's not a true gravity assist, and on paper, gravity assists cannot do what you want. Essentially, you can get very, very close to a perfect rendezvous, but there is a recalculation when you cross the sphere of influence boundary. If you get the right precision error in the floating-point mathematics, then you lose a few bits in the orbital energy and what was a near-capture hyperbolic orbit becomes a near-escape elliptical one. However, I have not seen this in years--it was never common anyway, and I believe that the devs changed the sphere boundary calculation to avoid unwanted perturbations, as well.

The best part is that this is almost true-to-life: Anyway, seriously, you can also load up your pod with every experiment you have access to and do those experiments on the pad. Be careful about rolling around with them, though, because they tend to have low impact tolerances and weird shapes.

It won't unless you get the actual encounter. Gravitational influence is an all-or-nothing thing in KSP: you're either in the Mun's gravity or you're not. Where the game thinks that will happen, the blue line of your vessel's trajectory will turn brown for the portion that falls inside the Mun's sphere of influence (and where it comes back out again, it will change again to purple). I should let you know that there is an art to moving things around in space that simply is not intuitive for people who are used to moving things around on the ground. Reading the navball is a technical skill all in itself. To help you, I'll go with your description of the burn that you gave just after my last post: So far, so good. Clicking prograde is the right thing to do. It's not the very best thing, but that's okay; you're learning. For now, it works just fine. I will say that you may want to consider node hold () instead of prograde hold () since you have a manoeuvre node set up, but for this manoeuvre, the right time to burn is about when they point in the same direction anyway. So far, so good. What I want to make certain that you understand is that the 850 m/s is not meant to be your final orbital speed. The 850 m/s here is the change from your starting velocity at the point of the burn, but this is one of the things that is not intuitive about rocketry: the starting velocity is not zero. Generally, it is never zero. It isn't even zero when you're on the pad; that's why it's to your advantage to launch to the east, for example. To illustrate, imagine that you're driving down a highway at a typical, albeit slightly slow 25 m/s. You would like to go a bit faster, so your intuition is to say that you will, for example, increase speed to 30 m/s. For a rocket, the same manoeuvre is 5 m/s. You can see where we get that 5 m/s, but the part that is not intuitive is that we drop all reference to the initial and final velocities when we do so. There are lots of good reasons to do this that make sense for rockets, but the important part is to remember that rocketry manoeuvres are changes and that they are measured as amounts of change, not target velocity values. The 850 m/s does not add directly to your orbital speed, either. The reality is much more complicated, because once you change your orbit, you change your velocity, and of course your position on the orbit is changing, as well, plus there are errors and losses that factor, so you generally should not treat the burn velocity as being strictly additive. The clicks are simply visual markers; you should have finer thrust control than that. The only thing in your navball that would read that high at that point is your orbital speed. That's the little panel with green text at the top of the navball. That is not your delta-V. Delta-V needed for a burn is the bright green text in a grey box to the right of the navball. I covered this above: 850 m/s is not your target final velocity; it is your change in velocity from the burn. Actually, since you're going prograde, you'll want your final velocity to be higher than your initial. You are, but this one is easy to correct. If you're going from 125,000 metres to 11,000,000 metres or so, then at 3,000,000 metres, you shouldn't be burning at all. One of the first principles of moving around in rockets is to conserve propellant. What that usually means is that you burn hard where it will do the most good, and then you coast the rest of the way to a point where you burn hard again, again where it will do the most good. The essence is that you have long, languorous journeys doing nothing at all, and these are punctuated by rare and sporadic fits of extreme activity. At 3 million metres, there might be a case to make a minor correction burn for inclination or to refine the encounter at the Mun. Burning prograde there, though, will not help and may hinder you. Should you? Yes. It will make learning easier because it will give you additional helpful information. You don't need to wait; you can click and drag the map view to orient the Mun where you like it. Kerbin should be the vertex of this angle. I assume that you meant that your vessel should be at the 7 o'clock position. That is backwards. The transfer angle for a Mun transfer from 125,000 metres is 110.5°, so wherever your manoeuvre node is, you want the Mun to be 110.5° anticlockwise from there. If the Mun is at the 12 o'clock position, then you want your rocket (or at least your manoeuvre node) to be roughly at the 4 o'clock position (it's actually a little less than that; put it between 3:30 and 4:00). Alternatively, if you put the Mun at a bit more than 45° clockwise from the top (roughly 2 o'clock), then you want to put your manoeuvre node at the 6 o'clock position. Choose whichever visual orientation is easier for you. You can afford to be less than precise here because the Mun is big, close, and very forgiving for people who are learning this. You'll need to be more exact literally everywhere else, but the idea is to learn the basics before we move on to refinements. Yes. You want it to touch. The number is less important--it could be a bit higher or lower depending on a lot of things--but that's a good value. However, you don't stop there. You will also want to adjust the line for an encounter. That means that, after pulling on the little green prograde handle to get the line to touch the Mun's orbit, you click the greyish circle that those handles come out of and move the node around on the orbit. Watch the point where the line touches the Mun's orbit; when you get the encounter, you'll see it change. Part will turn purple, there will be new icons that show up, and it may look a little weird--that's just KSP calculating what the encounter with the Mun will do to your predicted orbit. That's something that you'll need to deal with, but the important part is that you only need to deal with it because you've successfully gotten a Mun encounter. Manoeuvre. Even when you're flying towards a target, don't click on Target. There is a specific case that requires it, and you'd be forgiven for thinking that this is it, but oddly enough, flying to a target is just about the worst possible time to use Target. That's because Target points to where the Mun currently is, as in right now--so if you fly there, then you'll arrive after the Mun has moved on in its orbit. You'll end up constantly chasing it, only to arrive at where the Mun used to be. Much like throwing a ball to someone who is running, you need to lead the target and throw your rocket, not to where the Mun is, but to where the Mun will be when it gets there. Burn at the right time. Burn time depends on your rocket, because rockets all have different masses. KSP tries to predict the burn time for you; it displays this calculation near the bottom right of the navball along with the node countdown clock. It is best to split the burn in half, putting one half before the node and one half after, so you should start a little early, but for a burn this short and close to Kerbin, it's okay to start on the bell rather than trying to be technically perfect just yet. When you burn, burn at full thrust. This is Z on the standard keyboard layout, though you may want to check if you're not using a US English keyboard. The most efficient burns are the shortest burns, and for dumping a lot of energy into your orbit in as short a time as possible, there's really no reason to do anything less than full power. Lower thrust is good for landing and fine corrections. Nuts to that; we're going to the Mun. Press X to shut the engine off when the burn is done. When is the burn done? Watch your orbit--this means staying in map view. You can switch back to flight view for staging and such but map view shows you everything that you need to see. When you see your blue orbit trajectory line jump and add extra icons and do all the weird things that the manoeuvre node prediction did when you planned it before, you've gotten the encounter. You can fine-tune the trajectory (this is a time when low thrust is useful) but you've got the encounter. After that, it all depends on what you want to do. I suggest that you do flybys and not worry about orbit and capture until you can get Mun encounters and transfers predictably, but if you want to do capture and orbit of the Mun, then we can help you there, too.

The short answer is no, you don't have to do that. Should you? It helps. It makes a difference in that by setting the Mun as a target, the game knows what you're trying to do when you set up a manoeuvre node, so it can provide helpful information such as your predicted closest approach, relative inclination, and other data that can assist you in getting the encounter. There are relatively easy ways to get a Mun encounter without needing to set it as a target. Some ways, as others have mentioned, allow you to get the encounter without needing to set up a manoeuvre node, either. However, some of these techniques take advantage of unique circumstances particular to the Mun and are not broadly applicable. I don't know whether you've worked on rendezvous yet, but the principles are similar. For an encounter, you want to reach the Mun's orbit at the same time that the Mun will be at that point in its orbit. Doing this is complicated in real life but relatively easy for the Mun because the Mun happens to be in a perfectly circular, equatorial orbit. The Mun was designed this way deliberately in order to give you a good chance to practise the technique before going on to more interesting (meaning complicated and difficult) transfers and encounters later on. There's nothing wrong with eyeballing a transfer, or setting up a node without setting the Mun as a target. I would advise you, though, to play with the node planning controls a little. Try dragging the node around on your orbit (you can click and drag the node) to see how that shapes your encounter. Or, if you don't have one yet, so long as you have an orbit that reaches high enough to cross the Mun (and it's equatorial), then you'll get an encounter at some point by dragging the node around your orbit. See how changing the planned burn changes the predicted encounter. Don't be afraid to delete it and start over. At some point, you'll start to get a feeling for how you should plan your burns in order to go to the Mun.

I detect an issue, not necessarily with piloting, but rather with reading the map. That's a skill all in itself. The first thing to know about the map is that it is not like a static map of anything on Earth. In space, everything is moving relative to everything else, so what you see in map view is a combination of a snapshot of where things are right now combined with predictive plots that are an attempt to give an idea of how those things are moving. (Though I will note that by convention, the sun is considered motionless in order to provide a reference point.) In terms of plotting manoeuvres, the first thing to know is that your rocket's current, immediate trajectory is always going to be the solid blue line. If that path should go into a new sphere of influence (that's where a body other than Kerbin is the strongest local source of gravity, as in close approach to the Mun, for example), then it will turn solid brown at the point where it crosses into the new sphere of influence. There are other colour changes for additional interactions later on. The second thing to know is that when you plan a manoeuvre, the map view will generate a dotted line that will show your predicted path if and only if you execute the plotted manoeuvre. Think of a manoeuvre node as something more akin to an itinerary than an automatic program. You can plan to get off the train at a particular station, but unless you actually get up and leave the train at the right time, it won't happen on its own.