Zhetaan

Let's go through this in order: Your example is not the best; the Mun cannot give enough of an assist to get you all the way to Duna. However, it can take 500-ish m/s off of the delta-V cost. The problem is one of trade-offs: at minimum closing velocity (which is also minimum fuel, i.e. a Hohmann transfer), the Mun gives enough of an assist to throw you into deep space, but not enough for you to reach anywhere but Kerbin. You can burn towards the Mun for faster closing velocity, but then your trajectory will turn less and you'll get less from the assist. The following post offers a lot more information. It's old, but gravity hasn't changed much in the past six-and-a-half years: You might consider a form of practice to test the theory: consider that if the Mun can throw you into deep space, then it can get you an assist to Minmus. Played the other way, a flight from Minmus to the Mun can give you braking to a lower Kerbin orbit. Remember that all of the rules for interplanetary transfer apply to trips from the Mun to Minmus and vice versa. Adding assists to it is not difficult, and the best part is that the Kerbin system repeats its configuration so quickly that you can get a good intuition for how to put together these kinds of gravity assists before you try it on planets orbiting the sun. You'll need a delta-V map (or to calculate the transfer cost yourself) and you'll need some idea of how much you'll save from the assist. Let's assume that you found a great assist or series of assists. Then you need the delta-V to launch to the first fly-by, and the delta-V necessary to brake at your destination, and ... that's it. Ignore the rest of the delta-V map. You'll need a manoeuvring reserve for corrections, but not having to burn it is rather the point of saving propellant. Put differently, gravity assists are not about delta-V so much as they are about timing. Normal interplanetary transfers are about timing, too, but your use of propellant allows you to shift the variables to favour your mission: you can set the correct direction and speed by the use of propellant. With gravity assists, you are totally dependent on arriving at your destination at the right time so that your flyby sends you in the correct direction and at the correct speed without further input from you. That will definitely work. I'll caution you to ensure that you set the patched conics limit to something high, like six or more: if you don't, then the map view will stop displaying your predicted trajectory before you know whether it will actually get you to your destination. If you want to plan it by trial and error, then yes, you'll need to have something in orbit. It need not be the vessel that will make the journey; you can use something else that is already in orbit and it won't be a problem. This is generally desirable, though: starting from low Kerbin orbit ensures that you can launch within about fifteen minutes of the ideal transfer window (since low orbit has a period of about thirty minutes). Starting from the ground leaves you with a minimum margin of three hours. This is usually surmountable, however, because you can build corrections into the launch burn. More important is the fact that starting from orbit offers more potential savings via the ability to split the launch burn into several well-timed apoapsis-lifting burns, which saves propellant in low-thrust vessels such as ion-powered probes. There are two ways. One involves the use of a tool called Flyby Finder. It's a good tool, albeit it comes with some limitations. It cannot calculate double assists, and it is not the most easy-to-use. Read the manual first. The initial post for Flyby Finder also has a link to a spreadsheet that can calculate double assists, but it's definitely not user-friendly. The second involves figuring out what you want to do by hand. This is not quite so daunting as it seems, because gravity assists are not so much difficult as they are picky about timing. Provided that you know the orbital periods of the planets, you can set up simple assists just as easily as interplanetary transfers--which are not easy, of course, but it is possible with the stock tools. Once you have chosen a path, it's simply a matter of picking a launch time that fits the window. You'll need to do a bit of correction, simply because there's no way to reliably repeat a launch without a launch script or other automating mod, but it is absolutely possible. Neither. You want to time it so that the planet is where your spaceship is by the time your spaceship gets there. Once you leave Kerbin, Kerbin's location ceases to be relevant. It is the shape of your vessel's orbit that is the important part. You are correct that timing that launch is something that can be related to the relative positions of the planets; the angle between your origin planet, the sun, and your destination planet is called the phase angle and it's different for every interplanetary path. This is because the orbital periods of the planets are different, and more importantly, the ratios of the orbital periods are different. There is a Kerbin-Eve-Kerbin-Kerbin-Jool path that can get you to Jool for less than 1,100 m/s; the typical transfer cost is about double that. Provided that you get the timing correct, there is a lot of delta-V to be saved by using Eve to go anywhere and Tylo or Laythe to go anywhere at Jool. For example, you can do this: I'll include a link to the general tutorial on the subject: This is a YouTube video that covers a lot of the basic principles, and it also has the benefit of being less than a year old: I know that we're on version 1.9 rather than 1.7, but a lot of the other tutorial videos out there are from version 0.90 or earlier. Good luck!

