Zhetaan

The impact tolerance won't be an issue unless you try to land on it or decide to play bumper ships in orbit. Generally, you want to land with less than 6.0 m/s anyway. The ejection force isn't a problem; it's not a terribly useful form of propulsion, so the force that you need is only that which pushes the separated stages apart in a reasonable amount of time. One thing to note about the new versus the old decouplers is that the new ones have names with systematic relationships to their size. The TD-12 is the 1.25 metre decoupler. The TD-06 is the 0.625 metre decoupler. Similarly, the TD-25 and TD-37 are the 2.50 metre and 3.75 metre decouplers. The old decouplers usually had random numbers or no numbers at all (the 2.5 metre decoupler used to be called the Rockomax Brand Decoupler, which told you nothing about its size unless you knew ahead of time that Rockomax parts tended to be 2.5 metres). This is still the case with the radial decouplers: the 38 in TT-38K means nothing that I can determine, and Hydraulic Detachment Manifold is practically technobabble.

It may be that MechJeb is expecting the Thuds to be behind the centre of mass. You might try testing with an otherwise-identical vessel with Thuds at the back and seeing whether MechJeb has a problem with it. If you know how to use the cheat menu, then you can put the test rocket in orbit without needing to figure out the aerodynamics and just see whether it works.

It's interesting that you should mention that, because there's a deeper history there. Specific X is simply a measurement of some quantity divided by the mass to give the amount of that quantity per unit mass. It's particularly useful when comparing things such as different-mass objects in orbit (or the same object that changes mass, such as a rocket). Impulse is a quantity of force multiplied by its duration (time), and it takes units equivalent to momentum (newton-seconds in SI, which simplifies to units of mass times displacement divided by time). Specific impulse, therefore, technically takes units equivalent to velocity (displacement divided by time). How, then, do we get 'specific impulse' measured in seconds? The newton (the current SI unit of force) was not standardised until 1946--it wasn't even officially named until 1948. What, then, did a German rocket scientist in the early to mid-1940s use as a unit of force? Kilograms. Oh, yes. Kilogram-force is a unit equivalent to one kilogram in a one-gee acceleration, so in other words, it equates to 9.80665 newtons. This technically means that washroom scales ought to be calibrated in newtons and not kilograms (maybe dekanewtons for the sake of close-to-familiar numbers), because unless that scale is a mass balance, it is measuring weight--i.e., force--and not mass, and will, for example, show a reduced value if used on the moon where the force is less because the gravity is less. Under the German system then in place, mass was a derived unit, not a base unit, so kilograms-force were more fundamental than the kilograms we know today. It is true that this unit had a proper name, kilopond, though the word kilogram was often used interchangeably with it. In any case, the point is that aside from the ambiguities that arise when people use the same name interchangeably for units of mass and units of force, when you take units of force multiplied by time and divide, not by units of mass, but by units of force, it leaves only time. It is true that the U.S. customary system has the same problem with pounds-force and pounds-mass, and the correct unit of mass, the slug, has not seen widespread use. However, those expatriated German rocket scientists would have seen that as a feature of the U.S. system because it made things easier and more familiar. Yes, measuring specific impulse in seconds made for easy unit conversion (by obviating the need for it), but that was an emergent property of the systems in use at the time, not a deliberate effort to ease conversion between metric and U.S. units. Keep in mind that we're discussing actual rocket scientists; being good with numbers and with unit conversion is pretty much a requirement. Although sometimes, they do get it wrong. I'm looking at you, Mars Climate Orbiter. P.S.: Picking obscure or non-standard units doesn't really demonstrate difficulty so much as it does unfamiliarity. There's a valid point in there, but I don't think it's the one that you were trying to make. On the one hand, it doesn't take a lot of effort to find out that 2,000 metres per second is 1.203 x 107 furlongs per fortnight. On the other, I can do the same thing with metric and say that it's 41.30 megacalories per newton-day.

