Zhetaan

There's no specific game mode for that; however, a combination of MechJeb and kOS would work for that. The combination is not truly necessary: if you are a sufficiently inventive coder, then kOS on its own can do everything that MechJeb can do. Since you ask specifically about launch and turning, I believe that there are no truly automated launches; at the least, you are going to need to press space or otherwise tell it to start. The game requires user input for that (probably because Squad thought the pun was funny--I'm surprised that you don't begin your descent into the atmosphere by pressing enter). After that, though, there are fully-automated missions. It's ancient enough to nearly be a fossil, but this is an automated mission to Duna and Ike using kOS. I offer it for informational purposes only; both the game and the mod have changed enough that this cannot be taken as a tutorial. However, there are also fully hands-off missions that are not necessarily automated, either. With the right design, you can have a rocket that, once you ignite it, launches itself to stable orbit without any further input from anything, whether it be you or an autopilot. There are more resources for that than there are for automated missions (mainly because a rocket that launches itself to orbit using stock parts is more universally applicable than a script to launch your rocket, or any specific rocket, to orbit). If you have the Making History DLC, then you should know that it includes a Mission Builder that you can use to set requirements and parameters, and while it will not fly those missions for you, it could potentially be a help and a guide for you to lay out your mission plan. Of course, pencil and paper work for that, too, as they always have.

I have some: post pictures.

I'd like to chime in and say that I appreciate the attention to detail, so thanks for that. I am curious, though, about the decision to make EVA propellant equal to 5 kg/unit in density. There has been a long-standing fan idea that EVA fuel, in function if not in its exact formulation, is some variation of monopropellant (and there are a few mods that make this relationship explicit), so I am a little surprised to see that you've chosen to give it the same density as the bipropellant mix rather than the 4 kg/unit of monopropellant. That being said, I have not looked too deeply into the legacy system, and so if it turns out that EVA propellant has always been treated as though it had an assumed 5 kg/unit density (whether or not the mass was actually accounted), then I suppose my surprise is borne of ignorance. Either way, I am still curious about the reasoning that went into defining the density that you did, and would like to know: would it be possible for you to explain the rationale for that choice?

@Tristen Simon: I suppose that this is technically a gameplay question, though don't be surprised should you you find this moved to KSP Discussion. Anyway, I typically go in for tongue-planted-firmly-in-cheek puns, metaphors, and allusions in my mission/vessel names. My first space station, which is normally early enough that it is actually functionally useless--but nevertheless often provides good contract opportunities--is almost always called Bridge to Anywhere in reference both to the bridge in Alaska and the quote about getting to orbit being halfway to anywhere. I usually call my first Minmus lander the Ice Cream Sampler; later ones are Frozen Disappointment. Flybys are, after the Munshot series of rockets before them, called Minshot. Early Eve missions, of which the crewed type never involve a landing (I use life support mods and don't have effective means to supply an Eve base at the beginning) are Look But Don't Touch. I have a set of probe landers for Eve's surface that incorporate tiny rovers in a service bay that have all of the repeatable experiments (the Goo and such stay on the lander); these are named Way-Discoverer, Trail-Locator, and similar titles, with the rovers called things such as Honest Wanderer and Verified Traveller. They are arguably more appropriate to Duna, but, well, it's my game. Also, the rover that crashed on Duna is called the Dead Cat. The one that landed correctly with the repair parts to rescue it is called the Satisfaction. Moho is normally called some variation of Dedicated Masochism. Assemblies in orbit, if large enough, are also contenders for this distinction. I also play with Outer Planets Mod, so sending crewed missions all the way out to Plock necessitates some creative design--or a cryogenic freezer. The vessel class that carries one is called an iceliner, and the mission called the Corpsicle Express (with missions to nearer bodies as some variation of Zombie Queen), which are references to a short story by Larry Niven and also to a mission report by @Geschosskopf called the Outer Planets Traveling Circus; it's old but it's whimsical, and that suits me. I will typically send comm arrays in groups for either better coverage or to send to different bodies in the same local system (for example, one orbits Duna and another orbits Ike). Sometimes, I will use flotillas, but comsats are small enough that I just as often send them on a single transfer rocket with decouplers. The one that goes to Jool and its moons is called Actually Six Smaller Ships in a Trenchcoat. Rescue and repair missions are Put Back Together with Parts Left Over, and my large-capacity training/experience vessel for new Kerbals is called the Magic School Bus. Asteroid capture vessels are called Rocket with Real Rocks in It. I hope that helps, and if not, I hope it was good for a chuckle or two. Have fun!

