Zhetaan

Hello! It's good to see that you're not giving up. I don't know whether this will make you feel any better, but consider this: you got the game for forty dollars; NASA had to figure this stuff out, when corrected for inflation, at over seven hundred million dollars per launch (and with no quicksaves, either!). I looked at the image you posted: I have some advice for your next step: Keep in mind that there's no hurry; it costs nothing to take things slowly, because KSP rewards you for doing things correctly, not quickly. I don't know how much of a gamer you are, but I've noticed that a lot (perhaps most) of the frustration faced by more casual gamers trying to play KSP is caused by the fact that video games prefer to increase the difficulty by requiring you to perform tasks more quickly or with more precise timing--see, for example, the speedrun as a demonstration of skill. That kind of thinking won't work here; KSP has very few situations that require quick reactions. Instead, it presents the difficulty exactly as it is, and does not forgive you for making mistakes. It's definitely an adjustment. Remember that your camera view is two-dimensional and there's no sense of three-dimensional perspective, so once you have your docking ports aligned, be certain to move the camera to see whether you're aligned in all directions. Also note that docking ports work best at a closing velocity of less than three tenths of a metre per second--that's .3 m/s or point three. If you find that the station is drifting away from you, then remember that when you put the navball in Target mode, your prograde and retrograde markers show the direction of your relative velocity to the station. This means that you can zero your velocity with a retrograde burn to stop the drift (though at this range, you're better off using RCS thrusters instead; you don't want to burn off parts of your station!). You'll never make the drift exactly zero, but you can reduce it enough to give yourself time to dock. If you find the station's docking port rotating away from you every time you get it lined up to your ship's port, that's because you're in a low-enough orbit that the curve of it is causing fast-enough relative rotation to cause a misalignment before you can close and dock. To fix that, point the station's port in the normal direction and dock with it that way. Good luck!

DeepFreeze has a compatibility issue with Kerbalism. Don't forget to uncheck the 'Use Background Processing' option in the difficulty settings, or else you'll have problems.

I'll admit to a bit of confusion about what you're asking, but I'll try my best: If you mean previous versions of KSP, you have to have downloaded it. Usually, SQUAD makes the most recent previous version available at the KSP store; if you're on Steam, you need to find the previous version and move it out of the Steam directory before Steam updates it. However, current saves are usually not backwards-compatible. If you mean previous versions of a mod, then the mod-makers usually have older, archived versions at the same place that they offer the current version for download. It's much easier to get older versions of mods than it is to get older versions of KSP. However, again, older versions of mods may not work with the current version of KSP and they may be save-breaking in the event that you are currently using the updated version. If you mean going to previous saves, then you need to have an older save. The game backs up your last few autosaves (you can find the backup directory in your save directory, wherever you have KSP installed). Loading the older save has the effect of going back in time, and saving it will overwrite your newer progress. You need both a planet pack and a mod that can process planet packs. The current standard for processor mods is Kopernicus; as for planet packs, you have your choice. Note that Kopernicus tends to lag a version behind the current release of KSP, so if you want to use it, then you'll need to get the most recent previous version of KSP to go with it. If none of the available planet packs pique your interest, then you may try your hand at making your own. So far, the most popular planet packs include Outer Planets Mod, which is exactly what it says; Real Solar System, which again is exactly what it says it is; Galileo's Planet Pack, which completely reconfigures the solar system (and not just in the sense of moving the planets to new orbits; it replaces the stock solar system with a totally different one), and a few others, such as rescale mods (they change the size of the solar system to be closer to what it would be in reality, but without going so far as to replace it with the actual Real Solar System--although there is a Toy Scale mod that actually makes things smaller). Removal consists of removing the planet pack, but I'll caution you against doing so--if you add a planet pack, then you should probably keep it for the duration of the save. If you put anything on or in orbit of a mod planet or moon, then removal of that body will cause problems. Any remaining hardware or Kerbals left there will suddenly consider themselves to be in orbit of something that no longer exists, and I honestly don't know what will happen to experience logs, the science archive, or the contract system for anyone or anything back at Kerbin if they begin looking for references to planets that simply disappeared. Adding planet packs to an existing save can cause similar havoc (celestial bodies are given numeric identifiers, and when a rocket in low orbit of the Mun suddenly finds itself orbiting inside a rescaled Mun, or in the atmosphere of a completely new planet that reuses the number, hilarity does not usually ensue), with the exception that planet packs that solely add new planets and do not change existing ones are sometimes safe (Outer Planets Mod is mostly designed this way; I don't know what happens should you install it while you have anything at Eeloo, though). Yes. Some mods are not compatible with other mods; this is because they try to change the same aspects of the game in ways that conflict. A lot of mods are dependent on specific versions of the game; the mod makers do try to keep up with the new releases, but it takes time. Planet packs and Kopernicus are especially dependent; it turns out that the solar system is a core part of the game and thus things that modify it are often specific to that individual release. Some mods have bugs that may very well interfere with what you want to do (this is usually the result of a previously-unconsidered edge case or a previously-undiscovered incompatibility; sometimes, it can be addressed, and sometimes not). Mods are not necessarily optimised completely, and so they may induce lag and slow down the game. Mods that add a lot of processing or new physics can do this to the point of making the game unplayable, especially if you have a lot of memory-dependent mods installed at the same time. Mods that change the play style can derail a game in progress (for a simple example, imagine that you were to add a life support mod to a game that has a crewed vessel out near Jool; doing so will probably sentence that crew to die). I'm certain that there are other things to consider, and I'm equally certain that others will arrive shortly to add those parts. For now, this is a good beginning.