It doesn't have a name: it's just an EC unit. The reason for it is because the other things that are measured on a rocket, such as Fuel or Ore or even IntakeAir, have mass and volume, so (although this was not always the case) the developers decided to standardise the massive things to metric or metric-derived masses, volumes, and densities. EC doesn't have any of these properties, and more to the point, the way it is used in the game is definitely a departure from real-world physics, so even if it were to be standardised, it wouldn't be realistic. For example, batteries in KSP function a lot more like capacitors. A number of rocket engines have 'alternators', which would be a very short-lived experiment if one tried it in real life. Aside from that, something that takes energy from the exhaust, such as a turbocharger, would be seriously detrimental to the rocket's function: taking energy out of the exhaust is the very last thing that one would want to do, because chemical rocket engines are inefficient enough as it is. I didn't; I said that it was the least metric. It's still very metric, but a lot of the units used in astronomy stand apart from the metric system. Part of that is due to the use of the arbitrary--but situationally appropriate--units of measure you described. The simple fact is that astronomical measurement is so far off the scale that SI doesn't have the range to properly accommodate it. In addition to the AU and parsec (and this is hardly an exhaustive list), there is the gee, which is technically a unit of acceleration, and also a selection of masses and distances that derive from astronomical objects and not SI base units. Black holes, for example, are described in terms of solar masses--which, on the one hand, I understand, but on the other, I'd really, really like to hear someone use the word yottagram in a sentence. In fairness, though, one solar mass is beyond the limits of even the newly-proposed SI prefix definitions at 1,989 queccagrams, and compounding the prefix, i.e., 'kilo-queccagram', is not allowed. I could go with 1.989 ronnatonnes, but I consider that to blur the line between systematic measurement and just making stuff up to sound cool. There's a reason that astronomers tend to use scientific notation for everything: 1.989 x 1030 kg is sterile, but it won't make anyone burst into fits of giggles. At the other end of the scale, I once saw a paper describe the gas pressure in a nebula in terms of particles and kelvin per cubic light year. It's a perfectly valid unit (it's even pseudo-SI if you consider that, since the speed of light defines the metre, a light year is a valid derived unit), albeit it is an odd construction. It makes sense because the density and temperature of a nebula are relatively easy to measure at a distance, and it's all related through the Ideal Gas Law, so it should be apparent that astronomers know how to use SI ... it's just that often, they can't. Another part of it is that many, many of the quantities used in astronomy are technically outside of the metric system's purview because they lack dimension. Of the six Keplerian elements, only semi-major axis is an SI unit. Eccentricity is a dimensionless ratio; longitude of ascending node, argument of periapsis, inclination, and true anomaly at epoch are all angles (and therefore also dimensionless ratios, albeit with extra conversion factors). I'll grant that orbital state vectors are typically metric, but they are not used in KSP. Angles do deserve a special mention: obviously, the radian can be derived by dividing the length of arc in metres by the radius, also in metres, and I'm certain you're aware that's how it's defined for use in SI. I'd be willing to accept that for the same reason that I'm willing to accept the temporal second's adoption by SI (the unit saw utility in a number of prior systems before SI gave it a specific definition), but the problem is that astronomers tend to measure angles in degrees (and its subdivisions: a parsec is one arcsecond of parallax, after all). Degrees and angular seconds are accepted for use with SI, but they're not SI. They aren't even coherent units; they require conversion factors. Not to leave rocketry out of it, either, but in rocketry, we get a lot of ratios: thrust-to-weight for determining a rocket's lifting ability against the local gravity, mass ratio for calculating its available delta-V, and payload fraction for determining its capacity (and therefore efficiency). There is lift-to-drag ratio, too, although that is arguably more appropriate to aeroplanes (and spaceplanes) than to rockets in KSP. None of this, of course, is to argue either for or against the use of the metric system. I'm not arguing at all: I am merely pointing out that any system designed for broad applicability is going to run into edge case trouble when confronted with highly technical, highly complex fields such as rocketry and astronomy, and especially so when it operates at the extremes of scale. As such, you'll find that there are a lot of situations that require either non-standard units or a lot of powers of ten. However, just as with measuring gas pressure in a nebula, the metric system is often perfectly valid for deriving those units or counting those powers of ten. Oh, certainly not. I'm perfectly happy knowing that when I need to convert astronomical units, I can rely on my beloved 327.2 gigacubits. ... I hope that made you laugh, rather than cringe. Seriously, welcome to the forum. I hope you have fun here.

Well, I wouldn't say exclusively. Electric charge still ... well, I don't know what it is. It's not in coulombs, that's for certain. It's not convertible to joules, ampere-seconds, watts, or any other unit I can tell, either. Other than that, though, yes, it's pretty exclusively metric--which is pretty funny if you think about it, because astronomy in general is about the least metric of the physical sciences. In any case, welcome to the happy little family.

We're blasting from the past, I see! The thing to know about using the SENTINEL is that you do not line it up with a planet in the sense of being able to draw a line from the sun, through the telescope, to the planet that you're observing. The way to use it is to put it in a lower orbit than the target planet, but not so low as to cross the next planet sunwards. For example, if you want to observe Kerbin, then you need to eject from Kerbin's sphere of influence to a solar orbit that is between Kerbin and Eve. There are special SENTINEL missions that mandate specific orbital requirements, but if you're doing it for fun but not profit, then most orbits that lie completely between Kerbin and Eve will work to watch Kerbin.

It should, but keep in mind that the rate of science production is a fairly complicated mathematical process; it operates on a logarithmic decay model and so reducing this multiplier by a factor of five may only reduce the initial rate by that much. It may be a linear multiplier applied to the output of the logarithmic decay, or it may work out that later research when the initial store of data points is depleted may be slowed by significantly more--possibly by enough to create an effective standstill even with a large amount of data still in the lab. To get the effect you want, I'd suggest changing the scienceMultiplier value to 1, instead, to reduce the total science conversion. Change it to 0. If the game throws an error for that, then change it to .001 as you see in the atmospheric thrust curves for engines' cutoff pressure. I have not tried it, but I assume so. Without knowing the equation that governs the time calculation, I can't tell you what changing it would do aside from what it says on the tin. I'd personally suggest reducing the science conversion and eliminating the scientist bonus before changing the processing rate. Changing too many factors at once may nerf the lab to the point of uselessness, in which case I'd say to just comment out ModuleScienceConverter and play without that function.

On the one hand, there are a few missions that require more experience. On the other hand, doing them is how you acquire experience. On the gripping hand, frustrating yourself unnecessarily makes things less fun. Along with @18Watt, I agree that Moho is probably a bad choice if you are, as your post title suggests, a 'low-skill player'. Putting aside the issues of simply getting to Moho in the first place, landed equipment on Moho generally needs alternative power arrangements and such because of the length of night. Vall and Laythe are both good choices and have different requirements. Laythe's main attraction is the fact that it has an oxygen atmosphere, but if you're not interested (or simply not yet ready) to try flying interplanetary aeroplanes, then remember that Laythe is still interesting for those who insist on visiting it with normal rockets. Vall is more challenging than the Mun and also has some interesting features. Don't forget that you can challenge yourself in a different way by taking a multiple-lander to try both of them--you don't need to go from nothing to a full Jool-5. In fact, Jool-2 and Jool-3 missions (either Vall/Laythe/Pol for the ease of getting there, or Vall/Bop/Pol for the similarity of environment) are great ways to train for more complicated missions such as grand tours. There are other things to do, too, that may interest you. Asteroid capture and mining is a completely different game, and Dres is worth a look, as well. Dres suffers from the fact that it is far away from everything and lacks a collection of moons like Jool's, but it's still worth the trip. Have fun!

While many kerbals may yearn to see the stars from beyond their sky, the singular terrors involved in actually doing so are such that wishing to repeat this unlikely stunt is reserved for only the truly certifiable, such as Jebediah. Put another way, consider that these are the same companies that supply the explosion-worthy parts who are also asking you to loft the tourists. Perhaps these contracts are a disciplinary measure for corporate employees who are somewhat less than VI in their VIP. I know that I work with some people who could use a twelve-year holiday to Jupiter--then I might actually get something done around here.

If you are writing of what I think you are, then it's not a bug. The scanner module shows extremely low-resolution data, but that data is also shown on a per-biome basis, whereas the Tracking Station shows that data on a per-celestial-body basis. Differences are to be expected, and the values that you get still won't be very accurate: in essence, the orbital scanner is really only good for a qualitative test that tells whether the resource is present or absent, not a quantitative test to tell you reliably how much is there. You'll need to get on the ground and use a surface scanning module to 'ground-truth' the survey and, essentially, calibrate the scan against what you can actually find in the biome in order to get useful numbers. Also, a disclaimer: I'm not absolutely positive that this is how it works (I have used SCANSat since before stock mining was a thing) and the wiki, while providing a decent-enough set of instructions on how to use the scanning parts, does not provide much to use in terms of interpreting the data. I think that this is because in order to get accurate data, you need to get to the surface and run a surface scan, but since we're talking about mining resources, you'd need to go to the surface to make practical use of the data anyway, so the interval between having no scans to having accurate scans (where you are now, with an orbital survey but no surface scan) is supposed to be short. The orbital survey is meant to be a necessary aid in deciding where to look for resources, but it does not--and cannot--substitute for landing and sifting through some dirt to be certain.

These sorts of problems are difficult to diagnose without a picture of both the craft and of exactly what you're trying to do. However, the usual suspects in these sorts of cases, as @steuben and @FruitGoose have already mentioned, are autostrut and part clipping issues. Does everything explode at once, or does it tear itself apart over a few seconds? The autostrut problems normally occur when you have an autostrut set to the heaviest part, and the identity of that part changes mid-flight, or when you have them set to the root part and you change that part (usually when you undock something). Limit your use of autostruts to what is needed and no more, and set them to the grandparent part whenever possible. The part clipping issues are essentially what it says on the tin: you attach a part that intersects with another part in a way that they don't like. Given that EVA part attachment is a fairly new stock feature, it's also possible that you're encountering a new sort of bug and the reference to 'the usual suspects' needs a bit of recalibration.

Sorry about that. Even with all of the simplifying assumptions that KSP makes with respect to physics, there's still a lot going on. KSP attracts a lot of intelligent people who want to understand some of the technical depths (including you: you did ask the question, after all) so perhaps it was inevitable. For the purposes of directly (and briefly!) answering your question, lower is better, except in certain very specific circumstances.

I never bought into the idea that everything KSP needs to have an added K. I was honestly disappointed when the contracts appeared requesting Kolniya orbits, since Molniya orbits are a real thing and for the sake of clarity, I think that it's a bad idea to confuse legitimate terminology--especially when people who don't know about Molniya orbits wouldn't be in on the joke. Imagine if KSP insisted on calling the point of closest approach on an orbit the keriapsis--or that flyby trajectories were kyperbolic. That being said, I'm not immediately averse to the idea of Kerbin's star having a formal, official name, though my preference would be for one that does not include part of Kerbin's name (again for the sake of clarity). I sometimes refer to it privately as Felipe's Star, since out of all the possibilities, that name is both realistic (e.g., Barnard's Star, van Maanen's Star, and Luyten's Star) and true. But calling the local star the star is not confusing provided that the context is clear, just as you declaring that you'll be going back to the house does not mean the same house as I imagine when I think of the house, except in very specific circumstances that, again, would be clear in context. Similarly, I understand that there's a bit of a hangup with the notion of the solar system, given that it has the formal name of Sol in it. The general term for any system is star system, and I don't have an issue with that--especially since Kerbin system can be taken to mean the Kerbin-Mun-Minmus set of objects. Kerbin's star system is better but not ideal. Usually, I'll just call it the system and leave it at that unless there's a compelling reason to be more specific. As for the star itself, I call it the sun, but it's not as though I feel any kind of cultish religious fervour for it. I don't stare at it and chant, 'THESUNTHESUNTHESUNTHESUNTHESUNTHESUNTHESU....'