This will get you started: https://wiki.kerbalspaceprogram.com/wiki/Debug_Toolbar If there is anything there or in the menu that you do not understand, then we'll need more information about what it is that you want to do.

I see that you decided on a flyby, but I'll answer your question anyway. The cheapest way (technically the only way, if you want to be pedantic about it) to reduce the delta-V you need to capture around Moho is to reduce the difference between your velocity and Moho's velocity. Since you can't do it with fuel, your only option is gravity assists. You'll be coming in faster than Moho, assuming that you're in a Kerbin-Moho transfer orbit, so that means braking assists. Moho's small size and close proximity to the sun mean a lot of tiny assists, because Moho can't do much for you. However, not much is better than nothing, so it can be done--it's a matter of patience at that point.

In essence, that is correct. The bullet gets an assist, albeit not a gravity assist. Any time there is an elastic collision in physics, there is an energy and momentum exchange. (Technically, inelastic collisions combine energy and momentum, but that is also a type of exchange.) What makes it an assist is that you can arrange matters so that the exchange is favourable to the bullet for whatever purpose you have in mind. The part that will really warp your mind is that a gravity assist is an elastic collision. The reason for this is because the physical definition of a collision is the momentum exchange, and if, as in this case, momentum can be exchanged through forces that act at a distance, then it is not necessary for mechanical contact to occur (I say mechanical because physical contact does indeed occur). This is not quite such a stretch for the imagination, when you think about it. Matter, in the atomic sense, is mostly empty space (and amazingly so; I cannot properly relate the scale of it), and the reason that your fingers don't plunge through the keys of your keyboard is because of the mutual repulsion of their atoms' electron shells. The atoms don't need to come into mechanical contact (and that is for the best) in order to interact with one another.