Welcome to the forum! Thanks for stopping by. Generally, docking is best done slowly; you'll want to keep your closing velocity under .3 metres per second. Keeping it to .2 or even .1 is arguably better. If you're bumping hard enough that you need to start over, then you're going too fast. Mating docking ports is a subtle touch, not a smash-and-grab. This requires some finesse, but since you are able to get direct hits, I will assume that you have the aiming part of that finesse more or less figured out and need only to reduce speed. That being said, it is possible that you have a bug in one or the other of your ports where it fails to set a ready state for docking; the magnets only work when the port is in a ready state. Also, for future reference, the Advanced Grabbing Unit does require some speed for a good acquisition, but it operates on a different principle.

I can certainly appreciate running the numbers, though I think that the fact that you are also using this infrastructure to run rescue and part recovery contracts does confound the data somewhat. Regardless, I can also appreciate that what you are doing is working--I have reservations about saying whether any particular approach works 'best' but that's a separate discussion--so, put succinctly: good job! I do have a question for you: are you running any strategies, as well, or are these the raw, unadulterated numbers?

I'll offer some possibilities: If you want to staff your space program with more than a few Kerbals, then rescue contracts are a good way to go because they give you people and pay you for it, instead of the increasing-costs model for hiring in the Astronaut Complex. If you don't like the Kerbals that you rescue, then you can fire them and rescue others. There is also a refuelling mod called Kethane that uses a finite-resource model for refuelling, and you can stretch your supply with unwanted Kerbals and the KE-WAITNONOSTOP-01 Kerbal Unreconstitutionator ... though I suppose that's not polite to talk about. Part recovery and Kerbal recovery contracts can be made to work with some infrastructure by making use of vessels equipped with independently-controllable grabbing units and reentry gear. Launch the carrier--essentially a rack of decouple-able grabbing unit probes--once, and you have something standing by in orbit to recover however many pieces and Kerbals as you brought Klaws. I've personally seen these with the capacity for twelve, and that is definitely not the limit. Asteroid capture contracts result in refuelling depots, which extend the service life of whatever existing infrastructure you have--including the vessel that initially performed the capture. Should you perfect your SSTOs and reusable transfer craft (I know that that's probably some ways off since you're a new player), your space program can stop costing Funds entirely, except for those occasions that you need new rockets.