Not to compound the pedantry (sorry; I couldn't resist), but my example was to illustrate that the benefit of periapsis kicks over a single burn does not come from the Oberth effect. Yes, as the apoapsis rises higher, the speed at each periapsis encounter for subsequent kicks increases, and therefore the Oberth effect also increases; however, these increases occur whether you do it in one burn or in ten. The principal benefit of doing periapsis kicks is that it allows one to concentrate the manoeuvre in space (at the cost of time) at the periapsis, thereby coming closer to a practical realisation of an instantaneous burn than would be otherwise possible. In that respect, since the proximity to the periapsis means that the velocity at the time of the burn is closer to the maximum possible, it is also true that there are tiny increases to the Oberth effect from kicking over not kicking. However, I contend that these increases are irrelevant because failing to kick results in far greater cosine losses, and the point of kicking is to avoid those losses. Furthermore (for the sake of completeness), a more powerful engine that does not need to kick also concentrates the manoeuvre at the periapsis, which also means that the velocity is closer to the maximum possible, which gives the same increase to the Oberth effect--in other words, the principal benefit of kicking is still in that it allows a weaker engine to pretend that it is a stronger one by burning multiple times in (nearly) the same place and with reduced cosine losses, not that kicking in itself somehow grants more benefit from the Oberth effect than one may otherwise realise. Put in a different light, consider the vis-viva equation. The orbital speed at a specific radial distance on an orbit, given that the primary is constant (for simplicity's sake, let's assume that we're just working in Kerbin orbit) is dependent only on the semi-major axis and that radial distance. Unless you are at an apsis or on a circular orbit, any valid radial distance corresponds to only two points on a given orbit. Let's further assume that the radial distance we're interested in is that of the periapsis, since we're talking about periapsis kicks. That reduces the number of corresponding points to one. Since the vis-viva equation is in three variables, and one of them (the radial distance at periapsis) is held constant for the purpose of periapsis kicking, the other two variables can only vary with one another. What this means is that for a given orbital speed at a given periapsis, there is only one possible semi-major axis, but it also means that for a given semi-major axis, there is only one corresponding orbital speed at that periapsis. As you kick at the periapsis and increase speed, the semi-major axis increases with that speed (and so does the Oberth effect), but that will happen anyway whether it is done in one burn or a pulsed series of kicks. The reason that this is important is because it means that the interval between kicks is irrelevant. By necessity and the requirement of burning at the periapsis, the interval is limited to a discrete integer number of orbits, whatever the orbital period may be, but that interval can be zero and it still works because a single (instantaneous) burn can be considered as the limiting case of an infinite number of periapsis kicks with an infinitesimal interval between them. The Oberth effect operates on that orbital speed regardless of whether the speed is reached in one burn, which is to say that the Oberth Effect does not increase because of periapsis kicking. It increases because the periapsis speed increases, however one may choose to accomplish that and no matter how long it takes to do so. Furthermore, I contend that cosine losses are a problem precisely because gravity is redirecting your velocity. Prograde burns at the apsides are efficient because the prograde direction at those points is exactly perpendicular to the force of gravity. Outside of those points, either the prograde direction is not perpendicular, in which case some of the burn is lost fighting gravity, or else the perpendicular to gravity is not prograde, in which case some of the burn is lost fighting the orbit. This is mathematically inescapable because the perpendicular to a tangent of an ellipse (this tangent corresponds to prograde) does not go through the focus except when it is the major axis (which is the line of apsides for an orbit). Lastly, the reason that burning prograde at opposite sides of an orbit does not cancel out is not because of the direction, but because velocities in orbit are not strictly additive. There are certainly exceptions at various times and places, to be sure, but it is the energies that add, not the velocities. A prograde burn at periapsis and an equal prograde burn at apoapsis are burns in opposite directions, but they both correspond to an energy increase in despite of their cancelling directions. Total specific orbital energy is time-invariant (meaning that it is constant for a given orbit), but that total is the sum of a perpetually-shifting exchange between specific potential and specific kinetic energy. Specific potential energy at a given point relates only to your radial distance from the primary, specific kinetic energy relates only to your speed, and total specific orbital energy relates only to the semi-major axis of the orbit. Burning prograde at the periapsis raises the apoapsis because it increases the specific kinetic energy, and since the specific potential energy does not change (since you are still at the periapsis), it must also increase the specific orbital energy, which is reflected by an increased semi-major axis. Burning prograde at the apoapsis also increases the specific kinetic energy, and since the specific potential energy does not change (since you are still at the apoapsis), it also increases the specific orbital energy by increasing the semi-major axis.