Much of the beginner challenge in rocket design is controlling drag. Most of what I have to say about that has been said, but I will add that for the most part, you don't need an experiment container. It can be helpful, but it is not necessary. Most of the experiments you're using either run once (such as the Science Jr.) or else give you all of the science points that you're going to get the first time they are run (such as crew reports and temperatures); when you run these experiments, you can take them out of the science modules and put the data in a suitable storage device. The science container is such a device, but so is the command pod. The difference is that the science container can pull data to itself for storage, whereas experiments have to be manually moved from their science parts to the command pod by a Kerbal. If you want to try that, then it is good for practising EVAs. Absolutely! Career mode involves managing a lot in addition to learning rocket science and can be overwhelming. Sandbox mode involves having more parts than you possibly need and no obvious way to tell which ones are best for which purpose. Each mode has its place and its use: Sandbox is great for testing, or for players who want to do interesting things in far-off places without wanting to build up to it, and Career is great for people who want to manage more of a challenge (especially in the early game, when you're much more limited in the size and mass of your rockets and the missions that you can complete--you need to unlock manoeuvre nodes and the ability to EVA, for example), but Science mode offers opportunities to learn the basics of how to play the game in a way that neither overwhelms you with parts nor with management tasks. Also, some players, even experienced ones, play Science mode exclusively as a matter of preference. Some of them simply like it the best. Some of them don't like the mechanics of career mode. The reasons don't matter: it's a single-player game, so play it as you like.