This is, as @OHara, said, an interesting analogy. What follows in the spoiler is the extremely maths-heavy version, which I add for the benefit of others who do not know the equations. Since you do, I'll do my best to give you a more intuitive approach. The most common cause of confusion with the Oberth Effect is that people look at the relationship between the spacecraft and the nearest planet. This is completely wrong. Orbital energy is certainly a factor if you happen to be near a gravitational body, but only insofar as orbital energy gives an easy conversion between potential and kinetic energy. The effect, itself, has to do with the way the kinetic energy is used, not how it is obtained, and so the really important relationship is between the rocket and its propellant, not the rocket and its orbit. Let's take your train analogy, but instead of a bullet, let's use a tennis ball. When the train is at rest, I can throw the ball some distance, x. This is a representation of the chemical energy in the propellant. When the train is in motion, I can throw the ball farther, x + y--provided I throw the ball forwards. Prograde motion is important here. If I stand next to the tracks and throw the ball at the oncoming train, then assuming no other velocity losses, the ball rebounds off the front of the train and goes a distance x + y (from the point of impact), as well. Why does it do this? The collision between the ball and the train is perfectly elastic, which is to say that the kinetic energy in it is conserved. An inelastic collision is one where the ball enters the train and is lodged there--this is why I didn't continue to use the bullet analogy. A physical representation of an inelastic collision in rocketry would be when the engine combustion chamber ruptures. That is probably undesirable. The important point to see here is that it doesn't matter whether I'm standing on the train or standing next to it; the train imparts energy to the ball at the instant the ball contacts it, or more specifically, the ball has the gained energy at the instant it breaks contact with the train (or my hand, which, when I'm standing on the train, is part of the train). I certainly did nothing to make the ball go the extra +y distance. Since my arm (or the chemical energy in the rocket propellant) can only impart a fixed amount of energy, and that energy only can carry the ball x distance, the energy to go farther must have come from the train. In exact like kind, the extra energy from the Oberth Effect must come from something other than the chemical energy in the rocket propellant. Unfortunately, our choices are very limited: we have the rocket itself, which receives the energy and therefore cannot supply it, and we have the rocket propellant again, examined outside of the context of its chemical energy. What, physically, happens when we burn propellant in a rocket engine? When we burn it, the propellant exhaust products bounce about inside the combustion chamber, either off of the walls or off of other molecules of exhaust or propellant, until they are forced out of the nozzle. By Newton's Third Law, the action of forcing the exhaust out the nozzle forces the rocket, with equal momentum, to move in the opposite direction. In a physical sense, the exhaust bounces off of the forward wall of the combustion chamber (or, more accurately, the propellant between the forward wall and the nozzle) and out. Efficiency can be increased with the engine bell, which directs exhaust moving at an angle to a more retrograde direction, again forcing the rocket to move in the opposite direction. I'm certain that this is all elementary to you and I apologise for that, but consider, since the reaction in Newton's Third Law is equal, isn't it equally correct to say that the rocket bounces off of the exhaust? Normally, one would not think of bouncing off of an exhaust plume so much as ploughing through it, because the exhaust, as a gas, is of course a fluid. But the fluid is confined and it is made of matter; even though it is not dense, it is there, and so the rocket bounces off of it. It is also true that this propellant exhaust begins by initially moving at speed with the rocket. That much should be obvious; the propellant, until it exits the nozzle, is carried by the rocket. The fact that the propellant must accelerate itself as well as the rocket is what leads to the tyranny of the rocket equation, but in this case, it is a somewhat benevolent tyranny because that acceleration results in higher energies that we can usefully extract. Particularly, because the propellant does not stick to the engine or the rest of the rocket, the collision between it and the rocket is perfectly elastic. Since the propellant, being carried by the rocket, has greater kinetic energy when it and the rocket collide while in motion than it would have if the rocket were at rest, more energy can be exchanged between them in that collision. There is another common application of this that many people miss. Have you considered why we burn the propellant in the first place? Newton's Law only really requires that the momentum exchange be equal; there's nothing keeping you from, for example, venting the propellant out the back without burning it. If you take a good slingshot and a ready supply of stones, then you can even have a rocket with real rocks in it. When the propellant is burned, the chemical bonds are broken, and this liberates a lot of energy. We see much of that energy as heat and pressure, but heat is also represented as the kinetic energy of molecular motion, and pressure is energy applied per unit area. Pressure, in particular, can be increased by increasing the temperature of a confined gas or by forcing more molecules into a confined volume; rocket propellant mixtures can be selected to do either or both of these. Combine combustion chamber pressure with a nozzle opening that has a cross-sectional area, and the kinetic energy bound up in the pressure can be liberated. Consider that the increased temperature of the molecules is physically equivalent to the molecules moving faster, and you can begin to see that, when directed out the nozzle as exhaust, the burned propellant with its faster-moving molecules imparts more kinetic energy to the rocket than would cold, un-burned propellant that is vented more slowly. Does this mean that the Oberth Effect works inside rocket engines to increase their efficiency by extracting more useful energy from faster-moving combustion products than can be had simply from venting the propellant? Technically, yes. This also means that, technically, burning the propellant is not necessary; as I mentioned above, the important part is how you use the energy, not how you obtain it. You can obtain the kinetic energy simply by increasing the propellant temperature and pressure to levels normally seen in combustion, and it will work equally well. That is exactly how nuclear thermal rockets work. It isn't even necessary to heat or pressurise the propellant: if we can increase the kinetic energy by increasing the velocity of the molecules directly, then that will also work, and that is how ion engines do it. Nothing about the Oberth Effect is any more complicated than understanding that if I bounce a ball off of a moving train, then it will go farther than bouncing a ball off of a train at rest. If I bounce a ball off of a train moving even faster, then the ball will go even farther. The same is true whether I am on the train when I throw the ball or standing next to the train and bounce the ball off of the front. The misunderstanding that people have is, in essence, the same misunderstanding that leads people to try rendezvous in orbit by thrusting towards the target, or to attempt to raise orbital altitude by thrusting radial out: things in space work a little differently from what you have been led to expect from conditions on Earth, but the physics still work.

Good work on the nose cones. They will help you a lot in the end. However, part of the issue with your fins is in your choice of fin. You appear to have two types: AV-R8 winglets on your Twin Boar boosters, and Delta-Deluxe winglets high up on the main body of the rocket. I strongly recommend getting rid of the Delta-Deluxe winglets. Don't replace them with anything; you don't need fin control that high up on the rocket, and it won't be effective anyway, because they're too close to the centre of mass to have much leverage and be effective. Also, I suggest moving the AV-R8 fins farther down the Twin Boar boosters to be closer to the engine. You may need to include fins on the main stack; put them on at the base, between the Twin Boars. Another possibility for you to try is to add the fairing base under the upper tank (the one with the most Delta-Deluxe winglets, which you'd definitely need to remove at that point) rather than the decoupler immediately underneath the payload. You'd need to ensure that you use a base that is the same size as the tank (I assume that those are 5-metre tanks), but the idea is that a long, tapered fairing is better aerodynamically than a short one that tries to be flat on the bottom. Good luck!

Others have given the reason, and I have nothing to add to that answer. I do have something to add to this. Here's the technical (that means long) explanation:

In a word, yes. To answer your specific question, you can make all of the adjustments that you mentioned. To ditch the spherical module (the Stayputnik), you'll need a decoupler, but you can set the opening altitude (and the pre-deploy atmospheric pressure) when you attach the parachute in the VAB. More generally, there are a number of parts that can store science experiment data. Any crewed command pod (including aeroplane cockpits) can do so. The 2.5-metre lab can do so. I believe that most, if not all, of the crew compartments (such as the Hitchhiker and the two-seat crew capsule) can do so. The Experiment Storage Unit can do so, though it needs to be unlocked and is not immediately available except in Sandbox mode. The experiment module, itself, can hold one copy of the experiment (meaning that, for example, you can run the experiment and recover the module without ever removing the data, and you will get the science). Also, Kerbals, themselves, can hold science data. So long as the module carrying the experiment is recovered, the science value of that experiment is also recovered. This is true even in the event of disaster. I had a bad aeroplane landing once, and most of the experiment modules were left scattered on the ground. I had not recovered any data yet, but the plane was never going to fly again, so I recovered the individual parts and got the data. I have also explored the idea of making tiny experiment return modules that involve the Experiment Storage Module and minimal control and re-entry equipment, and send them back from probe landings on the Mun and Minmus in early career. One item of caution for you is to ensure that you keep focus on the part that you want to recover until it lands. Otherwise, it will be deleted when it reaches a minimum altitude because the game assumes that it either crashed into the surface or else burned up in the atmosphere.

None of the scanning tools do it, but if your goal is to have an equatorial indicator that appears in flight view as well as map view, then I may have a solution for you. Waypoint Manager allows you to place waypoint markers according to latitude and longitude, and you may set them at whatever altitude you like. Since you know your longitude from Kerbal Engineer, it should be trivial to establish an equatorial waypoint marker at your orbital altitude and longitude. You are still responsible for adjusting your orbital inclination to align with the waypoint marker, but you get the visual indicator that you want. Furthermore, you can establish a series of four waypoints spaced at ninety degrees so as to check your inclination and alignment over the whole plane. The point I am not certain about is whether the waypoints are hard-coded to disappear after you encounter them. If so, then they provide a one-time check and provided that you can eliminate all of them, then you can know that your orbit is acceptably equatorial. If not, then they provide a continuous check and you can eliminate them after you have established your station or what-have-you to whatever level of precision you prefer.

Indeed. I'll have some very strong words for Squad if they introduce an engine called the 'Delta-V'. To reply to your original question, Slashy's method has a lot to be said for it, though I don't think anyone else has the pictures. He did do a good job of explaining what he was doing, so you ought to be able to duplicate the technique from only the written description. If you're feeling adventurous, then you can take screenshots as you go and upload a new iteration!

Here is the relevant post: And this is the concise version:

You are not; I don't know whether they've fixed this in the most recent version of KSP, but it used to be that the calculator could not give you a time until you burned the engines at least once each time you took control of the vessel. This wasn't an issue for simple missions that you flew in one sitting, but long missions that play out over several sessions suffered from this (this was one of the great draws of Kerbal Engineer when it originally came out). I'm far from being the person to ask about how KSP recognises which engines are running in terms of the underlying code, but it is possible that the game is not respecting staging or anything else because you have had them both active. Are you on console? The only universal fix that I know is not to trust the readout and use Kerbal Engineer. That is part of why I don't know whether the issue has been fixed in the most recent version: I have never looked back after making the switch.

@eminerti: Welcome to the forum! @AHHans covered the important points. I'll add that you can use action groups to toggle your engines on and off. Also, the reason that there is such a big difference in burn time is because the Nerv has such low thrust compared to the Rapiers. If the choice were between a Nerv and a Terrier (which has the same thrust), then the burn time would be nearly the same.

So says the one who wants to fly rocket ships along brachistochrone trajectories and do the rocket science that actual rocket scientists find difficult. Seriously, though, I understand. We all have our preferred cups of tea. He handwaved, for the most part. He actually did mention in a couple of places that the vessel could not exceed its own exhaust velocity (and he even included a few references to scoop drag), but he tied that velocity to that of the oncoming hydrogen--in other words, writing as though the scoop did not accelerate the hydrogen but nevertheless ignoring the fact that in order to bring hydrogen molecules together to fuse, it needed to do just that. In The Ethics of Madness (which is emphatically not Niven's best scientific work, though I found the ethical debate interesting), the story concludes with two ramscoops chasing one another on autopilot for all eternity at almost the speed of light. I think that Niven let the idea of infinite fuel get away from him and interpreted that as implying infinities (or near-infinities) in the other aspects of the ship design. I think that he tended to view ramjets as something akin to streetcars in space: the ramscoop slides along a stream of interstellar hydrogen and uses it for energy in the same way that a streetcar gets its energy from the overhead wires, but without considering the equally analogous notion that the streetcar is limited to the capacity of its motor--or, specifically, the ability of that motor to transform the energy into mechanical work--for its overall velocity. In that case, I would think that it is really just a fantastically efficient or overpowered engine, which should be trivial to implement: give a Rhino an Isp of 340,000 and you'll be able to play with a torch drive until you get eye strain from watching the glow of the exhaust plume for too long. The Rhino is the 'Size3AdvancedEngine' and the Isp is given in the atmosphere curve under the thrust transform. Since thrust is handled separately, adding three zeroes to the vacuum Isp will only increase the fuel efficiency of the engine without making it into some kind of superluminal hyperdrive. If you intend to use the stock Rhino (or already have it deployed elsewhere), then I suggest copying the file and giving it a new name. You may decide for yourself whether you want to balance the cost or other factors, but for the sake of experimenting with it, I'd suggest letting those remain as they are.

I know that Niven's ramscoops used what is essentially the most realistic equivalent of infinite fuel, because the fuel was not carried on the vessel. Unfortunately, as I understand it, the interstellar hydrogen density figures that he had turned out to be wrong. This is a common problem with hard science fiction: you write a technology that you think is fantastic and someone invents it before the book is out, or alternatively, you build a world around an idea that current physics allows, only for someone to write a paper proving how it's actually completely impossible. Arthur C. Clarke ran into something similar with his third Space Odyssey book; he wanted to wait for Galileo to visit Jupiter so he could use the updated data, but ended up writing the book anyway because the mission was delayed. I mention him because he also used a variation of the torchship concept in that book. I know that the Heinlein ships tended to use exotic (and fictional) atomic elements, and later models (the Vanguard from Orphans of the Sky and the New Frontiers from Methuselah's Children) used some kind of total conversion to get useful energy from small masses. Niven's in-system ships were not ramscoops, but they did use magnetic confinement fusion to run under constant thrust and therefore qualify as torchships. These could be better realised in-game as engines that use small amounts of an exotic propellant (or not so exotic; hydrogen is a real thing) to achieve amazing thrust. Some of the Orion mods do that to simulate the bomb packages. It's not set up for the speeds you want, but look for light sail mods. They are generally set up to include some method to allow for weeks of constant, low-value thrust to affect the trajectory calculation so that on-rails light sail craft still move as though they were not on rails. I do not know whether the calculations would work for constant, high-value thrust; there may be a ceiling. Mods that simulate orbital decay (I don't know whether RO includes any) might also provide a means to simulate constant acceleration in the form of negative decay, but that would probably be tied to proximity to a celestial body. A constant-value acceleration that is not processed with proximity would be nice, but you may well need to write that yourself. The small ISRU works this way; it requires a certain amount of cooling, but it also includes a limit on cooling that is lower than the requirement. The result is that it will automatically shut down if you don't pulse it manually. The warp drive mods may provide a different means to do this, insofar as some of them require you to generate an exotic intermediary resource to power the drive. If you limit the generation and storage of such a resource to the engine itself, then you could get a similar result without also requiring an insane number of radiators. A lot of what you seek exists, albeit in scattered bits that may be well out of date. You may spend more time collecting those pieces than you do using the result. Nevertheless, good luck.

@_alphaBeta_: Welcome to the happy family! To answer your question, I think others have touched on the major issue, so I will sum it as this: your vessel is insufficiently specialised, or else it is specialised in the wrong way. A vessel with a crew cabin for tourism is good for tourist contracts, but not so much for early Mun landings and science missions. Aside from the diameter change between the .625-metre Mk. I Command Pod top end and the 1.25-metre crew cabin that does you precisely zero favours, your design, as @AHHans mentioned, is a bit too reliant on the solid rocket boosters. SRBs are great because they are cheap for the thrust they impart, but they can also show themselves to be worth what you pay in a more negative way. While a tourist mission in Kerbin orbit does most of its work getting to the target orbit, a Mun mission does most of its work in vacuum; you'll need to tweak your design for vacuum operation. You said that you were in the early career, but without knowing what you have unlocked in terms of facilities, I am limited in how much I can help you. For example, you really ought to unlock EVA ability for the sake of both getting surface samples (and planting flags, which can be worth a lot of money) and for the sake of collecting experiment data, which means that you don't need to haul the experiment modules home (this saves weight and thus fuel). You should consider, in case you have not yet done it, unlocking the higher part counts, because it's easier to manage rocket size and weight than it is to design a Mun mission that uses 30 or fewer parts. Don't be afraid to run a few more tourist contracts to build up a cash reserve. It takes money to make money, in this case. Put a solar panel on your vessel. You only need one, and the pod's internal battery is sufficient provided that you keep the panel facing the sun when in space and you don't land in the dark on the Mun. Please don't hesitate to come back with further questions. Definitely don't hesitate to come back with tales of success. Good luck!

I was going to reply to your earlier question about doglegs but you seem to have figured out the concept on your own. To be clear, however, a dogleg is a manoeuvre that uses some of the propellant margin to adjust the longitude of ascending node. This is useful because it allows one to have an actual launch 'window' as opposed to a launch 'arrow-slit', to coin a term. In other words, it allows one to launch a few minutes to either side of the perfectly ideal alignment of the target orbital plane with the launch site and give some flexibility to the launch time thereby. One can also use it to change inclination: adjustments to longitude of ascending node and inclination are similar in their execution. Efficiency is a separate question.

You're looking for the launch azimuth equation. The Orbiter wiki is a good place to find that information, so I won't quote the page here. I think you mean launch latitude, since there is no mention of launch altitude on that page. The basic idea is that launching from any latitude other than zero imposes a minimum inclination in your orbit equal to the latitude. This is because all orbital planes must pass through the centre of mass of the primary (Kerbin in this case), so if we assume that the centre of mass is also the centre of the planet (which is usually the case), then the orbital plane, in order to pass through the centre of mass, must be tilted at an angle equal to or greater than the amount that the launch site is 'tilted' with respect to the equator and the centre of the planet. It is necessary to account for this for two reasons: first, high-latitude launch sites can only launch vessels to high-inclination orbits (for example, launching from the north pole needs must result in a 90-degree polar orbit), and second, the rotational velocity of the surface varies with your distance to the axis of rotation. In other words, your eastward velocity on account of the planet's rotation decreases as you approach the poles. This should be fairly obvious once you think about it: a point ten metres from the pole takes one day to trace a circle around it. A point on top of an equatorial mountain (specifically, as far from the axis of rotation as possible) must trace a circle thousands of times larger, but still must do so in one day. When calculating your launch azimuth, you need to account for the amount of inclination that you get as a consequence of your launch site's latitude and for the amount of velocity you receive from planetary rotation at that latitude. When you restrict yourself to equatorial launches, these considerations simplify immensely.

Yes, that is it precisely. There is a concept in celestial mechanics called the synodic period which relates to the frequency of conjunctions or oppositions between two planets. Specifically, it describes the time it takes for a second planet to return to a particular orientation about the primary with respect to the perspective of the first. This is relevant to orbital mechanics because the same period describes the frequency (though not the location) of transfer windows. Since interplanetary transfer is advanced rendezvous, it also relates to the similarity of orbits for purposes of rendezvous--and KSP does not provide the most convenient tools for interplanetary transfer. Details are in the spoiler. You are most welcome. We're all here to help.

Welcome to the game, @wobartoz! I can certainly help you with reproducing the calculations, so that is what I will do. This is the original post: Let's take this in steps. Also note that I will use American notation conventions (commas for thousands separators and periods for decimals). First, we have a lander in a 40 km circular orbit of the Mun and another vessel ahead of it in the same orbit, with a separation angle of 77°. 1. Calculate the orbital period. The equation for this is T = 2π √(a3 / μ), where: T = orbital period, a = the semi-major axis of the orbit, and μ = the gravitational parameter of the body that you are orbiting KSP displays your orbital altitude as an altitude above datum, which is the zero point or 'sea level' of surface elevation. The problem is that semi-major axis for an orbit is calculated with respect to the centre of mass, not the surface. You need to add the radius of the Mun, which is 200,000 metres. You can find that in the wiki, but it is also displayed in the information pane for the Mun that you can find in the Tracking Station. The formula for semi-major axis in KSP is (Apoapsis + Periapsis + celestial body diameter) / 2, so for a 40 km circular orbit of the Mun, that is (40,000 + 40,000 + 400,000) / 2 = 480,000 / 2 = 240,000 metres. The gravitational parameter is also unique to a given celestial body, and is equivalent to the universal gravitational constant times the mass of the celestial body. This is also something that you can find either in the wiki or in the Tracking Station, and for the Mun is 6.5138398×1010 m3 / s2. Putting that together: T = 2π √(a3 / μ) T = 2π √([240,000]3 / [6.5138398×1010]) T = 2π √([1.3824×1016] / [6.5138398×1010]) T = 2π √(212,225.05) T = 2π * 460.6789 T = 2,894.5 seconds 2. Calculate the separation in terms of the orbital period. Since we're working in degrees, I will continue to do so, but know that many orbital calculations require radians. 2,894.5 seconds per 360° orbit gives 8.04 seconds per degree--we can round this down to 8 seconds exactly for our purposes. 77° at 8 seconds per degree means that, assuming that you are ahead in the orbit, you are 616 seconds ahead of the target in your orbit. To allow your target to catch up to you in minimum time, you will want to increase your orbital period by that much. Then, when you return to the same point, the target will have advanced by that exact amount and you will complete the rendezvous by matching velocities (which is the same thing as returning to your previous circular orbit). However, it is not necessary to do it that way. You can choose, for example, to increase your orbital period by 308 seconds and allow the target to catch up over two orbits. That will save fuel, but at the cost of time. Sometimes, it may be necessary to do it that way, such as when your phasing orbit will cause you to strike a celestial body, eject you from the sphere of influence, cost too much of a limited fuel budget, or otherwise cause issues. Anyway, in this case, since we want to slow down and allow the trailing object to catch up, we need to increase the orbital period by 616 seconds. This is as simple as 2,894.5 + 616 = 3,510.5 seconds. 3. Calculate an orbit that has the required orbital period. In this case, we want to use the same equation for orbital period, but we need to work through it the other way: we have the period and we want the semi-major axis. With algebra, we can derive a new equation to be: a = 3√(μT2 / 4π2) The variables are all the same as before, but please note that the outermost operation is cube root, not square root. a = 3√([6.5138398×1010] * [3,510.5]2 / 4π2) a = 3√([6.5138398×1010] * [12,323,610.25] / [39.4784176]) a = 3√([8.02740229×1017] / [39.4784176]) a = 3√([2.03336476×1016]) a = 272,942.9 metres Remember that semi-major axis is equivalent to (Apoapsis + Periapsis + celestial body diameter) / 2. In this case, we want to keep the periapsis for ease of rendezvous later, and we are naturally going to remain in orbit of the Mun, so the only variable to change is the apoapsis. This problem simplifies to (2 * a) - Periapsis - celestial body diameter = Apoapsis, or (2 * 272942.9) - 40,000 - 400,000 = 545885.8 - 40,000 - 400,000 = 105,885.8 metres (or 105.8858 km) for your new apoapsis altitude. 4 - 8. Complete these steps as given in the quoted post. One item of extreme interest here is that, although the calculation is valid, it depends on foreknowledge of the phase angle or angle of separation between your vessel and its rendezvous target. In the example, this was given as 77°, but KSP does not give you this information. You will need to either install a mod that will give the information (Kerbal Engineer will do this), estimate it by eye, or else use a protractor on the computer screen. You can calculate it based on the separation changes resulting from tiny orbital manoeuvres, as well, but that is often more trouble than it is worth. The typical approach for this is instead to raise your apoapsis by some arbitrary amount, wait for enough orbits to get a 'close' encounter, lower the apoapsis to get a near-perfect encounter according to the close approach markers in the map view, and rendezvous. The idea is that you get some fuel savings by choosing a lower phasing orbit to offset the cost of the minor adjustments. The net effect is equivalent to estimating the required phasing orbit and then refining that estimate by iteration until you get a rendezvous.

It doesn't, as you discovered. I believe that the reason for it has to do with the on-rails versus off-rails way that KSP calculates orbital information. When the craft is active, the orbital parameters are dynamic, but once you switch focus to something else, those parameters are treated as constant initial values in the orbital equation. Knowing that the craft's mean anomaly was a given value at the specific time you last controlled it is exactly as useful for calculation purposes as knowing what the mean anomaly was at some arbitrary zero time. That being said, I don't know that for certain, so I may be far and away off the mark. It doesn't tell any more about what OBT is, either.

Six parameters define the orbit in three-dimensional space. You need a seventh to define which celestial object you're orbiting, but that's handled here, obviously. Technically, you need an eighth to define the time element: mean anomaly defines one's place on the orbit as a radial angle from the periapsis, and mean anomaly from epoch (also sometimes called time of periapsis passage) defines position with respect to some time, but without a reference time to respect, it doesn't mean much. That time parameter is usually called epoch; I have no idea what 'OBT' describes. Granted, these extra two are not, strictly speaking, orbital parameters. They are properly considered part of the reference frame; an orbit can be just as well defined without knowing what you're orbiting or when (incidentally, orbits don't care about the surface elevation of the primary, either), but the practical value of knowing these things should, I hope, be readily apparent.

Welcome to the forum! It's nice to see new people here. You're not doing anything wrong, though I will say that you misread HvP's post. Note that @HvP did not say that there could be too many control surfaces. HvP said that there could be too many control inputs. That is not the same thing. Too many control surfaces is something that can happen, but it usually results in an unstable plane with too much control authority--in other words, tapping the ailerons to level the plane instead results in flying upside down, and trying to go back the other way results in flying sideways, because you have so much control that you cannot make fine adjustments. Too many control inputs means that each control surface tries to operate in all three axes--pitch, yaw, and roll. Normally, planes devote a control surface to controlling one axis at a time: elevators control pitch, rudders control yaw, and ailerons control roll. Occasionally, one surface will be used to manage two axes as in the case of elevons that manage pitch and roll (in fairness, though, I've never seen elevudders or rudderons). KSP doesn't know that a given control surface is supposed to be an elevator and another is supposed to be a rudder--even though some parts are called elevons in the VAB, nothing prevents you from using them as rudders (or as landing legs, if they've the crash tolerance for it). The game provides a way for you to instruct the parts to operate only for pitch control, but you need to select it when you place the part. If, for example, you leave your rudder set to roll rather than allow it only to control yaw, then an attempt to roll will also turn the rudder, even though its total contribution to roll is, at best, two or three percent of its contribution to yaw. The result is that the plane rolls (provided that you have ailerons as well), but rather than rolling while maintaining forward motion, it also yaws and invariably pitches down. With a full complement of control surfaces, they all end up fighting one another. The other part of that problem is what @AHHans mentioned. When your wings are too close to the centre of mass, the control surfaces on the wings are also too close to the centre of mass. This creates two problems. One is that the surfaces lose control: if you imagine that the control surfaces apply a force like a wrench turning the plane about its centre, then having the control surfaces father from that centre provides a longer wrench, more leverage, and thus more control. Having the surfaces too close to the centre shortens the wrench to the point that it has no control. Worse, if the centre of mass moves about because of a shifting fuel load, then the control surfaces that were slightly to the rear of the plane may find themselves slightly to the front once the centre of mass moves past them. Since KSP moves those surfaces according to their relationship to and direction from the centre of mass, it means that elevators that work correctly on the runway may suddenly switch and work backwards at some point in flight. I'd also like to see a picture of the plane in question. It doesn't make sense for time warp to change control surface function, but I've seen stranger things.

That is an excellent point. To the bug tracker, then. Edited to add: Issue 24504

Given that use of the cheats menu is now a standard part of the advice toolkit, is it perhaps to the point that we need to revisit the requirement that a satellite be new in the first place? I know that contextual contracts give contracts to move already-launched satellites, but those contracts are for specific already-launched satellites: the contracts pick a satellite and say, 'move this one'. The fact that they invariably pick satellites that I've placed with tender care into their orbits and have no intent to move for any price is merely twisting the blade for me--but that's a separate issue. Instead, what I mean is to ask whether it is possible to have a contract that will accept any satellite that meets the other requirements, regardless of its launch time. In other words, let's say that a contract requires that a satellite with an antenna and 600 units of monopropellant be placed in X orbit, and I happen to have one from an earlier contract that required 1,000 units, so it qualifies. One Hohmann transfer later, I've completed the contract. Does anyone know whether such a thing is possible without overhauling the game? @bewing, perhaps? If it is, then I'll write it up as a feature request for the bug tracker. If not, then I think I'll do that anyway.