@camacju: While avoiding an atmospheric dive is certainly helpful, the main benefit of periapsis kicking is that it reduces cosine losses: for this reason, periapsis kicks make sense for low-thrust craft even when they are not at risk of falling into an atmosphere, and they also make sense for high-thrust craft that need to make very long burns (for whatever reason that they may need to do so--escaping the star, perhaps). This comes of the fact that velocity is both a magnitude and a direction, and when thrust is low, the burn takes so long that the direction can change substantially over the duration of the burn. Also, the benefit of the Oberth effect does not increase with periapsis kicks. The Oberth effect only operates on one's speed; whether you acquire this speed in one burn or in several is of no consequence. For example, let's say that you need to increase your velocity from 2,300 m/s to 2,600 m/s for some manoeuvre. You'll get the same benefit from the Oberth effect when going from 2,599 to 2,600 m/s no matter how many burns it took to get there. I will concede that with enough precision, one can have an arbitrary number of infinitesimal burns at the exact periapsis, and that would maximise the orbital speed at which one makes the burn. However, that is no different from an instantaneous burn, which is how we generally calculate these things anyway. I would like to respectfully qualify that. The energy will be the same, but energy is a scalar, not a vector--one can gain energy from a purely ballistic repeat flyby provided that the direction changes on leaving the sphere of influence, which is, of course, how gravity assists work in the first place. The purely ballistic K-E-K-K-J transfer from Kerbin (eventually) to Jool is fairly well-established, and it includes a Kerbin repeat-flyby. I will add the caveat that you are correct in that you cannot start from Kerbin and use it again for the next flyby, but that is because in that case, Kerbin would be at one of the apsides of the orbit. Maybe if you did a bad transfer with a lot of radial, you could use Kerbin to fix the trajectory, so perhaps even the caveat has caveats.

