Zhetaan

@antipro: The short answer is yes. The longer answer is that it depends. For extremely high-period orbits, the amount of 'perturbation' (it isn't, really) is lessened when the 200 milliseconds is such a tiny fraction of the overall orbit. A 40,000,000 metre circular orbit of Eve has a semi-major axis of 40,700,000, for a period of 2π * √ [(40,700,0003) / (8.1717302 x 1012)] = 570,708.6729 seconds, or 26 days, 2 hours, 31 minutes, 48.6729 seconds. This is over the circumference of 255,725,642 metres. If we make a pessimistic assumption that one of your satellites is exactly correct and the other is exactly 200 milliseconds less, that gives a distance loss of 89.6 centimetres per orbit. If we assume that the distance to the coverage overlap is also the minimum distance for loss-of-signal, then that means that you need to lose one sixth of the orbit, or 42,620,940.3 metres, before you have a signal loss. That requires 47.5 million orbits. At 26 days (or a little over) per orbit ... ... ... I don't know about you, but I am going to make a snack while we wait.

@Fraktal: @eatU4myT has the first part correct, and what you describe appears to be inclination. @eatU4myT: You're correct about the first part, but not quite the second part. It is probably best to consider eccentricity as an intrinsic property of conic sections; because of the way it is calculated, it is at least equally correct to say that it is relative to a parabola. This is because a conic section in the geometric sense is a construction related to a point called the focus and a line called the directrix. Ellipses and hyperbolae have two foci and two directrices, and a parabola has one of each (though an argument could be made that it has a second focus at infinity). Eccentricity is the relationship between the distance from a point on the section to the focus and the distance from that same point to the directrix; in other words, when the distance from a point to the focus is divided by the distance from that point to the directrix, the resulting proportion is a constant for every point on the curve, and that constant is equal to the eccentricity. The geometric definition of a parabola is that it is the set of points exactly equally distant from the focus and the directrix, which, since these distances are divided to get the eccentricity, of course defines its eccentricity to be exactly 1. For an ellipse, the directrix is always farther away than the focus, and for a hyperbola, the directrix is always closer than the focus. A circle is not just a special case of an ellipse; under this definition, it's the limiting case in that the circle's directrix is at infinity. Since eccentricity is (distance to focus) / (distance to directrix), a directrix at infinite distance implies an eccentricity of zero. While Kerbal Engineer and MechJeb give you information about your current orbit, I don't know whether they give you detailed information about orbits post-sphere-change. Once you're in the new sphere, I can't speak to the other mods, but I know a dirty back-of-the-envelope method that will get the information you want, albeit not the way that you'd prefer it. The manoeuvre planner in MechJeb has an option to plan a burn to set the eccentricity to a value you define, so if you put in .8, it will give you that burn. Of course, that is not the same as examining your current burn and telling you whether it will work. However, if you are amenable to using a pencil and paper, there's nothing keeping you from looking at your periapsis (I assume that you want to burn at the periapsis) and calculating which apoapsis gives the target eccentricity; then it would be a matter of establishing the required burn. KSP won't give you the equations but the other values needed, such as the Mun's gravitational parameter, are available in-game. It's the same general idea as using MechJeb's planner, but you do the calculations yourself, which, since you seek greater understanding, is one way to get it. Another way is to compare and contrast orbital energy and run through those calculations; you'll get not only the exact manoeuvre required to close the orbit to the desired eccentricity, but also will be able to account for the Oberth effect and all of the other little gotchas of orbital mechanics. Any way you want to do it, good luck!

Hmm. I think that they fixed infiniglide with version 1.0. The Klaw bug was fixed in 1.3 ... I think? I think that the ladder bug is gone, too. The wheel problem still exists, though I don't know whether it's controllable. I am definitely not the right person to show you how to use the Kraken drives that still exist, but I can point you in at least one good direction: look up the YouTube channel Danny2462. He's tested (and in a lot of cases, invented) just about every Kraken drive that there is, and he does you the favour of giving the KSP version number. He tends to focus on breaking the universe, but in the process, he does often go to interesting places at even more interesting velocities.

The simple explanation is that the number is variable; Kraken drives are, by definition, bug-powered, and so with each new release, the type and scope of Kraken power necessarily changes. Generally speaking, however, they work by exploiting what are called 'phantom forces' that result from part clipping errors. The basic idea is that when you force two parts to be in the same space, they try to push apart. Since the pushing doesn't require any input, only that the parts be in contact (and be from two different vessels--that's important, too), you can get momentum from nothing. Some of the other types--some of which remain outstanding bugs, and some of which have been fixed--include infiniglide, which used a quirk of control surfaces to fly forever; the physicsless parts bug, which exploited a setting used for some parts to consider their mass negligible to create inertialess vessels; the ladder bug, which allowed a Kerbal who climbed a ladder which dead-ended into another part to move a vessel (one person got to Eve orbit from sea level by climbing a ladder); and the rover wheel bug, which will almost always make you fly and which can sometimes get you to Eeloo in about six seconds if you want to try jumping on a wheel. I'm sure that there are others, although I don't know how many or how many of them work. So far as I know, there's no compiled list.

Also, just so you're aware, there is no way to extract the processed science from the lab and return it to Kerbin in another vessel. You can transmit it or send equipment to assist it in that transmission, or else you can return the entire lab to Kerbin and recover it, which I understand will also recover any science stored inside. The reason for that is because the way science is normally transferred from place to place is as discrete experiments in containers that carry experiments, rather than science points. Once the data is processed in the lab, it becomes unbound science points that are not tied to any specific experiment and therefore cannot be transmitted in an experiment container.