To extend (apologies for the pun; I couldn't resist) what @Gargamel and @steuben said, if you were not asking about building beyond the limits of the editor but instead asking about building in locations other than the KSC, then yes, it is possible. The Making History expansion offers access to alternate build locations on Kerbin, and the mod Extraplanetary Launchpads allows you to build anywhere that you set up the infrastructure. I'd recommend against using ELP as a beginner; it is not a beginner mod. I'm not the one you addressed, but I can answer that, too. Docking ports are connectors that allow you to join two vessels together. This is useful for assembling large space stations or other vessels in orbit (from smaller, easier-to-launch parts), or for Apollo-style missions where the lander is a separate vehicle from the main engine. It is usually done in space (or, for the Apollo-style missions, you can pre-assemble the vessel in the editor) and it requires that: Both vessels be equipped with a docking port, Both docking ports be the same size, Both docking ports be installed correctly (you can accidentally put them on backwards), You have some decent piloting skill, patience, and a hand for fine manoeuvring. As a beginner, it's not something that you'll need to do for some time yet.

Perhaps they're hiding because of the insult. On a serious note, I agree with He Who Was Once 5thHorseman: that's an unconscionably silly UI decision. I think I'll throw some feedback into the bugtracker about it. Edited to say that 25319 is now on the tracker.

Welcome to our little club! I can't tell you a lot without more details (as others have said), but if you have insufficient fuel, then the problem is going to be one of two things: either you need more skill at flying the rocket or you need a better rocket design. 'Skill at flying' does not necessarily mean controlling the rocket during a burn, but can also extend to navigation and planning for your manoeuvres. If we knew the design of your rocket, then it would be easy to tell which is the problem; if you have a rocket that is capable of reaching the Mun but you can't seem to get it there, then we can help with that. On the other hand, if your rocket is not capable of reaching the Mun, then it really doesn't matter how much skill you have or lack--but we can help with that, too.

From the wiki, Minmus has an argument of periapsis of 38° and a mean anomaly at zero of .9 radians exactly. The argument of periapsis is measured from the ascending node, in the direction of motion, and centred on the primary, whereas the mean anomaly is measured about the centre of the ellipse (it's technically a circle for mean anomaly, but the centres coincide), so for most cases, you'd need Kepler's equation to translate between the two. However, Minmus's orbit is circular; there is no difference between the mean anomaly and the true anomaly. It's not a complete simplification, but it is made astronomically easier, to use exactly the right metaphor. Since true anomaly conventionally measures from the periapsis at zero, but argument of periapsis conventionally measures from the ascending node at zero, the first thing to do is to convert the argument of periapsis into a true anomaly of the ascending node, which in this case would be 360° - 38° = 322°. The descending node is 180° away from that or at 142°. Conversion of .9 radians to degrees gives a mean anomaly for Minmus of 51.57° at time t = 0 seconds. Minmus's orbital period (we want the sidereal period, not the synodic period) is 1,077,311 seconds, so from t = 0 to the descending node is equivalent to the time to travel 142° - 51.57° = 90.43°, which is (90.43° / 360°) * 1077311 = 270614.5 seconds, or 12 days, 3 hours, 10 minutes, and 14.5 seconds. After that, Minmus passes through a node every 24 days, 5 hours, 37 minutes, and 35.5 seconds.

Undocking should not be so energetic; even decouplers and separators of proper size should not cause explosions when releasing the rover on the ground. Typically, such destructive force is caused by part clipping issues. Part clipping occurs when two parts occupy the same space; normally, it isn't a problem for two parts on the same vessel, because KSP ignores the case where a vessel collides with itself (this is necessary to keep the vessel in one piece), but as soon as you undock, you have two vessels that can collide with one another. KSP's physics responds to collisions with a repulsive force, and in the case of a part intersection, that force becomes enormous. You can check in the VAB to see some possible part clipping issues, but one way to tell is to launch a test vehicle into orbit and to try undocking the rover there. Have a quickload ready; there's no need to waste game resources for bug testing. If the rover shoots away at high speed or explodes, then you likely have a clipping problem and will need to redesign to eliminate that problem. It's not definitive--you may have a clipping issue that only appears when the landing leg settles under gravity, for example--but if the rover does shoot away, then it's a true positive. For example, you can rearrange your lander so to eliminate a landing leg (tripods are perfectly stable provided that they are properly under the centre of mass) and put your rover in the free space thus created. Another possibility is to turn your science station into something more resembling a skycrane by moving the Thud engines outwards and the rover towards the centre. Yet another possibility is to move your return capsule to the side (atop one of the Science Jr. modules) and to move the rover to the other side, for balance. Since both the rover and the return capsule will decouple, it won't even ruin the overall aesthetic. Driving off of the top of the science station to an intact landing may be an act better reserved for Minmus than the Mun, though.

At the very start, your main goals are altitude-based, meaning that so long as you can find up, you can find the correct direction. It very quickly moves to reaching space, and after that goes to staying in space, for which there are numerous tutorials (including in-game ones) to help you. If you're talking about missions to conduct studies at specific places and altitudes for science, then I should warn you that most people find them easier to complete with aeroplanes rather than rockets--not that aeroplanes are easy, of course--and requires a completely different set of skills. Trying to do it with a ballistic rocket is an exercise in frustration; it's solvable (with the same techniques used by launch planners during the Cold War, in fact) but you may stop having fun before you figure it out. If, on the other hand, you are attempting to reach specific locations on the surface, then it is still difficult but I think I can help you. You may find it easier to launch to a polar orbit and then try for a precision landing. Polar orbit is good for that because over the course of an in-game day, you will pass over most or all of Kerbin's surface. That makes it possible to land anywhere on the planet, so provided that you have a rocket capable of getting to polar orbit, that rocket can land anywhere on Kerbin. Thus, you no longer need to design different rockets with different amounts of fuel for different ranges; a single model goes anywhere on the planet. Since it's roughly the same distance to the surface from any point at low orbit altitude (approximately 75 - 80 km, and your surface altitude runs from sea level to about ten percent of that), the key to precise landings is repetition. Use the same type of rocket and learn a standard ascent profile so that you can reach a consistent orbit with a consistent amount of fuel. Then always deorbit the same way: use the same amount of fuel and thrust, and always decouple your engine and fuel tank at the same time. Always open your parachutes at the same time (you can adjust the settings so that they open at a predetermined altitude and pressure after you arm them). Pick a target on the surface and try to land on it. If you miss, then you can gauge and correct the error and try again. Quicksaves and quickloads are a tremendous help with this. Determining the correct direction for a rocket launch generally divides into three possibilities: You're launching to what we may call a 'standard' equatorial orbit, which requires you to pitch east after launch. This is the 90-degree direction on the navball (learning to read a three-dimensional compass is a new skill in itself). You're launching to a polar orbit, which requires you to pitch either north or south (it doesn't usually matter which) and, after you get some experience, slightly west in order to refine the orbit. This is either the 0-degree or the 180-degree direction. You're launching to a retrograde orbit (this is normally only required for satellite orbit contracts where the target orbit is retrograde) and requires you to launch west, which is the 270-degree direction on the navball. There are other cases that will arise under special circumstances and as you advance in skill, but these are usually for very specific purposes. Keep in mind that a coordinate system is useless without a basis of reference (the KSC isn't necessarily at 0°N, 0°E), and even one with a basis becomes useless once you leave the sphere of influence (Kerbin-centric coordinates make no sense at Minmus and even less sense at Jool). That doesn't touch the problem of things being in orbit also being in motion.

Congratulations; you've discovered an edge case! One thing to remember is that your orbit about the Mun is fixed with reference to the stars, not the Mun or Kerbin. The Mun still rotates (albeit slowly) under you, and it still orbits Kerbin, so yes, this absolutely will happen. You're at a point where you need to consider your departure almost as a transfer window, and set your node in such a way that will have you leaving the Mun in a retrograde direction at the point that you arrive there. This is somewhat more involved than typical interplanetary transfers because in the grand scheme, while Kerbin doesn't move much over the several days it takes to escape to interplanetary space, the Mun's six-day year-equivalent is fast. Therefore, you need to visualise your position and path, not only with respect to your position and motion about the Mun, but also with respect to your motion about Kerbin. The best way I can think to illustrate your problem is this: you have to remember that if your ship is orbiting the Mun and the Mun is orbiting Kerbin, then you're orbiting Kerbin, too, albeit in an extended-family sort of way. If you were to graph your position with respect to Kerbin rather than the Mun, then you'd see that the orbit always appears to be a variation of the Mun's own orbit. It depends a bit on whether your orbit is polar or equatorial, but the variation will be some sort of helix or spiral (or a combination of the two). Eccentricity also plays a role and changes the character of the spiral, but the point is that if you were to look at your vessel from a top-down perspective focused on Kerbin's north pole, then your vessel's orbital track would usually appear to be some attempt at Spirograph in space. As your semimajor axis extends farther and farther out and away from the Mun, the orbit changes. Let's assume for a moment that the Mun is intangible; that is to say, you won't crash into its surface and may set your vessel exactly at the Mun's centre of mass or otherwise orbit arbitrarily close. At the exact centre, your vessel's orbit is equivalent to the Mun's orbit. Very close to the centre, the orbit is still mostly circular with a tiny bit of periodicity--or, should you be unfamiliar with that term, 'wobble'. As you get closer and closer to the boundary of the sphere of influence, your orbital track 'expands' to fill the volume of the Mun's sphere of influence as it traces a toroid (that is a shape like to an inner tube or a doughnut) about Kerbin. See the attached image for a visual example: The red track is the closest orbit, the blue track is in the middle, and the green track is the outermost. Note that the path 'expands' in both directions; so does the sphere of influence extend to points inside the orbit as well as outside. All three tracks are nonetheless centred on the same orbit circle, and in KSP, this circle would be traced by the Mun's centre of mass. Eventually, you simply leave the Mun's sphere of influence, but because you're so close to escape velocity at that point anyway, your resulting orbit is essentially (not completely!) co-orbital, which is to say that your orbit is equivalent to the Mun's, but not in orbit of the Mun--which is exactly what you would expect for a vessel that orbits at the Mun's altitude with enough energy to remain there, but is not gravitationally bound to the Mun itself. The resulting orbital track, then, is eccentric with a periapsis somewhere on the circle traced by the innermost point of the Mun's sphere of influence, and the apoapsis, in like fashion, at the outermost point. This is the difference between orbiting freely and getting captured into Mun orbit: when you execute a Hohmann or other transfer to get to the Mun's altitude and enter its sphere of influence, you initially have enough energy that, without a second manoeuvre, you will eject from the Mun's sphere just as quickly as you entered--albeit in a different direction, which is the essence of a gravity assist. When you make your capture burn, you lose energy with respect to the Mun--that's how you get captured--but you gain energy with respect to Kerbin, because from Kerbin's perspective, you are remaining in a higher orbit. By increasing your orbital altitude to the limits of the Mun's sphere of influence, you gain energy with respect to the Mun, but because you remain gravitationally bound to it, your energy with respect to Kerbin doesn't change appreciably; it only varies between increasing extremes. In that respect, you've already wasted the fuel. To efficiently return to Kerbin, it would be best to dive towards the Mun's surface and set up the burn so that you can make use of the Oberth effect. Again, this is for reasons that are more commonly encountered when making interplanetary transfers, but the point is that no one makes an effecient interplanetary burn from the edge of Kerbin's sphere of influence. Sometimes, people will burn for a high apoapsis and then escape at the next periapsis, but that's it.

It appears that you are trying to use a rocket to deliver the satellite as a payload, but still be able to control the rocket after delivery. That's certainly possible, and sometimes people will do something similar with robotic rovers or atmospheric probes for Jool where they can have a pilot safely in the main rocket to control the probe, and the probe take the risk of crashing or burning up. Apollo-style missions are a crewed version of the same thing. People often use either expendable rockets to deliver satellites to orbit (as in real life), or they use reusable spaceplanes to complete missions that are more like yours, but one case where your mission plan is very useful is when delivering multiple satellites to similar orbits in a single launch, as is the case with communications satellite constellations. In that case, the satellites are stacked onto the rocket and released one at a time. Usually, the main rocket is also independently controllable (so it can be moved out of the way and avoid crashes). You'll find a number of possibilities if you search for terms such as comsat constellations or single-launch networks. If that is a bit more than you are ready to try, then the easiest way to get started is to take a crewed rocket that you know can fly to orbit (preferably one with a Mk1 Command Pod), and instead of a nose parachute, attach a .625-metre decoupler or stack separator (the TD-06 or TS-06) and put your satellite on top of that. You'll almost certainly need to include a fairing (that's the AE-FF2 Airstream Protective Shell), and it ought to be attached to the 1.25-metre main stack (that's the size of the bottom of the command pod). I suggest adding a decoupler to the bottom of the heat shield if there isn't one there already (the TD-12) and the AE-FF2 underneath that. If you're not familiar with fairings, then that's a different tutorial. The important things to remember are that, first, the satellite needs to have a probe core in order to be controllable, second, if it has an engine, then you need to be absolutely certain of the staging order, third, you're adding mass, so you may need to strap some solid rocket boosters or other additional engines to your rocket, and fourth, you don't have a nose parachute, so you'll need to add radial parachutes to the Mk1 Command Pod to retrieve the crew safely. If you find that this doesn't help, then I can direct you to a few builder tutorials that offer more information on the subject. Some are out of date, but there are some very comprehensive ones out there.

Carefully. In seriousness, it is possible to have accurate parachute landings provided that you can slow your reentry to safe deployment speeds consistently and repeatedly. This is somewhat like booster and pod recovery at the KSC, but it is more somewhat more difficult than Kerbin because Laythe's atmosphere is different enough from Kerbin's that your intuition will be off. Eve and Duna aren't good trainers, either, because Duna's atmosphere is negligible, and Eve's requires special handling at the best of times. For practical purposes, you're likely best off with a combination that includes propulsive landing, as @AHHans suggests.

There is! Put this in a text file, save it as a .cfg (call it something like RTImprovedCommand.cfg), and drop it in your GameData directory: @PART[probeCoreOcto2]:AFTER[RemoteTech] { %MODULE[ModuleSPU] { %IsRTCommandStation = true %RTCommandMinCrew = 1 } } I have not yet tested this, but the intent is that this patch will make the Octo-2 probe core a command-capable part with a requirement of one kerbal. Your probes will work just fine, but so long as this part and a kerbal are on the same vessel, you'll have no signal delay for other nearby vessels. I know of no way to set it so that it cannot control a vessel outside of a limited radius, so if you're using a relay network, then you'll be able to control vessels on the other side of the system with this provided that it's closer than KSC. What this means for you is that your one-kerbal rocket with an Octo-2 at Duna will be controlling your Jool probes half of the time. I think that part of the original rationale behind the current system was that since any core with command capability would operate as a command centre regardless of the intended use, the more realistic interpretation of that would be to require it to operate as a command centre and sacrifice the smaller operations. It's up to you to choose whether to abuse the functionality. Also, feel free to alter this as necessary for your purposes. If you want to set it to two kerbals, then it ought to be fairly apparent how to do that, but as always, if you require any help, then please feel free to ask. Oh--for the required disclosures, this was adapted from RemoteTech code which is licensed with GNU GPL 2.0, and the licence and original source code can be found here.

That is also to be expected. The only way for you to have and to maintain zero relative velocity is to be in exactly the same orbit as your target. The obvious solution to that is to be physically connected to the target as in the case of docking, but if you had an orbit that was identical in every way except that you were in a different place on it, then it would remain at zero in that case, too. However, that also would mean that you would maintain that separation, whatever its value (even if it were zero, again as in the case of docking), and once you began to approach, you'd again be subject to this orbital drift. There are tricks to minimise the drift, but they vary in helpfulness with your proximity to your target. For example, if you are approaching the target from behind, as you would if descending from a higher orbit, then aligning your orbital prograde marker () with your target marker () will help to ensure that when you zero your target-relative velocity, you will be in nearly the same orbit. However, that only works when you are very close to your target, and even then is an approximation subject to eventual drift. On the other hand, the drift is periodic; provided that you and the target have the same orbital period, you will always return to the same relative position no matter how far you drift, and you will do this reliably on every orbit. The other common trick to avoid orbital drift, and this works when approaching from any direction, is to close quickly, but incrementally. The idea is that as you make successive approaches, correcting the drift can be done with the braking burn. To do it in KSP, zero your relative velocity, burn towards your target (), and then, while keeping the navball in target mode, set SAS to retrograde (). Do not under any circumstances orient your vessel to antitarget (). When you achieve your desired separation (closer is better--until you crash, so don't get that close), burn retrograde to re-zero the relative velocity. This solves for both your excess speed and the accumulated drift in one burn. So long as you are within physics range (that's somewhere between two and three kilometres), you can zero your relative velocity, point towards your target, and burn. A rendezvous burn from two thousand metres may drift enough that you completely miss the target by a hundred metres or more--especially in a low or fast orbit. In that case, brake at your point of closest approach (using the navball's relative velocity readout and retrograde marker for the speed and direction, and the map view's target distance readout for range) and do it again. It wastes a bit of fuel, but that bit of fuel is from an aptly-named manoeuvring reserve. Docking is not about conserving fuel; it's about conserving rocket parts. Since you can reliably get to within four hundred metres, you will have a much easier time of it. This drift is the reason why nearly every docking tutorial begins with a review of rendezvous; when you are more than a few tens of metres from the target, any attempt to approach the target directly will result in enough drift that you will miss. This is a fundamental consequence of the way orbital mechanics works: they had the same problem with Gemini 4. The reason is because even though you begin dead in space relative to one another, you are both following curved trajectories around another body, and any difference in those trajectories will result in a variable relative velocity. If you were moving in a straight line, then pointing at the target and giving a tiny amount of impulse would always result in a dock, but you never are moving in a straight line when you are in orbit. This is the reason why docking is considered among the most difficult of skills to learn. But you can learn it; eventually, what is now awkward and frustrating will become second nature and intuitive.

@XLjedi has some good advice for you. However, not all mods are on CKAN, and CKAN won't help you choose which ones to use. Most mods can simply be copied into the Gamedata directory, which is in your KSP installation directory. Most mods also come with installation instructions (usually consisting of what I just told you) but some mods have special requirements. Install many at a time. If you have a slow processor or not much memory, you may have a problem with too many mods, but there are some players who routinely run more than 100 mods and have no trouble. Usually, the major problem with running many mods is that they sometimes try to make different changes to the same things, and that causes a conflict. The second most common problem with running a lot of mods is that you can't update very quickly when Squad releases a new version of KSP because you have to wait for all of the mods to update, too. Sometimes, mods are abandoned, and then @linuxgurugamer collects and updates them. That takes time, though. The best answer I can give you is: it's your game, so choose what you like. There are mods to increase realism (and a suite of mods collectively called Realism Overhaul that is built to that purpose). There are mods to decrease realism (Toy Solar System mods do this), and mods to completely replace the solar system with something else for new and different challenges (Galileo's Planet Pack does this). There are weapons mods for epic space battles if you want to have them. There are mods to increase the difficulty if you find the game too easy, or to extend it if you finish your tech tree too early or find that there are not enough planets for your liking. There are mods to tell you when you have upcoming manoeuvres for your rocket (such as Kerbal Alarm Clock), mods to increase the available information about your rocket as it flies (Kerbal Engineer), mods to make it fly more realistically through atmospheres (Ferram Aerospace Research), mods to fly it for you in case you want an autopilot (MechJeb), and even a mod for you to write your own autopilot in computer code and then have it fly the rocket for you (kOS). In all of that variety, you should decide what you want to do in KSP that you can't do in stock and then see whether there is a mod for that (I'll tell you in advance that there probably is). If you want a logistical and planning challenge for your Kerbals, then you should consider mods for life support. If you want a logistical and planning challenge for your rockets, then you should consider mods that modify the construction of rockets, or possibly a part failures mod. If you like gathering science, then you should consider a mods that extends that capability with new experiments and situations. If you like bases and resource management, then you should consider a colony mod. One of the large mod repositories is SpaceDock (I included a link). It has a number of different categories of mods, including lists of popular mods that you can browse. Not every mod is on SpaceDock, but many of the very good ones are. The Add-on Releases forum also has a library of mods; it's a sticky post near the top and also at this link. It's a more comprehensive list of what is available, but it does not sort by popularity because there is no way to track the number of downloads. You should look at the forum to see what the most active mods are right now and see whether anything piques your interest. The first three or four pages will tell you most of the most popular mods. However, there are, at current count, 140 pages of mod threads in the Add-on Releases forum. Some of these are repeats of old mods under new managers, and many are abandoned mods (for many different reasons; Fine Print, for example, was incorporated into the stock contract system, so it technically stopped being a mod in the purest sense of the term), but there are simply too many to give a good direction except to tell you what my preferences are and let you use that as a basis to determine your own preferences. For my part, I prefer mods that increase the difficulty and extend the game. I use Community Tech Tree, Outer Planets Mod, MKS (a colony and resource mod), the entire Near Future Technology suite, USI-LS (a life support mod that incorporates mental health in addition to food), Connected Living Spaces (it requires that your kerbals move through vessels in kerbal-sized corridors), Kerbal Construction Time (it makes rockets take time to build), kOS (the write-your-own-autopilot mod that I mentioned before), and about three dozen others that have the same general theme, plus all of the utilities and other mods necessary to keep these ones playing well together in the literal play-the-game-without-crashing-to-desktop sense. I also deliberately keep an old version of KSP with Kerbal Sports: Jebediah Kerman's Fishing Challenge, because fishing in KSP strikes and always has struck my sense of whimsy. In addition to all of that, I mod some files myself, such as reworking the large ISRU unit and fuel cells to be about 10% efficient compared to the stock versions, because I enjoy the logistical challenge that arises when you force KSP to more closely obey the laws of thermodynamics. It's most important for you to see what you would like and to try that. Also, I will warn you that it is best to prepare a new career save for mods because some mods can be very unkind to existing installs (don't install a life support mod when you have crewed vessels away from Kerbin). If you need any further advice, please don't hesitate to ask.

That depends on your order of visitation, vessel design, preferred return profile, and use of assists, among other things, but you can definitely do it with 17 km/s. I tend to completely overdo my delta-V budget because I'm usually looking to do other things, such as establish stations and bases, so I don't have a good number for you. Still, here's a link to a slightly outdated Jool-system delta-V map for your perusal and to aid with planning. The only inaccuracy I know of is that the Laythe entry data is wrong because this was made with the old aerodynamics model. However, that also means that it overestimates the needed delta-V by quite a lot (about 500 m/s if I recall correctly), so it shouldn't be a problem. Also, here's the current Jool-5 challenge thread. That may help, too.

I have a couple of ideas, but more importantly, I have a couple of solutions to go with them. I put them in spoilers because, in my search to give you a complete answer, I ended with four answers and would spare you an intimidating wall of text. I also have instructions on how to use the Docking Port Alignment Indicator and explanations for what each of the indicators means. You mentioned that you are in orbit of Minmus. I don't know your altitude, but typical Minmus low orbit is between ten and twenty kilometres, which gives orbital periods between approximately forty-five minutes and one hour. That is not quite so fast as low Kerbin orbit, but it still means between six and eight degrees per minute. When you set a vessel's SAS to stability assist (what you called 'set position'), it fixes the orientation in a non-rotating reference frame. The problem is that orbit, at least from the perspective of a vessel in orbit, is not a non-rotating reference frame. During each orbit, the vessel will hold its orientation fixed relative to the stars, but because you are in orbit, it will appear to rotate away from you relative to your perception of directions such as down. The reality is that the direction of down changes (relative to that non-rotating reference frame), but you're trained to assume that it doesn't (by your lifetime of experience with down being a reliable direction and likely equivalent experience of not standing on your head), and what you are seeing as an unhelpful rotation is in fact related to the rate of change of down. That's the problem--or, I should say, that is what I believe to be the most likely problem given what you have said so far. Here's my first solution: For a second solution: For a third solution: For a fourth solution: Lastly, I will warn you that Docking Port Alignment Indicator, while an informative tool, also presents a lot of information in a small window and can be difficult to interpret without experience. There are many different indicators in the main window and they are all related to one another, but they tell different things. I hope that helps. If it doesn't, then please feel free to return. We're all interested in helping players have fun and avoid unnecessary frustrations. Good luck!

Technically, it's asymptotic, which means that the closer you get to 100%, the more difficult it is to get even closer yet to 100%, with the end result that you will never reach 100%. It's much like how it is not possible for an object with mass to pass or even reach the speed of light in reality.

They are close but not equivalent. A line of right ascension is the celestial equivalent to lines of longitude, and thus there is a relationship to longitude in the same sense as the longitude of ascending node. However, right ascension is specifically defined for celestial observations made from Earth (it uses a particular point in Earth's sky as a sort of 'east pole' and would need a different definition for observations made from different places) and is more useful for locating fixed points in the sky as seen by an observer on the ground, whereas longitude of ascending node is specific to objects in orbit of something and is determined without respect to an observer's location. In other words, one uses right ascension to locate a point on the face of the sky, and one uses longitude of ascending node to locate an orbit, which is not a point. In this case, an object in polar orbit will always have one of two right ascensions: when travelling from the north to the south pole, it will have one value, and when travelling from the south to the north pole, it will have the supplement to that value.

You need a second Eve assist; one won't normally lower your periapsis enough. The trick to K-E-E-M trajectories is to use the first Eve assist to set the exact correct time for the second. Eve's orbital period is 65.5 days, so you need a solar orbit with that period exactly; you can afford a bit of error margin on the Kerbin and Moho ends of the path. There's one path that begins at Kerbin on day 162, flies past Eve on day 210.6 and again on 276.1, and finally reaches Moho on day 296.1.

@AHHans's suggestions are all good ones, and I will add that, considering the amount of effort that you're putting into it, you can also build a mobile launcher into a rover and simply drive to the equator. For my part, my preference would be to get them to the same orbit in space and then make my adjustments once there, thus eliminating the persistent imperfections of the planet and my launch location.

As @Stamp20 mentioned, there are only two ways to have inventories, and neither are on the stock 1.9 game: you need to have the Breaking Ground expansion, or you need a mod that includes inventories. Kerbal Inventory System is the obvious one, but there are others. Either way, inventories are not part of the base game.

Below and to the right of your first post (and the first posts of all questions in the Gameplay Questions forum), between it and the first reply, is a button that says, 'Sort by Date'. This control will arrange replies by time posted rather than by number of upvotes. There was some discussion about this some time ago, but the forum administrators decided against making 'Sort by Date' the default. That said, I would not mind a user-level setting to change the default for myself, but I suspect that that would require more work to implement than it is worth. For my part, I've gotten to the point that my first action in any Gameplay thread is to click that button from habit.

You are absolutely correct, and this is a good thing to bring up in the Bug Tracker should you feel strongly enough about it to make the suggestion to the developers. Another idea is to suggest that the developers make the contracts do a better job of communicating their requirements: i.e., the contract needs to explicitly state that you must return the capsule rather than the kerbal. You can also use a mod that lets you take more sensible contracts. I tend to the idea that it ought to either track the kerbals or require direct evidence of a landing, such as a surface sample, but I prefer to mod the contract system to correct the issue.