It's a little more complex than a simple higher/lower choice. Yes, as others have said, the Oberth effect is important and yields great returns for expended propellant, but there is more going on than a straightforward relationship of 'go lower = go faster = go better'. One thing to keep in mind is that there are different requirements for different destinations. In order to make an interplanetary transfer, you need a specific hyperbolic excess velocity that is different for each planetary destination (and different for each transfer window, too, owing to inclination and eccentricity variations). This excess velocity is called that because it is the velocity that your escaping craft still has at the point of escape from its original sphere of influence (i.e., Kerbin's), and thus is 'extra' velocity not needed to escape. However, because you need to add that velocity in with the initial ejection burn (in essence, 'storing' it for later), it interacts mathematically with the other energy of the burn and thus affects the outcome. Also, in order to effect a transfer from any closed orbit, you need to reach escape velocity first--otherwise, you can't leave! Therefore, any manoeuvre to escape a closed orbit about a planet or other gravity source has to account for both the escape velocity (to begin the transfer and break free from the parent body) and also the hyperbolic excess velocity (to finish the transfer and carry the vessel the rest of the way after leaving the parent). The equation that combines these yields a value called the burnout velocity, which is the velocity your vessel needs at engine shutdown. Burnout velocity, in turn, is the sum of your orbital speed and your manoeuvre delta-V. Rearranging it a bit, your manoeuvre delta-V is thus the required burnout velocity minus whatever assistance your orbital speed can give you. This implies that either decreasing the required burnout velocity or increasing orbital speed saves delta-V. This is true, but the Oberth effect only affects the second part. Orbital speed increases as altitude decreases, but so does escape velocity. To illustrate the concept better, consider this: at infinite distance, your orbital speed is zero, because you're not in orbit. At infinite distance, your escape velocity is also zero, because you've escaped. However, when in a closed orbit, your orbital speed must be less than escape velocity, because it's a closed orbit. Therefore, as your orbital altitude increases to infinity, both your orbital speed and escape velocity go to zero, but escape velocity goes to zero slightly faster because it starts from a higher value. Your needed ejection delta-V is a combination of three values. First, there is the hyperbolic excess velocity, which is a constant for a given transfer. Second, there is the escape velocity, which is inversely proportional to altitude. Third, there is the orbital speed, which is also inversely proportional to altitude. At low altitudes, orbital speed is high and so is escape velocity. Specifically, the escape velocity dominates the burnout velocity term. As the altitude rises, the escape velocity decreases faster than the orbital speed does, so the orbital speed gains a slight edge and that reduces the manoeuvre delta-V costs. However, soon after that, the escape velocity reduces to a point that it no longer dominates the burnout velocity term--eventually, the constant hyperbolic excess velocity portion takes over. Since hyperbolic excess velocity is not dependent on altitude, increasing altitude after this point only reduces the orbital speed and thereby increases the manoeuvre cost, which is the Oberth effect in action (albeit in reverse). The concept is called the gate orbit, and is built entirely on the notion of striking a balance between the Oberth effect and the ejection requirements at different altitudes. As an example, I took the first Kerbin-Duna transfer window and a fairly typical hyperbolic excess velocity of 920 m/s. With that value in mind, the optimal transfer altitude to conduct the ejection burn is 7,745 km (as seen in the altimeter; the distance-from-centre is 8,345 km), and a transfer from this altitude costs 650.5 m/s. The best transfer I could find in that window has a hyperbolic excess velocity of 855 m/s, and its optimal altitude is 9,062 km with a manoeuvre cost of 604.6 m/s. By contrast, transferring from a 100 km low Kerbin orbit on that same transfer costs 1,060.9 m/s. The problem, of course, is that it costs 1,200 m/s to get to 9,062 km from 100 km. That trade-off actually trades away all of the savings from choosing the optimum altitude and costs extra besides, but the information is still useful. For example, if you are assembling a large interplanetary vessel in orbit, there's something to be said for assembling it in the gate orbit. The cost of putting the vessel there is borne by the assembly craft and propellant tankers, not the vessel itself. Also note that the gate orbit for Duna is reasonably close to the Mun, which is a reason for having a fuel infrastructure there--and if you want to transfer from the Mun directly to Duna, then you can multiply the effect (that is to say, choose the gate orbit for a Mun hyperbolic excess velocity equal to an ejection burn to Duna from Kerbin at the Mun's altitude) and see even greater savings. Duna and Eve gate orbits are fairly high because they don't have large hyperbolic excess velocity requirements for the transfer. A gate orbit to Jool, on the other hand, is at about 270 km (but that makes it a good place to put a Kerbin-Jool propellant depot or embarkation station if you want one). This is because, as the hyperbolic excess velocity increases, you need to get more from the Oberth effect to supply that velocity. Alternatively, to use my illustration from above, a higher hyperbolic excess velocity comes to dominate the burnout velocity term that much sooner as altitude increases. The other reason that gate orbits are useful is because they assist with interplanetary operations at the destination. Suppose that you want to send a vessel to some distant place, but you also want to return it to Kerbin. Sending it to the gate orbit at the destination allows you to 'start' at that higher orbit for the return trip and thus obtain all of the delta-V savings that you can.