It's called the vis-viva equation: v2 = μ [(2 / r ) - (1 / a)] Where: v = your orbital velocity μ = the standard gravitational parameter of the body that you're orbiting (the body's mass times the universal gravitation constant--Kerbin's is 3.5316 x 1012 m3/s2) r = your current radial distance from the body (because of the way that KSP shows altitude, you need to add 600 kilometres--Kerbin's radius--to your sea-level altitude) a = the semi-major axis of your orbit (that is the sum of periapsis + apoapsis + Kerbin diameter all divided by 2) Comparing these is fairly straightforward: since you want the speed at 40 km, the radial distance is the same in all three, as is the gravitational parameter. For the semi-major axis, we can approximate it by saying that a return from a moon is equivalent to a return from Kerbin orbit at the altitude of the moon and use the moon's orbital altitude as the apoapsis for our semi-major axis calculation. 90,000 metre low Kerbin orbit: (90,000 + 40,000 + 1,200,000) / 2 = aLKO = 665,000 metres 12,000,000 metre Mun return: (12,000,000 + 40,000 + 1,200,000) / 2 = aMun = 6,620,000 metres 47,000,000 metre Minmus return: (47,000,000 + 40,000 + 1,200,000) / 2 = aMin = 24,120,000 metres And for the velocities: Low Kerbin Orbit: vLKO2 = 3.5316 x 1012 [(2 / 640,000) - (1 / 665,000)] vLKO2 = 3.5316 x 1012 (3.1260 x 10-6 - 1.503759 x 10-6) vLKO2 = 3.5316 x 1012 (1.6222 x 10-6) vLKO2 = 5.7290 x 106 vLKO = 2,393.5 m/s Mun Return: vMun2 = 3.5316 x 1012 [(2 / 640,000) - (1 / 6,620,000)] vMun2 = 3.5316 x 1012 (3.1260 x 10-6 - 1.510574 x 10-7) vMun2 = 3.5316 x 1012 (2.9749 x 10-6) vMun2 = 1.0506 x 107 vMun = 3241.3 m/s Minmus Return: vMin2 = 3.5316 x 1012 [(2 / 640,000) - (1 / 24,120,000)] vMin2 = 3.5316 x 1012 (3.1260 x 10-6 - 4.145937 x 10-8) vMin2 = 3.5316 x 1012 (3.0845 x 10-6) vMin2 = 1.0893 x 107 vMin = 3,300.5 m/s Therefore, considering the 2,393.5 m/s return from 90 km to be the baseline, a return from the Mun would be 847.8 m/s faster, and a return from Minmus would be 59.2 m/s faster than that, or 907 m/s faster than baseline. This should make sense; after a certain point, the apoapsis becomes some approximation of 'very far away' and tiny additions of delta-V change it dramatically, so the converse is true in that dramatic increases in apoapsis make only tiny changes to the velocity. Also keep in mind that your actual results will vary: you need to go through a lot of air to get to a 40 km periapsis.

A second, also important caveat in addition to what @Spricigo mentioned is that, as @bewing said, tourist contracts are best for quick money in the early game. Although it is possible to complete the tech tree without leaving the Kerbin system, from a contract and exploration point of view, that is still the early game. I generally don't consider it mid-game until I'm either conducting Duna/Eve missions or exploring asteroids, but of course I admit that there is no official word defining that--what is important to you is that I think you're still seeing good returns from your tourist contracts because the game has not yet decided to offer you the later contracts where the balance shifts. I don't know how you feel about mods, but if tourism infrastructure is something that you're dedicated to developing, then you should at least seriously consider Contract Configurator and its Tourism Plus contract pack. Even though you may not want to go that route, you should still at least look at the page for the Tourism Plus pack--that space hotel picture still impresses me nearly six years after it was posted; you may like it, too. If you find yourself letting contract offers run out rather than declining them, then you should disable the reputation penalty (which you can do in the difficulty settings, I believe). Mission Control only offers a limited number of contracts; it doesn't make sense to sit there warping to get out of contract offers that you don't want in order to avoid losing one point of reputation.

For me, that settles it: you have a drag problem. This is a good point to raise; you may want to set your LFO tanks to drain from the bottom-most to the top-most, since you have so many in the stack. However, I don't think it's central to your problem: if you're flipping at 350 m/s, then you're not draining enough of the propellant for its mass distribution to contribute much to the instability.

I don't have much to add, except to say that one thing that I did not notice (and if someone did say it above, then please accept my apologies) is that you get less drift when you are in a higher orbit. The orbits are larger, which means that the angular sweep over the same period of time (meaning the size of the angle in the orbit that you travel through during the operation, or, to be more technically accurate, the change in true anomaly) is less. Also, the orbital speed is lower, which reduces the sweep even more.

That is perfectly acceptable, and about in the middle of the range that people generally recommend for those starting out with this. Others have mentioned Kerbal Engineer, but your question asks for stock, so aside from the thrust-to-weight readout that is now stock, your other option is to calculate it by hand. That's not too difficult; KSP gives you the thrust values for each engine in the VAB. You'll want the (atm) value for launches, rather than the vacuum value. Add up the thrust of all of the engines that light in the first stage, and that's your total rocket thrust. I believe that the VAB has a rocket information readout that gives you that total, so you may want to use it. Now take the weight of the vessel, which is the fully-fuelled (wet) mass (also found in the VAB), multiplied by the acceleration due to gravity where you are, which is Kerbin sea level or 9.80665 m/s2. Divide the thrust by the weight, and you have the thrust-to-weight ratio. Keep in mind that the thrust-to-weight changes dynamically as you fly. As you rise out of the atmosphere, your thrust increases and your weight decreases; both of these changes drive your thrust-to-weight up. Once you get an appreciable fraction of the way to orbit, thrust-to-weight ceases to be so important; your second stage, for example, can even have less than 1 and still make orbit provided that you get enough horizontal velocity from your first stage. Drag is much more dynamic than thrust-to-weight. There's a reason the field of study is called aerodynamics, after all. What this means for you is that you can't calculate it. Drag is dependent on more factors than you can access, and so your only option is to rely on a mod that calculates or reports it for you. Yes, it can be done (the game does it, after all), but this is one of those things that really relies on the computer part of your gaming machine. I encourage you to do so, but you should know that it is not for the fainthearted; aerodynamics is one area of physics where we have persistent unsolved problems (turbulence in particular; some physicists think we'll have a Grand Unified Theory of Everything before we solve turbulence). I will warn you that if you get very far into it, then you're going to find a lot more places where KSP uses approximations and other shortcuts to avoid the realities of just how complex aerodynamics really is. Realistically speaking, you don't need to know aerodynamics to understand the basic principles at work here. 'Pointy rockets work better' is often the overall design principle, and that works just fine in KSP (also in reality; look at a few pictures of the Mercury-Redstone, Gemini-Titan, and Apollo-Saturn rockets, and you'll see just how much the Space Shuttle is an aberrant weirdo in the American space program--but even the Shuttle has pointy parts). The main concerns to keep in mind are that you want to concentrate your drag and your thrust behind your mass. This is sometimes difficult to do because fairings are somewhat draggy and engines are heavy, but the solutions to that are fins and payload. It helps to keep your payload near to the same diameter as the rocket under it, too, so don't have giant fairing balls on top of spindly rockets. There are exceptions to this principle, which you will encounter if and when you ever decide to try your hand at spaceplanes (see above re: Space Shuttle), but for traditional pointy-bit-goes-up rockets, it'll serve you in good stead. Good luck!

There's also the Mammoth, which is actually four Vectors in a trenchcoat.

Oh, certainly. I don't think that the Principia people guarantee the long-term stability of the system. I know that they needed to make a lot of adjustments just to keep it stable in the short term, but insofar as total system longevity is concerned, well, suffice it to say that the KSP solar system was never designed to be realistic. I think that the design paradigm is essentially to establish a system that is pseudo-stable for a long-enough period of time to avoid unmitigated chaos during a typical career save. On the other hand, realistic or not, if you run enough mods then your computer's CPU can simulate the heat death of the Kerbal universe on its own.

Try this and see what you think. It's not exactly a step-by-step guide, but it does a decent job of both elucidating the theory and examining the extent of the possible solution space. There are several different kinds of cyclers, of which the Aldrin cycler is but one. I'll help you to begin: to even start establishing a cycler, you'll need the synodic period of the two bodies that you want to visit. Since Kerbin is its primary, the Mun has no synodic period with Kerbin and so a cycler between Kerbin and the Mun in the traditional sense is not possible. However, and with respect to others who have said that, there's nothing keeping you from establishing a cycler anyway. One way to do this is the take the degenerate case of the synodic period of a body with its primary: that's just the orbital period. You can establish an orbit that is some rational multiple of a Mun orbit, time it so that you don't lithobrake, and, so long as it is not thrown out of that orbit by Mun gravity, there you go. Resonant orbits are useful for all manner of things, and the cycler is simply a case of resonance extended to three bodies instead of two. Alternatively, and I suspect that this may be closer to your intent, you can establish a cycler between the Mun and something in Kerbin orbit that does have a synodic period with the Mun. It's doesn't need to be Minmus. You can put up a way-station, refuelling stop, heat shield, escape pod, funeral pyre, or nothing in some orbit of Kerbin and establish a cycler between that and the Mun. If your design is to set up an Aldrin cycler, then the starting orbit will have a minimum orbital altitude that is probably a bit above your typical low Kerbin orbit, owing to the fact that the cycler, with its eccentricity, will have a periapsis lower than the orbit you pick. Per usual, @Spricigo raises good points. The chief benefits of a cycler have to do with reusable habitation space, launch costs, and travel time--but only travel time in the sense of the wait between two adjacent 'stops' on the cycler line. Because the cycler is typically eccentric enough to extend out far past the target body, travel time on an outbound or inbound leg between the two points of interest is shorter--potentially much shorter--than it would be on a Hohmann transfer orbit. Once past that second point of interest and near the apoapsis, the time that the cycler craft spends out there is, ideally, while it is uninhabited (the crew departed to do experiments on Mars or what-have-you), and then the crew returns aboard for the relatively short journey home. Cyclers may not become necessary, per se, but they do begin to make a lot more sense when you run mods such as Kerbalism that simulate radiation, food and water requirements, and other health-related issues, because those mods both require and reward short trips with heavy radiation shielding. The heavy shielding is where I make my third point. @Spricigo is absolutely correct in saying that it takes more delta-V to operate a cycler. That was always going to be the case; it's not a Hohmann transfer or any of the other minimum-propellant transfer orbits. A cycler does not meet the target tangentially, and as such will never be the most efficient in terms of delta-V. However, a cycler takes advantage of the fact that there is another way to look at cost. Consider, for a moment, that you are sending a vessel to the Mun. It is a small, un-crewed probe of perhaps a half-tonne fully fuelled. How much delta-V does it take to go to the Mun from low Kerbin orbit? By the map, it will cost 860 m/s. Consider now that you are sending a one-megatonne station on the same orbit. How much delta-V will it cost then? Still, it will cost 860 m/s. But how much will it cost in tonnes of propellant and Funds? Well, that's another story. Let's get away from mods for a moment. Let's say that you want to send a full crew, and with the upcoming update, a few crates of spare parts, along with a mobile processing lab, a fuel processing plant, and because why not throw in the kitchen sink, a comm array that lets homesick Kerbals telephone their mothers. All of this needs to to go the Mun (for a certain highly subjective value of need, of course), but it doesn't need to stay there, which means that for the slightly increased cost of rendezvous for a low-mass lander or shuttle, you can send all of that equipment once and get repeated use out of it for so long as you want to use it, and you don't need to worry about braking burns or otherwise getting it safely to Mun orbit. You'd be best situated to set up a cycler that runs from the Mun to Minmus first, and then finding something resonant that runs from low Kerbin orbit to the Mun. It should be possible, but it may not be pretty. What you describe is likely only useful as a novelty, but I don't doubt that it can be done. You are; a cycler is a reusable rocket ship with extra steps. That's the point. In many ways, it's an elaboration of the more traditional method, for example sending a vessel that has been optimised to send lots of tourists to low orbit (and return them safely), meeting a transfer vessel there, and sending that to make rendezvous with an optimised lander in Mun orbit that can take those tourists to the surface (and return them safely, too). What you want to do is essentially to combine the transfer vessel with space stations at either end of the Mun transit leg into one craft that also allows you to take your SSTO (or whatever launch-to-orbit vessel you send) and lander along without needing to worry (much) about the extra propellant costs of sending all of that hardware on that journey. It's a perfectly valid way to do it, and it has the added benefit of being both a difficult challenge and elegant in its implementation when you get it right. Is it the most propellant-efficient way to do it? Not at all. Is it more cost-effective than sending single-use delivery rockets to get your reusable landers to Mun orbit? Quite possibly. Is it more fun? Try it and find out. True, but if you ever are intested in N-body physics, I leave you with this. That's not without controversy; there's a persistent rumour that he was taking pure oxygen and laxatives the entire time.

Since I am uncertain of what you have tried and what you've found to work or not work, I can only go by the information in the bug report: it appears that you have three choices for workarounds. First, you can eliminate the mass disparity between the vehicles, which might necessitate inert ballast on one of them. Second, you can redesign to eliminate robotic parts, since the problem appears to be isolated to designs with those parts. Third, you can redesign so that you can dock while your wheels are retracted. I don't like number one because it both complicates design and is tailored to exactly one situation in which you would use the rover, thus requiring a custom solution for every mass combination. That said, you could make it work by keeping the ISRU as a separate module and using the rover to haul both ore and propellant. You'd need to have a balanced transfer shuttle too, though, so it's a bit more complicated than just balancing the converter/power-plant against the mobile-drill/tanker, but provided that a drill rover with a full tank of ore masses the same as the ISRU plant, then the finished propellant will have the same mass as the ore. I don't think you'd like number two, since it puts you back in the position of needing to get exactly the same height and orientation, as you put it. For my part, I would choose number three and have the rover able to lower itself onto skids or a stationary cradle in preparation for docking. These can be incorporated into the rover's underbelly and made a part of the docking process. You may lose some utility as you're more likely to beach your rover when going over ridges and other rough terrain, so you'll need to consider it carefully, but you can justify it as having the rover assume a needful bracing position prior to a major mass transfer as would occur in offloading a tank full of ore or some such. If real cargo haulers need to 'block' their wheels, as it were, before moving mass around, then it's no loss for you to do the same.

As I understand it, there are three basic ways. First, get circular parts. There are a few mods out there that have single-part habitation rings and such; some of them even spin. It's obviously the low-creativity solution, but the advantage is that you don't have to worry about alignment or anything like that; so long as you can loft it to orbit, you get a ring station. Second, build a symmetric ring in the VAB, then send it to orbit. You should know that there are no ways to build rings in the stock game; it has to do with the 'tree' structure of the parts (the 'tree' system is also why the first part is called the 'root' part). What this means for you is that every part on your vessel has to have one path linking it back to the root; there can be many branches, but no rings in this system. This means that your rings are actually curved arms. However, there are ways around the limitation. The stock way is to clip a docking port in the end of each section so that they connect; docking ports work a little differently and so can create rings. The modded way is to use ReCoupler, which creates ring connections. This avoids docking ports (aside from the ones you want use for, you know, docking ships). The advantages are that you get good alignment usually right away, and for stability, you can use struts because it's all one vessel in the VAB; the disadvantages are that without docking port or ReCoupler connections, the station can be wobbly, and getting it to orbit in one piece can be unwieldy. Third, you can assemble the parts of the rings in pieces and send them to orbit individually. I'd strongly recommend a mod that either helps you with docking port alignment or else restricts docking ports so that they can only go together when they are aligned properly; otherwise your ring station begins to look like a mangled bicycle wheel. The advantage here is that you can send it up to orbit in manageable pieces, but you lose the assistance of struts to keep everything stable unless you have a mod that assists with that.

This appears to me to be a collision mesh problem. When you use the non-shrouded node, the parts clip ever-so-slightly into one another, and when you activate the separator, the now-two-vessels force themselves apart. You ought to consider submitting a bug report for it. P.S.: Nice signature!

PAS-22 was a case in which a satellite that was supposed to be launched into a geosynchronous orbit had a booster failure that made it impossible to reach the target orbit. The original owners scrapped the mission, the insurers declared it a total loss, and they sold all interest in it to another company that eventually decided to push farther to the moon and let a gravity assist adjust the orbit so that it could still reach geosynchronicity even with its reduced capability. It wasn't exactly asked for, but it did happen.

The launcher absolutely can maintain the alignment; it is instead choosing not to do so. @AHHans has the right of it; pay close attention to the attitude control needles in the lower left corner of the screen. They barely move; a rocket that tries and fails to overcome aerodynamic instability would have one or all of those needles hard against the edge of the gauge, indicating that even full-output control authority is not enough. Instead, to flesh out what @AHHans was telling you, is that after your first two stages burn out, your third stage has a much weaker (I assume vacuum-rated) engine that cannot push the apoapsis out far enough ahead of the rocket to keep the set time-to-apoapsis. Therefore, it has to make use of mathematical trickery and use some radial-out thrust to shift the orbit (and the apoapsis with it). Typically, this also lowers your periapsis, but since you're still in a powered ascent and the geometry of the orbit is right, the actual effect is only to slow the periapsis's rate of increase (that is only barely perceptible; although what your rocket is doing is inefficient, it's obviously not going to jeopardise the launch). If you want to stop this behaviour, then you're going to need a different time-to-apoapsis target that allows you to get a bit higher before your stage separation. Whether that means unlocking the finish time field or changing your launch profile completely, I don't know. I do notice that you're achieving orbit, unstable though it may be, at only 40,000 metres, which I admit that I don't prefer (I dislike risking that much atmospheric heating, and that goes more so for fighting drag losses the way I saw your rocket doing every few seconds), but your exceptionally flat ascent trajectory is a product of your high-powered initial launch stages. Your vacuum engine simply doesn't have the power to keep up at that altitude while also maintaining a fully prograde orientation, so it doesn't; another way of describing the radial-out burn is that it increases the eccentricity (at least in this case; it's not a fixed rule) and raises the apoapsis (and the ascent path) that way.

I should caution you that if you're starting from Kerbin, and this target is just outside of Kerbin orbit, then you may need to wait a prohibitively long time for a transfer window. The closer two objects are, the longer their synodic period, which is to say the time it takes for them to repeat their closest approach. It may be faster (albeit not cheaper, but sometimes, that's not the most important) to go into a phasing orbit with more frequent transfer windows.

Beyond Home has a list of dependencies that also need to be installed. You have to include Kopernicus and Parallax (click those for links to their respective download pages; forum threads for them are here and here) in order for it to work. Parallax does not appear to have any further dependencies, but Kopernicus does--although it also includes those dependencies as part of the download. I don't use CKAN personally, but I can say that it does keep track of all of the extra bits that you may need in terms of dependencies of dependencies, and so forth. Also keep in mind that GitHub releases are typically in the form of .ZIP files, and you will need to unzip them and put the unzipped files in your GameData directory for the mod to work. Also also, if the zipped download has a 'GameData' directory in it, then you need to put the contents into your own computer's GameData directory, rather than dragging and dropping the entire thing. Don't have nested GameData directories in your KSP install.

I don't know about 'better', but if you're willing to spend some time, then multiple gravity assist passes of Kerbin can raise your periapsis and lower your closing velocity to the point that the Mun can capture you into orbit.

@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!