@Popestar: I'm a bit late to the party, and I don't have any bubble gum, but I may be able to help you. With 192k Funds, money isn't a problem. You can build a fully flyby-capable rocket with 20 parts for less than 10k Funds. I tried to do it with a tier-1 launchpad, but the 18-tonne limit was enough of a frustration that I will go so far as to say: don't bother. A tier-2 Tracking Centre is very, very helpful, but again, not necessary. I don't know the specifics of your career, so I assumed that you had the first three tiers of technology unlocked, plus Advanced Rocketry from Tier 4 (Tier 4 would be the nodes that cost 45 science to unlock). I also assumed a Tier 2 Launchpad and Tracking Centre. The trick to remember about flybys as opposed to landing (or even orbiting) is that the flight is functionally equivalent to a rendezvous. The only real differences are that you don't burn to match velocities and that the thing you are approaching has a sphere of influence that can throw you out of the system if you're not careful. Therefore, your flyby rocket really doesn't need to be more elaborate than an orbiter with extra fuel. Trying to build a flyby rocket from a landing tutorial can cause problems because the transfer, capture, and landing can all be (and sometimes need to be) separate and discrete phases of the flight, complete with their own stages and equipment, almost none of which is necessary for a flyby and almost all of which thus adds unnecessary mass--catastrophically so, if you don't have the upgrades needed to actually fly those rockets. Thus, while it is true that any lander is necessarily an orbiter and a, er, ... flyby-er (?) ... the point is that a lander that is used for that purpose is far too much rocket for that particular job. To wit, the rocket given in the Mun landing tutorial that you linked has about three times more things than you need for a flyby. I was able to do it with the following rocket (apologies for no picture): Parts: (1) Mk. 16 Parachute (2-3) Mk. 1 Command Pod (with monopropellant drained) ------> Mystery Goo (4) 1.25m Heat Shield (with 20.0 ablator) (5) 1.25m Decoupler (6) FL-T400 Fuel Tank (7) LV-909 'Terrier' Engine (8) 1.25m Decoupler (9-11) Aerodynamic Nose Cone FL-T400 Fuel Tank Aerodynamic Nose Cone (12-14) TT-38K Radial Decoupler <------ FL-T400 Fuel Tank ------> TT-38K Radial Decoupler (15-19) Basic Fin <------ BACC 'Thumper' SRB FL-T400 Fuel Tank BACC 'Thumper' SRB ------> Basic Fin (20) LV-T45 'Swivel' Engine I'm certain that this can be improved. This rocket is an absolute jitney; it does the job but is not elegant and shouldn't be legal for passenger fare. It does leave ten parts of room for you to improve the rocket, and it comes to a total mass of 27.6 tonnes, a price of 9,840 Funds, and a delta-V of 5,807 m/s. Now, to walk you through the design rationale: You only need one parachute. You're using the atmosphere and the heat shield to do your braking, and extra parachutes don't add to that because you're not bringing the extra mass of a service bay. You don't need a reaction wheel or batteries; the on-board ones in the pod are enough. I'd recommend keeping rotations to an absolute minimum, though; you have no solar panel and only the Swivel engine has an alternator. No service bay means carrying your Mystery Goo in the open for all to see; this is not a rocket for polite company. Put it on the east-facing side of the pod (that's the side facing the open door in the VAB) so it doesn't deflect your rocket to the north or south (I don't recall whether the Mystery Goo has physics, but I'm treating it as though it does). If you have the 1.25m heat shield, then you have the thermometer and barometer, too, so bring them if you want an easy upgrade to this rocket. Keep the science instruments high up on the pod; you want the pod to shield them as much as possible on reentry because you don't have a separate science container, and if you don't have an upgraded Astronaut Complex, then you can't EVA and thus must bring the experiments home. You do need a heat shield; it may not be completely, absolutely necessary, but you're returning from the Mun, so have a heat shield. You only need a minimum of ablator, though. The FL-T400 tank and Terrier engine will be working for nearly the entire trip. The Swivel stack isn't enough to make orbit on its own, so the Terrier will get you the rest of the way to orbit, all the way to the Mun, and will de-orbit you on the way back. The tutorial that you linked mentions that liquid boosters are easier to control and worth the expense over the cheaper solid rocket boosters. That's true. A Thumper, however, is a propellant tank and engine in one part--your limiting factor here is part count, not cost, so design accordingly. I turned the thrust limiter on these down to 75%; you may want to do the same so that your tiny pod-based reaction wheels can have a chance to actually turn the rocket. You can exchange the Basic Fins for AV-R8 Winglets if you have them, but that requires unlocking Flight Control in R & D (it'll cost another 45 Science). Struts are parts. Nuts to that. Use 'Rigid Attachment' on the Thumpers and call it good. Autostruts are not parts. Nuts to that, too. You don't need them on this rocket. TT-18A Launch Stability Enhancers? What, are you crazy? This rocket takes ground control seriously. If you add the extra experiments, then the price comes to 11,620 Funds, and 12,850 Funds if you go in for the AV-R8 Winglets. The game begins new saves on Year 1, Day 1, not Year 0, Day 0. Your flight plan was for six days hence, not a year and six days. Almost all of the tutorials that you're likely to find will be about landing on the Mun, I'm afraid. If you're comfortable with picking and choosing relevant parts from many tutorials, then I suggest that you look into any that you can find that cover rendezvous of two objects in wildly different orbits (as in, for example, one vessel in an 80 km orbit that wants to rendezvous with something in, say, a 12,000 km orbit). The idea is that where the conventional approach is to get into a similar orbit and then adjust it from there, when you have such a drastic difference, it's extremely wasteful to circularise at such a high orbit unless it's also at the rendezvous point with your target. Another possibility is to look at scanner tutorials and maybe Grand Tour-type compound-flyby missions. Scanners don't land, so they're at least one degree closer to a flyby than landers. Alternatively, you can do this extremely quick not-really-a-tutorial that I wrote just now: I assume that you can take the example rocket I gave you above and get it to orbit. It may take a couple of tries; but the ascent profile is typical: start turning at 1,000 metres or 100 m/s, turn slowly, be roughly at 45-degrees at 10,000 m, and be on a fairly flat trajectory by 30,000 m. The main point to watch is that the Swivel will run out when you're still suborbital. You may want to aim slightly up to ensure that you have an apoapsis out of the atmosphere, but it's not necessary; the Terrier has 59.9 kN of thrust (out of 60 kN) at 60,000 m, anyway. Don't worry about having exactly zero inclination. Don't worry about being perfectly circular. Aim more upwards if you start seeing overheat bars on the experiments. The Tier-2 Tracking Centre doesn't have manoeuvre planning, so you'll need to get the Mun intercept by eye. Go into Map View and orient the map so that you're looking down at Kerbin's north pole. Rotate the view so that the Mun is 45 degrees clockwise from the top of the screen. The point on your orbit that is closest to the bottom of the screen is where you want to burn. Time warp until your vessel is at (or very near to) that point; it helps to change focus to Kerbin so that you can place the tip of your mouse pointer cursor at the burn location and expect it to remain still; this is our poor-man's manoeuvre node (you can change focus back to your vessel with the ` key, which is to the left of 1 on an American layout). Hopefully by this point, you'll see why I made certain to include 1,000 m/s more than the delta-V map says you strictly need. Burn for intercept. But throttle down when your apoapsis gets close and keep your finger over the cutoff; shut the engine down immediately once you get an encounter. The Tier-2 Tracking Centre does show patched conics, so you'll know immediately when you get an encounter. This is why I find it so helpful. This is the most important thing to remember about flyby missions: any entry and exit of the sphere of influence counts as a flyby. You're not trying to orbit, let alone land, so you don't need to go down to the bottom of the gravity well. On the other hand, although the Mun is rather bad at gravity assists, it can still thoroughly ruin your mission with one, so don't give it the chance: cut the shallowest chord possible through the Mun's sphere of influence. You're not carrying duplicate science experiments and you can't EVA to reset anything in early career, so get the high-in-space science and go home. Leave yourself enough time to do your experiments (don't forget your crew report!), but don't linger, because the longer you're there, the more your post-encounter trajectory will change. I typically end up with about one to two hours in the Mun's sphere; that's quite enough. Your brief time in the Mun's sphere will still have raised your orbit by a bit, so when you exit, you'll find yourself at or approaching the apoapsis of your Kerbin orbit, which is terribly convenient: burn retrograde to lower the periapsis to about 40,000 metres. You may want to modify that value after trying the rocket for yourself--keep in mind that I'm giving you the barest essentials of the mission. When you get close to Kerbin, you may want to burn to lower your apoapsis. This is mainly to reduce your velocity in atmosphere; your 20 ablator will run out very quickly if you come in too fast. Your heat shield will still work, somewhat, afterwards, but I tended to run out of ablator at the very end of my need for it, so I wasn't concerned. Land, and enjoy the fruits of your mission: with default difficulty settings, you get 82 science from the experiments and recovery if all went well and you completed the crew report, barometer, thermometer, and mystery goo experiments. You have other options. For one thing, there are the World's Firsts rewards for the flyby (this assumes default difficulty and rewards settings, that the reputation is from a start of zero, and that you've not gone to the Mun yet in this save): Event Funds Science Reputation First Flyby of Mun 26,000 2 4 Escaping Kerbin's Sphere 26,400 3 5 Escaping the Mun's Sphere 18,720 1 3 Returning to Kerbin from the Flyby 26,000 2 4 Totals 97,120 8 16 Also note that part test contracts give you the parts that you need even though they may be locked (some people, on getting a contract for a very good part that they have not yet unlocked, will delay completing these for several in-game years while they enjoy the use of the part on many experimental prototype 'testbeds'). You can try to get more World's Firsts for Kerbin. Have you tried rendezvous? Docking? Building a space station? These all pay rewards for the first time you do them. If you have any other questions, please do feel free to ask. Until then, happy non-landings!

Let's go through it step by step. There are certain assumptions and simplifications that we can (and should!) apply to this problem, but the overall result will still be close enough to correct. First, however, since your issue is more about your assumed expectations, let's look at the problem more abstractly and see what insights we get from it to correct your intuition. For one thing, your orbit radius is a bit over twice Minmus's radius (remember that an altitude of 70,000 metres is actually 130,000 metres from Minmus's centre). In terms of the abstraction, let's call it exactly twice and work from that. If Minmus is at half of the orbital radius, what then? If we assume that the orbit is a unit circle, that the sun shines from the left side of the graph, and that Minmus's shadow is a cylinder (projected to be a rectangle--the point is that it does not taper), then Minmus's bulk will cover the right side of the orbit to half of the orbit's maximum height above the x-axis. Thus, we want the angle that leads to a point y = .5 on the unit circle. We can solve that with trigonometry: arcsin (.5 / 1) = 30°. Of course, Minmus covers a portion of the shadow below the x-axis, too, so we need to double the angle. The total included angle is therefore 60°. We can get that value another way, courtesy of our abstraction: if the orbit is twice Minmus's radius, then the size of the shadow, which itself is twice Minmus's radius, will equal the orbit radius. Since the distance from the origin to the edge of the shaded part of the orbit is going to be one orbit radius for both the upper and lower edges of the shadow, it altogether makes an equilateral triangle, so the included angle is definitely 60°. Since your actual orbit is slightly larger than double Minmus's radius, we can safely expect that the true included angle will be near to but less than this value. In terms of the fractional coverage of the larger orbit, 60° is one sixth of the total orbit, and of course the total is the full circle at 360°. If you expect a darkness time of 30 - 45 minutes, then you expect an orbital period of 180 - 270 minutes, or 3 to 4.5 hours (actually slightly more). If you find your orbital period in KSP, you'll see right away that that does not make sense. The reasons why are less intuitive, but it's simple enough to check. Orbital period is better to use, but your orbital speed is the first parameter that KSP displays, so let's work with that, instead. I'll show the calculation later, but for now let's assume that it is at or very near to 116.5 m/s. The circumference of a 130,000-metre circular orbit is 816,814 metres, so going around that orbit at that rate gives a period of 116.85 minutes. Thirty minutes of darkness is a little more than one quarter of that orbit. Forty-five minutes is closer to forty percent--and that should immediately feel absurd, because fifty percent coverage is what you get at the surface. Forty percent coverage requires you to be so close to surface altitude that to achieve it should have you crashing into the mountaintops. One sixth of the orbit gives about 19.5 minutes, but again, we've already shown that the actual value will be somewhat less than that. Now to the more precise calculations: Minmus has a standard gravitational parameter, μ, of 1.7658 x 109 m3/s2 and a radius, r, of 60,000 metres. A circular orbit at 70,000 m altitude has a semimajor axis, a, of 130,000 metres, which is equal to the orbital radius at all points on the orbit. This orbit thus has an orbital speed, v, of: v = √(μ / a) v = √(1.7658 x 109 / 130000) v = √(13583.1) v = 116.5 m/s Minmus's shadow cone technically ought to vary in length over the course of its orbit about Kerbin. Since neither Minmus's orbit nor Kerbin's have any eccentricity, the constraints on the variation, and thus also the variation in taper angle, should be relatively easy to determine. However, for one thing, this orbit is close enough to Minmus that approximating Minmus's shadow as a cylinder with no taper will work more than adequately (it will slightly overestimate the darkness time, but not by a lot), and for another thing, I don't know how faithful KSP is to the realities of physics in this case. I would like to assume that it is accurate but I have neither tested it nor seen anyone else do so. Under these assumptions, the included angle of the shadowed arc of the orbit, θ, is given by twice the arcsine of the body radius, r, divided by the orbital radius, R: θ = 2 * arcsin (r / R) θ = 2 * arcsin (60000 / 130000) θ = 2 * .479729 rad θ = .95946 rad or 54.97° The arc length of the shadowed portion of the orbit, l, is given by the included angle multiplied by the orbital radius: l = R * θ l = 130000 * .95946 l = 124,729.4 m At the previously-calculated (constant) rate of speed, your vessel will cover this length in time t: t = l / v t = 124729.4 / 116.5 t = 1070.6 seconds t = 17.84 minutes Your calculations are correct.

@American Patriot: Ask not what your forum can do for you .... Part Size Cost Full Empty Mass Ratio Cost per Tonne R-4 'Dumpling' External Tank Radial mounted 50 0.1238 0.0138 9.0 404 R-11 'Baguette' External Tank Radial mounted 50 0.3038 0.0338 9.0 165 R-12 'Doughnut' External Tank Small 147 0.3375 0.0375 9.0 436 Oscar-B Fuel Tank Tiny 70 0.2250 0.0250 9.0 311 FL-T100 Fuel Tank Small 150 0.5625 0.0625 9.0 267 FL-T200 Fuel Tank Small 275 1.1250 0.1250 9.0 244 FL-T400 Fuel Tank Small 500 2.2500 0.2500 9.0 222 FL-T800 Fuel Tank Small 800 4.5000 0.5000 9.0 178 Rockomax X200-8 Fuel Tank Large 800 4.5000 0.5000 9.0 178 Rockomax X200-16 Fuel Tank Large 1550 9.0000 1.0000 9.0 172 Rockomax X200-32 Fuel Tank Large 3000 18.0000 2.0000 9.0 167 Rockomax Jumbo-64 Fuel Tank Large 5750 36.0000 4.0000 9.0 160 Kerbodyne S3-3600 Tank Extra large 3250 20.2500 2.2500 9.0 160 Kerbodyne S3-7200 Tank Extra large 6500 40.5000 4.5000 9.0 160 Kerbodyne S3-14400 Tank Extra large 13000 81.0000 9.0000 9.0 160 Mk2 Rocket Fuel Fuselage Short Mk2 750 2.2900 0.2900 7.9 328 Mk2 Rocket Fuel Fuselage Mk2 1450 4.5700 0.5700 8.0 317 Mk3 Rocket Fuel Fuselage Short Mk3 2500 14.2900 1.7900 8.0 175 Mk3 Rocket Fuel Fuselage Mk3 5000 28.5700 3.5700 8.0 175 Mk3 Rocket Fuel Fuselage Long Mk3 10000 57.1400 7.1400 8.0 175 C7 Brand Adapter - 2.5m to 1.25m Small, Large 800 4.5700 0.5700 8.0 175 C7 Brand Adapter Slanted - 2.5m to 1.25m Small, Large 800 4.5700 0.5700 8.0 175 Mk2 to 1.25m Adapter Small, Mk2 550 2.2900 0.2900 7.9 240 Mk2 to 1.25m Adapter Long Small, Mk2 1050 4.5700 0.5700 8.0 230 Mk2 Bicoupler Small, Mk2 x 2 860 2.2900 0.2900 7.9 376 2.5m to Mk2 Adapter Large, Mk2 800 4.5700 0.5700 8.0 175 Mk3 to Mk2 Adapter Mk2, Mk3 2200 11.4300 1.4300 8.0 192 Mk3 to 2.5m Adapter Large, Mk3 2500 14.2900 1.7900 8.0 175 Mk3 to 2.5m Adapter Slanted Large, Mk3 2500 14.2900 1.7900 8.0 175 Mk3 to 3.75m Adapter Extra large, Mk3 2500 14.2900 1.7900 8.0 175 Kerbodyne ADTP-2-3 Large, Extra large 1623 16.8800 1.8800 9.0 96 Mk0 Liquid Fuel Fuselage Tiny 200 0.2750 0.0250 11.0 727 Mk1 Liquid Fuel Fuselage Small 550 2.2500 0.2500 9.0 244 Mk2 Liquid Fuel Fuselage Short Mk2 750 2.2900 0.2900 7.9 328 Mk2 Liquid Fuel Fuselage Mk2 1450 4.5700 0.5700 8.0 317 Mk3 Liquid Fuel Fuselage Short Mk3 4300 14.2900 1.7900 8.0 301 Mk3 Liquid Fuel Fuselage Mk3 8600 28.5700 3.5700 8.0 301 Mk3 Liquid Fuel Fuselage Long Mk3 17200 57.1400 7.1400 8.0 301 NCS Adapter Small, Tiny 320 0.5000 0.1000 5.0 640 FL-R10 RCS Fuel Tank Tiny 200 0.1000 0.0200 5.0 2000 FL-R25 RCS Fuel Tank Small 330 0.5600 0.0800 7.0 589 FL-R1 RCS Fuel Tank Large 1800 3.4000 0.4000 8.5 529 Mk2 Monopropellant Tank Mk2 750 1.8900 0.2900 6.5 397 Mk3 Monopropellant Tank Mk3 5040 9.8000 1.4000 7.0 514 Stratus-V Roundified Monopropellant Tank Radial mounted 200 0.1000 0.0200 5.0 2000 Stratus-V Cylindrified Monopropellant Tank Radial mounted 250 0.2300 0.0300 7.7 1087 PB-X50R Xenon Container Radial mounted 2220 0.0540 0.0140 3.9 41111 PB-X150 Xenon Container Tiny 3680 0.1000 0.0240 4.2 36800 PB-X750 Xenon Container Small 24300 0.7600 0.1900 4.0 31974

In that case, congratulations! You're half-way to anywhere. Welcome to the happy family, too--this forum is very much the right place to go to find advice. Well, that all depends on what you want to do. The missions that you're getting right now are probably offering contracts to either visit one of the moons or perform a rendezvous in orbit--assuming that you're playing in career mode, that is. That's a good place to start, but KSP is an open-ended game with no specific win condition. The goal is to get out there and explore, and it's completely up to you to decide how to do that. Were I in your position and playing career mode, my next move would be to upgrade both Mission Control and the Tracking Station to level two, because doing this provides access to manoeuvre nodes and flight planning. From there I'd next look to re-enact an Apollo-8-style Mun mission where I orbit but don't land. From there, it really is up to you. You can try doing an Apollo-style mission, but that will require you to learn rendezvous and docking. You can try doing a direct flight (meaning no separate lander), but that will require you to design a new type of rocket. You may want to invest in probe cores, since you'll most likely make a lot of mistakes. On a related note, you might as well see the orientation video: Hilarity aside, this really does describe a common experience among players. Keep a sense of humour, and hope that you don't need to go all the way to four rescue missions to save one kerbal. Aside from Gameplay Questions, where you are presently, there is the Tutorials section. You'll get more of a technical take on solving problems here, and more of the step-by-step stuff from there. Another place to look for inspiration is the Mission Reports section. Most of the materials that I used to learn were made for much older versions of KSP, so there's a limit to how much they can help you--a lot has changed in the past seven years. You're probably best served by looking at some of the YouTube resources out there, but be wary of anything more than a year old and especially so for anything more than two years old. There's still good information to be found in the older stuff, but it definitely has a half-life. Trial and error is still a good teacher, so you may find it best to decide on what you want to do next, and then ask for help should you have trouble. There aren't any mods that you absolutely need. The stock game is fully playable. But in the interests of a complete answer, mods can largely be divided into four broad categories: visual mods, information mods, part mods, and gameplay mods. Visual mods change the appearance of various game objects: in your screenshot, did you notice that Kerbin has clouds and a pretty aurora? That's a visual mod. Information mods usually supply you with information that the stock game does not, though they occasionally offer stock-available information in a more readable form or otherwise improves on stock. Kerbal Engineer Redux is an example of the former; Kerbal Alarm Clock is an example of the latter. Part mods are exactly what it says on the tin. Often, new parts go along with gameplay mods, but some mods only offer new parts. There are new jet engines, new station parts, new wings and aeroplane parts, and other things that make use of the stock mechanics but offer something better suited to specific missions. Eve Optimized Engines is an example of this. Gameplay mods are the most diverse. They include changing existing functionality, adding new features, taking features away, and can involve anything and everything from adding a strut that can be attached in-flight to changing the face of the solar system (however, I concede that planet packs may well constitute a fifth category at this point). I will say that you may find Kerbal Alarm Clock to be helpful; it will offer you reminders of upcoming burns and transfer windows and the like so that you don't forget missions when you have several going on at once. It also helps you avoid accidentally time-warping so far past a burn that you need to reload the game to have another chance. Kerbal Engineer may offer too much information that you do not yet know how to use--especially since a lot of its staple offerings are now part of stock. MechJeb is more than an autopilot--it can calculate advanced interplanetary transfers without necessarily flying them for you, for example--but you don't need it if you don't want it. If it really bothers you, then you can install kOS and write your own autopilot. Anyway, that's everything that I have to add to answer your questions for now. If you have other questions, then please feel free to ask.

Free Google translation: @M@tyu: English: Welcome to the forum! I see nothing wrong with the solution that @jimmymcgoochie offered, but I'm not at a computer where I can test it. I will caution you that the merge command and subassemblies can be finicky and give unexpected results, but so long as you have an open attachment node, it can be made to work. Also, it may not be my proper place to do this, but you should know that one of the rules here is that you'll need to provide an English translation of your posts when you're posting anywhere other than in the international section. Google Translate is fine for doing that, but any post you make needs to be readable in English. I'm sure that a moderator will be along shortly to offer advice (and probably add a translation to your post for you). They are very friendly and love to help, especially when the issue is unintentional. Español: Bienvenido al foro! No veo nada malo en la solución que ofreció @jimmymcgoochie, pero no estoy en una computadora donde pueda probarla. Le advertiré que el comando de fusión y los subensamblajes pueden ser delicados y dar resultados inesperados, pero siempre que tenga un nodo de adjunto abierto, se puede hacer que funcione. Además, puede que no sea mi lugar adecuado para hacer esto, pero debe saber que una de las reglas aquí es que deberá proporcionar una traducción al inglés de sus publicaciones cuando esté publicando en cualquier otro lugar que no sea la sección internacional. Google Translate está bien para hacer eso, pero cualquier publicación que haga debe ser legible en inglés. Estoy seguro de que un moderador vendrá en breve para ofrecer consejos (y probablemente agregar una traducción a su publicación). Son muy amables y les encanta ayudar, especialmente cuando el problema no es intencional.

Yes, but not quite the way you think. So long as you are moving directly up (or, I suppose, at some point it's really more out than up), you are still in some sort of gravitational relationship with the primary, which is to say, in orbit. This is a special class of orbit called a radial orbit. Eccentricity is not an informative parameter of radial orbits, so instead they are characterised by their specific orbital energy. More relevant is the character of the orbit: there is another situation in which we might see a spacecraft approach a point on a radial orbit or otherwise zero its angular momentum, and that is in a suicide burn landing--a radial approach to the Mun is essentially a reverse of a suicide burn landing from Mun altitude. Imagine zeroing velocity at twelve million metres and coasting down to perform a suicide burn landing. This is a terrible approach because all of that time spent going straight down involves a build-up of velocity that will cause problems if you don't shed it. At the same time, reducing velocity means spending more time descending, more descent consuming propellant, and more propellant trying to hover. Although suicide burns are the result of a desire to put off until the last second the necessary wastage of such a stunt in an effort to have as little unnecessary wastage as possible, that does not obviate the fact that wastage occurs. The same is true of the reverse burn. To illustrate this wastage, consider a more typical approach to changing one's orbit: should you want to change the apoapsis of your orbit, where is the best place to do it? Normally, that would be at the periapsis, but for a radial orbit, the periapsis is unavailable. You can only change the apoapsis from the apoapsis side of the orbit--in fact, because of the way radial orbits work, it is functionally similar to waiting to reach the apoapsis of an elliptical orbit and then burning radial-out, which is to say, it is among the most inefficient methods possible. This is why, even for suicide burns, the standard advice is to approach the surface as closely as possible before cancelling one's velocity and proceeding with the landing, which is then timed so that the radial-out burn is as short as it can be while still (hopefully) providing for the survival of the vehicle and its occupants.

I found forty-four flyby trajectories of varying quality. In the interest of giving you workable results, I neglected to refine the search any more than I did, but I will caution you that these are all untested and should be taken as theoretical until proven otherwise. Also note that the plot is, for lack of a more accurate term, weird, in the sense that there is no discernible periodicity. Given that real-life alignments of the outer planets occur approximately 175 years, I suspect that this is largely due to too short a search window. Also please note that, given the travel times, some (or most) of these probably work out to have phasing orbits that take a turn around the sun before encountering the next planet in the tour. This is not a problem when considered from the standpoint of a valid flyby, but given that you want to reenact a Voyager 2-esque mission, I elect to share only the five trajectories that have the shortest travel time. Path dV Start Day Jool Encounter Sarnus Encounter Urlum Encounter Neidon Encounter Total Time 1 3195 160 630 9843 14612 32220 32060 2 3611 232 664 9940 14830 33660 33428 3 3083 220 664 9942 14875 34140 33920 4 2737 208 664 9943 14912 34530 34322 5 2576 196 664 9945 14957 35055 34859 Note that these are all fairly similar; using the shortest travel time ultimately leads to that because I'm essentially choosing from only the pointed left side of the porkchop plot. Note however the difference of 2799 days between the first and last trajectories on this list: that is over six and one-half Kerbin years. It's not much, in light of the orbital periods of the planets, so these properly could be termed subsets of the same trajectory (and I did eliminate two of my results for being too similar to ones on the list). Path 1: Start Planet: Kerbin Orbit Departure Time: 3434400 seconds UT 160 days UT Start Orbit Inclination: 7.5 degrees Start Boost from that incl.: 3195 m/s Path 2: Start Planet: Kerbin Orbit Departure Time: 4989600 seconds UT 232 days UT Start Orbit Inclination: 2.8 degrees Start Boost from that incl.: 3611 m/s Path 3: Start Planet: Kerbin Orbit Departure Time: 4730400 seconds UT 220 days UT Start Orbit Inclination: 3.5 degrees Start Boost from that incl.: 3083 m/s Path 4: Start Planet: Kerbin Orbit Departure Time: 4471200 seconds UT 208 days UT Start Orbit Inclination: 4.3 degrees Start Boost from that incl.: 2737 m/s Path 5: Start Planet: Kerbin Orbit Departure Time: 4212000 seconds UT 196 days UT Start Orbit Inclination: 5.2 degrees Start Boost from that incl.: 2576 m/s You are absolutely welcome to find and make refinements. There are likely many to be had; however, a set of trajectories that will actually get you there will at least get you closer to a true Voyager-like solution.

Fair enough. There's also a K-E-K-K-J trajectory that more or less gets everything that you can get out of repeated Kerbin flybys before you reach maximum velocity (and minimum assist), but just the paths I showed you earlier involve waiting a bit over two years between the Eve and the second Kerbin encounters; a third Kerbin encounter would add another two years to the flight time (or three; I don't remember). Do note that course corrections probably are not so bad as you fear; Eve and Jool are both inclined but still arguably in the plane of the solar system, and the flyby paths are designed to be flown on inertia alone. You'll need some manoeuvring reserve for corrections anyway, but the essence of it is that after the big burn at Kerbin, you don't light the engines again until Jool (or later). Most who fly these paths well use less than 100 m/s total for corrections, and most of that is in RCS. But there is, as usual, the trade-off between efficiency and time, and if you want to move more quickly, Duna is certainly an option. It will still take time (windows between Kerbin and Duna occur somewhat infrequently because they are next to one another in orbit) but it's a viable, albeit unusual, choice. I will suggest that you consider refuelling at Ike instead, though. The lower gravity and lack of atmosphere could be great helps to you.

I queued some Flyby Finder trajectory searches for you; a K-E-J assist window occurs approximately every 400 days, starting at day 0 (though the best assist that I found was at day 776). I neglected to post any of them because they all required, at a minimum, 3,170 m/s of delta-V to get a Jool flyby. The problem is that for Eve to raise your apoapsis to Jool orbit in one pass, you need to supply most of the energy yourself in the initial burn because the amount of velocity change that you can get from Eve is capped by Eve's own velocity. If you need more than that, either because you're going farther away or because you're approaching at an angle or speed that is less than ideal, then you need to get orbital energy from somewhere else. One place that you can go for that energy is Kerbin: the K-E-K-J trajectory is much better. I found quite a few paths that reduce your delta-V to less than 2,000 m/s. Here is a selection: Path Start Day 1st (Eve) Encounter Day 2nd (Kerbin) Encounter Day 3rd (Jool) Encounter Day Total Time (days) Initial dV (m/s) 1 1374 1564 2433 3187 1912 1338 m/s 2 1384 1568 2438 3168 1784 1358 m/s 3 1408 1568 2432 3249 1841 1621 m/s 4 1424 1572 2428 3235 1810 1920 m/s For the first path, you'll need to start from an inclination of -2.6° and 75 km Kerbin orbit. The path takes you to 120 km altitude at Eve, 284 km at Kerbin, and 1000 km at Jool. Please note that these paths all lead to Jool, but not past Jool; for obvious reasons, Flyby Finder does not calculate trajectories to open space. However, tweaking the encounter with RCS in order to tease out an assist to deep space is quite possible.

That's interesting; mine clearly do. In lieu of a charge rate, they display, 'Broken!' In fairness, I also run Kopernicus which uses its own solar panel code for purposes of pointing at multiple stars, so it's possible that the unequivocal message is a part of that code. I'll have to check. As to the code that you copied: deploystate = EXTENDED is the part that fixed the panels.

Each broken solar panel in the vessel will have a line in the save file that says something to the effect of (and I do apologise for not knowing exactly, but I'm not near a save file that I can test): STATUS = BROKEN. It could be DeployState = BROKEN--the point is that BROKEN is the key word. You'll need to change that line to say either EXTENDED or DEPLOYED--again, I don't remember which, and you'll want to check a known-good OX-STAT-XL to know for certain--but that will fix the panels. The large OX-STAT panels do not have a visual indicator of their damaged state, unlike the extendable panels that shatter when broken. The only way to know for certain whether they are working is to check the part action window and see whether they are capable of generating charge. Broken panels will have a status message of 'Broken!' in the part action window.

It's been a bit under four years. Squad added green monoliths in v1.2, and to my knowledge, green monoliths have always had this tech node unlocking behaviour.

Wouldn't that address your ballast problem? Actually, with respect to both your propeller and your range problems, you might be able to get better results by trying something more like a bathyscaphe than a submarine. I say this from a purely theoretical position, of course, so you'll need to do the testing, but you could design a vessel that is neutrally buoyant at something less than full tanks of ore. You can take wheels, Wheesleys, and some amount of wing to keep off the seafloor (probably trivial because you can tailor it so that buoyancy cancels most of your weight), explore the ocean bottoms, and when you start running low on fuel, begin converting ore. As you gain positive buoyancy, you also gain fuel and can use that to make your way to somewhere that you can mine to recover ballast and dive again. Also, I believe that fuel floats but I do not know whether the tanks float higher without fuel--i.e., I don't know whether the empty space is properly accounted, so I don't know what effect burning the fuel would have on your buoyancy. It's not a working propeller but it might be a place to start.

Oh! I misunderstood earlier; you know that it's Day 82, but in case you forget again, you need a way to determine that Day 82 is the day that you want without needing to memorise it or rely on pre-calculation. In that case, I can think of two answers. The first is to use manoeuvre nodes to plot an orbit that just barely leaves Kerbin's sphere of influence, set up a transfer to Moho's ascending node, and note the time-to-node. That is subject to inaccuracies because the thing in solar orbit is necessarily not precisely in Kerbin's orbital track, but it's probably close enough. The only way I can think of to get more accurate using in-game tools is to plot an escape burn to Moho's ascending node altitude and start pressing the + Orbit button until you get a burn that actually goes there. You'd need to tweak the node location in order to keep your escape pointed Kerbin-retrograde and you'll likely get joint fatigue in your knuckles from all of the clicking, but it should work. This depends on having something in orbit that you can use to plot these manoeuvres, whether it's your Moho vehicle or a random low-orbit satellite, but reference rockets that you put in orbit are arguably in-game tools, so there it is. Granted, you asked for fast, not accurate, but aside from setting this up in advance, I can't think of a faster way using only the in-game tools. This is a situation where you're getting a good answer for the wrong reasons. In fact, the only reason that this works is because Kerbin is in a zero-eccentricity, zero-longitude-of-ascending-node, zero-argument-of-periapsis orbit that can thus directly relate the true anomaly value of Moho's longitude of ascending node to the mean anomaly value of its own orbital position without any correction at all. However, Kerbin starts at π radians at epoch, not zero. The reason it works anyway is because it sets up a transfer orbit: you want to start on the opposite side from the destination, so adding π radians is a necessary step. If Kerbin had had any other starting location, then this would not have worked.

Since you got a departure date of day 82, wouldn't the subsequent windows for this method be multiples of 426 days (one Kerbin year) after this date? You're not transferring directly to Moho, but rather a point on Moho's orbit, and since that is a fixed orbit without perturbation, there's no synodic period: Kerbin will pass its ideal alignment with that point once every year.

I suppose you're right that I shouldn't assume others will take a non-rotating reference frame as a given. Further, you are correct that older versions could not handle dates after a century or two. Escape velocity from the sun at Kerbin's altitude is given by: vesc = √ (2μ / r) vesc = √ (2 [1.1723328 x 1018] / [13,599,840,256]) vesc = √ (2.3446656 x 1018 / 13,599,840,256) vesc = 13,130 m/s An eighty-year solar orbit with a periapsis at Kerbin has a semimajor axis of: a = 3√ (μT2 / 4π2) a = 3√ [([1.1723328 x 1018] * [9203545 * 80]2) / 4π2] a = 3√ [([1.1723328 x 1018] * [5.4211353962896 x 1017]) / 4π2] a = 3√ (6.355374838311 x 1035 / 4π2) a = 3√ (1.609835252771 x 1034) a = 252,499,474,052 metres And an apoapsis of: a = 252,499,474,052 metres 2a = 504,998,948,103 2a - Pe = Ap = 504,998,948,103 - 13,599,840,256 Ap = 491,399,107,847 metres, which is a bit over four times beyond the apoapsis of Eeloo (note that this is true apoapsis, not surface altitude). The periapsis velocity of this orbit is: v2 = μ * [(2 / r) - (1 / a)] v2 = 1.1723328 x 1018 * [(2 / 13,599,840,256) - (1 / 252,499,474,052)] v2 = 1.1723328 x 1018 * (1.4310014659636 x 10-10) v2 = 167,760,995.5397 v = 12,952 m/s Which is 177 m/s less than escape velocity at that altitude. It would take very little to push this orbit to escape, so your recollection is probably accurate.

I believe that it will disappear if the ship is still connected to it; asteroids are treated as a special category of vessel parts, so they are recoverable. I don't know whether they are worth anything. Be certain to disconnect any clawed parts and recover them separately if you should want a decorative rock accessory for your planet.

In reality, an orbital speed of zero occurs at the 'endpoint' of a parabolic trajectory. If there is any excess velocity, then the trajectory is hyperbolic (and in fact, the velocity beyond what is needed to escape is actually called the hyperbolic excess velocity), and if there is insufficient velocity, then there is an instantaneous point where the velocity is zero in the vertical direction (you're more familiar with that point as the apoapsis), so there is difficulty already in this because a parabolic trajectory is a pseudo-stable solution to the equation. In other words, if you have any excess velocity beyond escape velocity, then your speed will never go to zero; it will go to whatever the hyperbolic excess is. So to answer your question, no: there is no stable orbit with zero velocity. At best, it is a pseudo-stable co-orbital relationship where a nudge in any direction will either close the orbit or result in escape--and fun theatrics with Lagrange points don't count because those involve orbit about a third body. In terms of the game, both infinity and zero are a bit more discrete. On the one hand, there is an absolute limit to how far you can get from the sun before you have an addressing error in the coordinate system, and on the other hand, there is an absolute limit to the possible precision of a floating-point decimal such that the rounding errors will leave you with the wrong velocity. On the gripping hand, you can probably get a good approximation out at the fringes of available space.

At a minimum, your minimum inclination must be the same as the latitude of the waypoint, or else you'll never reach it. There are some disadvantages to doing that rather than using a polar orbit: you'll only touch the waypoint at the highest latitude, whereas a polar orbit gives two chances (one on each side of the planet). The other thing to remember is that you need to account for orbital resonance. Kerbin rotates once in six hours, so it rotates at one degree per minute. Your orbital period is 31 minutes, which is very, very close to a resonance; your orbit track moves across the surface of Kerbin at a rate of one degree per orbit. Of course, Kerbin itself rotates thirty degrees in that time, so to cover all of the planet, it's going to take a while. There are none I know that will project your track onto the planet, but ScanSat will project it onto a map of the surface, which is of equivalent value. Furthermore, it will project your equator crossings for the next 100 orbits and give you an idea of whether you're in a repetitive resonance or whether you'll actually cover the whole of the surface. If you'll look at this image that I pulled from the ScanSat Readme, you can see the blue and orange tick marks at the equator. Blue ticks are crossings going north and orange ticks are crossings going south; the spread and even distribution shows that the orbit is not resonant. If the ticks seem to bunch together into groups of five or six, then that indicates a strong resonance, and that means that you'll only ever cross the equator at those points; in other words, you'll pass over the same ground again and again without going to new territory. That's great if your waypoint is on your orbital track, because you'll have many chances to get the right encounter and run your tests. It's terrible otherwise.

This is my shortlist: Near Future Propulsion: Includes the Cryo Separator part that will strain xenon gas from the atmospheres of some planets. However, the xenon is not generated by this mod, but rather by the bundled dependency Community Resource Pack. The base implementation includes a 50% chance of being present in any other atmosphere and guaranteed presence in Kerbin's atmosphere, Kerbin's Water, and Laythe's Crater Bay--you have to mine the ground in those biomes; it's not in the water. Although it is extremely inefficient to strain Kerbin's atmosphere for xenon (for the most part, Kerbin resources are more for testing purposes than anything else; you can simply buy most resources in the VAB, after all), xenon is expensive enough that it may be worth it, provided you're willing to be liberal in your use of time warp. Near Future Electrical: Includes the Nuclear Recycler part that can generate xenon from depleted nuclear fuel. The problem with this is that it requires you to have a source of depleted fuel; i.e., a nuclear reactor. Nuclear reactors are heavy, expensive, and require a lot of radiators. USI Reactor Pack: The link is to MKS, but there are, I think, several mods that make use of the USI Reactor Pack. So far as I know, it is not available as a stand-alone mod but is a hard dependency for a few other USI mods, MKS being one of them. These reactors are designed to give off a tiny amount of xenon gas as a side product. Of course, like the Near Future reactors, these are neither lightweight nor cheap. Community Resource Pack: This mod does not include the parts needed to obtain resources; however, for most crustal resources, special harvesting parts are unnecessary because the stock drills serve adequately. This includes asteroidal xenon, which has an 80% chance to appear. I have not tried Xenon ISRU or any others. You may notice a certain bias towards Community Resource Pack and asteroidal xenon. From this list, it really is your best option. ... Aside from more conventional propulsion, that is. To be completely honest, a reusable crew shuttle that also makes a point of using the most expensive and difficult-to-obtain resource in the stock game seems to me to defeat the purpose. However, I say that without judgment; it's your game. On the other hand, it's also your stranded crew.