I have to admit that the gravitational parameter is just about the last thing I would think to check, too. I'm glad that you figured it out. I don't know whether desmos can do this, but Newton's method works just as well on the hyperbolic form of Kepler's equation as it does on the elliptical form. I know that it can be calculated, but I do not know whether it is easily iterated, let alone automated.

That seems to me to be an asymmetric thrust problem. You'll need to turn on the centre of thrust indicator in the VAB and ensure that the line coming out of it points through the centre of mass. It's a bit tricky to do since the line doesn't come out of the front of the marker, but you can do it by rotating the view of the vessel while in the VAB. Before you get that far, be certain to remove any boosters that will be expended before you light the OMS engines; you don't want to include engines that will be staged away by the time that the OMS fires because they and their tanks will throw off your centres of thrust and mass in the VAB, which would lead you to optimise for the wrong configuration. Once you do that, you'll need to rotate the OMS engines to align the thrust with the centre of mass. When I do it, I try to get my view behind the centre of thrust and rotate my view so that the centre of mass disappears behind it, and then rotate engines to align the thrust vector, too. This is much easier to do if you first rotate the whole rocket to be on its side or even switch to the SPH for this portion; thrust and mass don't care about the direction of gravity. Next, you'll need to drain the propellant tanks and see whether the centre of mass shifts appreciably. If you're using something like an SSME (that's a Space Shuttle Main Engine, which is the engine that used the propellant from the big orange tank on the real Shuttle) instead of, or in addition to, an OMS system, then you'll probably need to move the orange tank (or equivalently-coloured tank) up on the shuttle's belly so that its centre of mass is on the same line as the thrust. That way, the centre of mass as the tank drains only moves closer to the engines along that thrust line, and you either eliminate or significantly reduce the asymmetric thrust. Note that if you have wings or other engines, then the thrust of the shuttle may not point precisely where the OMS engines do. Also, as you go into vacuum or change engine configurations, the powered flight performance of the shuttle will change as well. There's no good overall solution for that, but you can still optimise the engines' alignment for where you intend to most use them: for example, don't take lift into account at all if you intend to use the OMS engines only in orbit or the upper atmosphere. I hope that helps, and if it doesn't, then please do let me know (and provide more details so we can help you more).

FlybyFinder won't do multiple passes of the same body. It can calculate a J-D-K-D trajectory, for example, but not a J-K-K-D trajectory. It has to do with the fact that solutions to Lambert's problem break down when considering transfers from a point to the same point (actually from a radial distance from the centre of attraction to the same radial distance, but it's the same issue as in a repeat flyby). There are ways to perform that calculation, but I've found them all to be far less than user-friendly. Were I given the choice, I'd exhaust the possibilities with the J-K-K-D path first, even after accounting for the higher up-front cost, because it allows one to either append a second Duna flyby to it if needed, or escape to Kerbin should it turn out to cost too much.

You considered using a Duna flyby to raise your periapsis after all of this; after two Kerbin flybys to get your solar apoapsis down to Duna's altitude, it makes sense--provided that you have the life support--to use Duna to raise your solar periapsis so as to slow your velocity on your next encounter. I went a little mad with FlybyFinder and a J-K-E-D trajectory, that being roughly what you initially proposed. My numbers largely agree with yours; I haven't yet found a way to get the braking delta-V down to a manageable value for your vessel. However, the most efficient assist trajectory I know to get to Jool from Kerbin is the K-E-K-K-J assist; it would not surprise me to see that a good way to Duna from Jool is a J-K-K-D-D assist. It shouldn't be terribly difficult to set up, since your K-D transfer will have Duna catching up to you from behind; your main need at that point will be to course correct to get the second encounter, and possibly also to boost for an encounter within your life support window.

I thought that the impracticality was implied by the 5 centimetre acceleration. You have my apologies if that was not clear; to be unequivocal, though, allow me to state for the record that you certainly won't see me trying to push a kilotonne craft with only one Nerv engine, whether at Gilly or anywhere else.

Gilly's surface gravity is .049 m/s2. The Nerv has a thrust of 60,000 N. This would mean that a Nerv can, at least theoretically, land a craft of anything up to 1,224.5 tonnes, though for a safety margin it's probably best to limit the weight to 90-95% of the thrust. It'll still take a long time (a Nerv pushing that mass will have the same acceleration as Gilly's gravity, so 5 cm/s2), but you're underrating the Nerv by a factor of about four.

The problem with that is that a differential equation would describe a rate that is at least partly dependent on its own rate of change, but your trajectory, at least while you're in free-fall, should be constant. You absolutely could describe that as a differential equation, but its only solutions are trivial or degenerate in the same sense as solving for the parabola ax2 + bx + c = 1 for all x. The variable terms drop out and you're left with a constant function for a constant output. For a powered transfer, that's another matter, but that gets complicated quickly. I took a look at your situation from a standpoint of specific orbital energy, and the only conclusion that I have is that you are not reporting a parameter correctly for that orbit. I don't mean that you are failing to read the numbers correctly--bugs are the usual suspects--but something is definitely wrong. At the given radius from the sun, your specific orbital potential energy is approximately 101 megajoules per kilogram. Keep in mind that specific potential energy has absolutely no dependence on velocity; it is only a function of radial distance and the standard gravitational parameter. At a minimum, your specific kinetic energy must exceed that, or it's not even a hyperbolic orbit--let alone the hyperbolic orbit that you want. To have the semi-major axis you reported, your total specific orbital energy, which is constant for the entire orbit no matter where you are on it (and, therefore, which is also independent of velocity), is and must be approximately 1,196 megajoules per kilogram. This should make sense; an eccentricity of 23.8 comes from a hyperbolic trajectory that is almost flat, and as such necessarily must be utterly dominated by the specific kinetic energy term. With the velocity you gave, your specific kinetic energy is only 91.7 megajoules--that, as I mentioned above, is not enough to escape. This is further confirmed by the fact that an orbit such as you describe has a vinf, or excess velocity at infinity, of 48,907.7 m/s. That is the low point of the orbit's velocity. It is possible that there is a bug in this, given that you can't totally escape from the sun, but on the other hand, the sun's sphere of influence is the only one in the game that actually is infinite (to within any acceptable approximation), so if anything, the equations ought to be most accurate for objects in solar orbit. The only suggestion that I have for you is to re-check the data. At this juncture, you may as well question everything. My value for the solar standard gravitational parameter is 1.1723328 x 1018, which is the value from the wiki. Is that value correct? Check it. Is the velocity being reported correctly, and as relative to the sun? That is definitely worth a check. Look at the visual appearance of the orbit. Is it actually hyperbolic? Does it look like a hyperbola with an eccentricity of 23.8? I suspect that your orbit information is a bit askew; there's very little chance that you are confusing an orbital velocity of 13,550 m/s for one of approximately 50,000 m/s, so perhaps you've reached some kind of error relating to the magnitude of your semi-major axis. What does Kerbal Engineer have to say about it? Do you have a persistence file containing this mission with the Mira at its solar periapsis? Seeing the values that the game is using to place the orbit would help to decide once and for all what it is trying to do.

As others have said, yes, it can be done. One way is to throttle down and use a low simmer to keep your apoapsis in front of you until you circularise, but in fairness, shutting off the engines and restarting is just a special case of this where low burn becomes no burn. The way that real rockets do it, at least occasionally, is to burn full blast but to turn radial inward to adjust both apoapsis and periapsis so as to achieve a circular orbit with one burn. This necessitates a bit of planning and a willingness to use more fuel. I don't think that anyone has answered this part yet. You can adjust the ascent profile in MechJeb in a couple of ways. One is to adjust the gravity turn profile, but you probably don't want to do that. The other thing that you can do is to adjust the orbit altitude setting, along with the thrust and turn limiters (and the other settings) in the appropriate panel. I believe that MechJeb more or less assumes that you'll need to coast to a circularisation burn (it's a consequence of Kerbin being a toy-sized planet; real rocket ascents take twenty minutes or more), but with a bit of tweaking, I think that you can get it to put you in orbit with a continuous burn. Note that as @bewing said, the exercise is academic in terms of practical use; it saves neither time nor fuel. That's not a recommendation against trying it--by all means, do so; it's your game--but a caution that most people here chase efficiency and so there probably isn't much material to guide you: you'll need to figure out the appropriate settings for yourself. That being said, if you do manage it, then please do post the settings here; you can help to establish the guidance material for anyone else who wants to do what you're attempting.

Because of the relative similarity of orbits of adjacent celestial bodies, it works out that they have the longest separation between transfer windows. In other words, the easier it is to get to a destination, then the longer you'll be waiting to go in the case that you want to wait for the window. You have a few options. You can do missions in the meantime, but you should know that the in-system missions between Kerbin and the Mun or Minmus are orders of magnitude shorter than interplanetary missions. You'll likely get bored before you get to the window. Time warp is a stock game feature; using it isn't cheating in even the strictest interpretation of the idea. Another choice is to do your warping first thing, and start your program a bit before the window. That's a little like what @king of nowhere suggests, though I took it that the suggestion is also to get out of career and go to either sandbox or science mode. That's also valid, but if you want to keep the feel of career, then you can warp first and finish your progression with a time offset to bring your start point more in alignment with your interplanetary goals. Yet another choice is to redesign your rockets and your program. You don't need to wait for a window to open if you have a rocket powerful enough to 'kick in the door', so to speak. Windows are more efficient, but the game doesn't reward efficiency; it rewards contract completion (and a couple of other things like science experiments). Yes. Back up your save (or make a new one) and then hit the warp button already. If you don't like it, then revert and play without warping. In spite of the theme of the game, this part isn't rocket science; the only thing making it difficult is your reluctance to experiment with how you play. So experiment! Maybe you'll enjoy it more. Maybe not, but then you'll know. Why not just try it?