Zhetaan

As I understand it (and while there is research on this, it's not exhaustive because people have found it so infuriating), the alarm signals the very beginning of a transfer window, not the optimum transfer time. The optimum transfer time is sometime later: in your case, apparently, that would be 29 days later. Since you already have MechJeb installed, I suggest using the transfer window planner that comes with it. I have generally found it to be accurate.

I know I'm late to the thread, but this is too good to pass up: Anyway, in the interests of offering something a little more on-topic, @SolMonster3318, if it helps at all, you should know that most people who play this game learn how to do rendezvous from doing rescue missions. It's become something of a meme, and though this won't tell you how to rescue your lost crew, I offer it in the hope that you can both laugh and appreciate that this sort of thing has been going on since the beginning. Keep at it, and soon enough, you'll not only know how to rescue your crews when things go wrong, but you'll also know enough about why and how they went wrong to keep them from happening in the future. Good luck!

Rough is correct, for reasons mentioned above. Terminal velocity is dependent not only on the characteristics of the atmosphere, but on the characteristics of the craft, and can change dramatically over the course of the flight (as a case-in-point, this is how parachutes work, though I admit that I do not know whether this is how their simulation works in the game). I can give you an explanation. That chart was an attempt to provide information that would be useful to players who had to work with few mods, few stock indicators, and a weird atmospheric model. None of those things is still true. It comes from this challenge: If you're not familiar with the Goddard problem, the short version is that it is an efficiency problem. The slightly longer version is that it is the question of how best to control a rocket to get the most altitude out of its propellant while taking into account the drag and atmospheric characteristics. It's of practical use because more efficient control means getting more out of a given load of propellant, but because of the reasons mentioned above, it's very specific to a particular rocket in a particular atmosphere. It's also only useful for a particular trajectory: straight up. Reaching maximum altitude is rather useless when the goal is to achieve orbit: the principles are different and the optimum solutions have almost nothing to do with one another. That being said, KSP is great for simulating these kinds of problems because it offers true reproducibility. It's also terrible for getting practical results from simulating these kinds of problems because it's not simulating other real concerns such as unavoidable variations in manufacturing the rocket, changing atmospheric conditions, or a fully-accurate aerodynamic model, among other things. However, at the time that it was made, that chart did provide some useful information. I'll provide details in the spoiler, mainly because it discusses completely outdated game mechanics and I don't want to create confusion. That being said, I think that this is actually a very interesting piece of KSP history, because this is from 2012 and people were still trying to figure out the mechanics of the game (and for a lot of them, spaceflight in general). Have a look at these cutting-edge graphics: Note the lack of lights, gear, and abort action groups. Also note that SAS was in the staging and had a finite capacity. Note the lack of info panels and KSPedia. Suffice it to say that there once was a time when people got to orbit by launching straight up and out of the atmosphere, then turning over and burning horizontally to make orbit ... hopefully before falling back into the atmosphere. At the time of this challenge, the atmospheric model was something like ten times more dense than what it ought to have been. Eventually, people settled on a hybrid approach to ascend in something (very) roughly approximating a gravity turn. What you see here is some of the experimentation that the players performed on their own to try to figure out those optimal ascent and control profiles. The terminal velocity table came from that. It worked at the time, so it made it into the wiki. After version 1.0 and the new model, someone noticed that a table of terminal velocities and altitudes no longer made sense for general use. It's not a matter of updating the table with new values for Eve: general values simply don't exist. An atmospheric density table would be nice, but density varies with temperature, which varies a lot with latitude and time of day, as well as altitude, so a table probably doesn't make much sense compared to an equation, or at least an algorithm. More pragmatically useful would be a list of good landing locations that combine high-altitude plateaus for launch with proximity to multiple biomes for research. Eve's rotation period is nearly four (Kerbin) days, so there isn't much to be gained from landing at the equator (55 m/s of eastwards rotational velocity instead of Kerbin's 175 m/s), but landing four kilometres above sea level is useful to avoid both the density and the heat of Eve's lower atmosphere. There is the idea that, given Eve's greater and more constraining challenges, the kinds of rockets needed to ascend from Eve's surface will be much more generally similar than the many and varied vehicles that come from Kerbin. In such a situation, you can make simplifying assumptions about the nature of these rockets to get a generally applicable range of solutions to the optimal ascent problem. However, those solutions are still dependent on the type of rocket, not on the planet itself, and so still wouldn't really fit on the wiki. But if you wanted to make a tutorial thread, however, then that would be a fantastic idea.

I'll toss one on: One of these mini-biomes becomes unavailable after you upgrade the building. The tier-2 VAB has a group of buildings called the VAB South Complex: The fun fact is that upgrading to tier-3 adds some new miniature biomes to the VAB, but removes the South Complex, which makes this the only natively permanently missable science content in the game. Everything else either remains available (as in the other biomes and World's Firsts rewards) or else is repeatable (as in contracts and asteroid science). Granted, available must be taken with a grain of salt, because I believe that would technically include such absurd situations as Landed on the Sun, but I believe that there was a quality pass a few years ago that finally removed that one from the list. Anyway, it doesn't amount to much, but it does serve to filter the unrepentant completionist players from the rest because they won't upgrade the VAB until they've unlocked. Every. Single. Science. Experiment. In the game and retrieved all of that delectable, collectible science from the South Complex before it goes away forever. Yes, this means grinding away without custom action groups until unlocking that elusive Tier-8 tech tree node for the silly gravioli detector. Good luck if you're using mods that add science experiments and science parts elsewhere in the tech tree.

You may be better off sticking to standard ports for traffic, Sr. ports for station expansion, and Jr. ports for nothing if you can avoid it. That's purely up to you, of course, but it reflects my usual procedure (it prevents confusion--I won't say that I've never used them and never will, but I do try to avoid it). You don't need that many of them, either. Let's say that you go with the full kit and eventually you have a dedicated transfer vehicle to go to the Mun, another to go to Minmus, an emergency re-entry vehicle to evacuate the crew to Kerbin, a passenger- and cargo-rated vehicle for surface-to-orbit-to-surface traffic, and an RCS docking tug for handling station expansion modules: that adds up to an extremely fancy and well-equipped station that needs only five docking ports, of which you're regularly using only two (Kerbin surface-launched traffic and a moon transfer vehicle), and at least two of which are for redundancies (emergency return and a second moon transfer vehicle). It might not be a bad idea to eliminate one ring of ports and move the solar panels to where the ports used to be just to better avoid trouble with collisions and the shadows of any docked vehicles. You've already said that you're not fond of docking, so I imagine that breaking solar panels while trying to dock would be extra frustrating. You may want to exchange the retractable (SP-L) solar panels for the non-retractable (OX-4L) ones; that will save a bit of mass and cost. You don't really need RCS on this; other things dock with it, but it doesn't dock with anything. Keep the monopropellant tank, but only for a depot. Maybe only fill it one-quarter of the way, too: you won't run out any time soon. You may want more battery, especially with the big 2.5m reaction wheel. Hitchhikers don't provide control, but I see that you have a probe core on it. A probe core will be fine, and you don't need one with normal hold: you can orient the station yourself and use stability assist instead. You'd need to do that or something similar anyway, because you'll need to set the port you want to use to 'Control from Here' to get the navball markers in the right places. All told, this is a good first station--albeit a little ambitious with its docking capacity--but ambition is a good thing in this game. Good luck!

Look at the delta.cfg link in the infobox to the right of the wiki page and it'll tell you more. The maximum and minimum drag values in the file are .02, but there's an angular drag value of 2, and a value for drag that varies with the angle of attack between 0 and .6 in ModuleLiftingSurface. Whether those figures mean anything to you is another matter. If that's not what you want, then you might be best off looking at modder resources: modders who make wing parts need to make their wings perform predictably in concert with KSP stock wings, so seeing what they're using to do that (and how they're comparing their parts to stock parts) might be of help. The mods themselves might also be instructive: B9 Procedural Wings comes to mind as one that not only properly has to account for drag, but must do so on the fly, to coin a pun. Good luck!

I'm going to assume that you're good enough with rendezvous to reliably get good close encounters and only need help with docking, itself. I'll not parrot the standard advice that you can find most anywhere, but will instead share a couple of tricks that I've learned over time: Docking ports generally only engage when your closing velocity is less than .3 m/s--that's 30 centimetres per second. You need to drift--with purpose--but still drift to dock. If you put your docking port on the front or side of your vessel and approach from zero relative inclination, then depending on how slowly you perform the manoeuvre, you may find that the circular path of the target vessel's orbit has rotated the target port away from a good angle by the time you reach it. You can do one of two things to help with this: you can learn to drift quickly, or you can use reaction wheels on the target to orient the target port to normal/anti-normal and approach from above/below. Orbital rotation will then merely spin the target port round, not turn it away from your port. For learning, it's okay to be generous with monopropellant and attitude thrusters. Efficiency can only reliably come with skill, so learn the skill first. I play on PC and thus have access to the alternative translational controls for the attitude thrusters, but I think that on console, you are stuck with docking mode instead. I don't know the way to get to docking mode on console, but I will say that translational control is much more important than rotational control for docking. This is another reason to rotate the target so that the docking port is aligned with the normal axis: you can rotate your vessel to face normal while still somewhat far away from the target port, and then switch to docking mode and use the translational controls to bring your vessel in to dock. Precision control mode (accessed on PC with CapsLock--I hope that helps you find the appropriate control for console) is, if not absolutely necessary, then certainly helpful. When it's active, the roll, pitch, and yaw indicators on the lower left of the screen are blue instead of orange. You don't need power to dock; you need precision. The best unsung feature of precision control mode is that it balances the thrust output of your attitude thrusters to keep your vessel aligned. This alleviates any balance issues that come from not having the jets positioned equidistantly from the vessel's centre of mass. Lastly, if you need to practise docking, then you should consider sending up a set of docking trainers. These are little tugs with a probe core, monopropellant tank, attitude thrusters, docking port, and only the minimum necessary hardware to power and control them. They're cheap, highly manoeuvrable, and a lot more forgiving than your 3-million-Funds orbital station. If you send them up as a set of two, then you won't need to worry about rendezvous, either; simply undock, re-dock, and continue doing so in various situations until you're comfortable with the process. If you break one, then de-orbit and try again. I hope that helps. Good luck!

On the main KSC screen, it's the complex that touches the VAB and the Astronaut Complex. Here's the relevant wiki article: https://wiki.kerbalspaceprogram.com/wiki/Research_and_Development It's the same place where you research upgrades and new parts, but the archives are there, too, and you can select them with the button at the top left once you're in the tech tree. Almost certainly it was. What you describe is the diminishing return of a science experiment run twice (three times, actually) in the same location. When you're orbiting in Kerbin 's Low Space, the Science Jr. has a total of 32 base Science points available (with normal difficulty settings), but only allows you to recover 25 of those on the first run of the experiment. The game then uses that fraction, 25 / 32, for each subsequent run of the experiment. In this case, it's approximately 78%, so what that means is that every run of the Science Jr. in a location where you ran the experiment before will recover only 78% of the remaining Science. The first time, you get 78% of 32, or 25 Science points. That leaves 7. The next time you run it, you get 78% of the remaining 7 Science points. It goes to zero fairly quickly; as you discovered, there's not much point to running the Science Jr. a third time (at least, not in Kerbin's orbit; some places with very high science multipliers do make a third run worth a try). Every experiment is different: some give you all of their Science the first time. Some give you less than 78%. Some give more. If it told you that you had 25 Science points coming to you, but then only awarded 8, then my guess for what caused that is that you had another Science Jr. that ran the same experiment in the same location, and you recovered it before the module that only gave you 8 Science. That happens especially when you have both experiments flying at the same time: KSP tells you that both are worth 25 points, even though only the first one is, because you haven't yet recovered either one and so it's not set in stone yet. 8 is a weird number to receive; 78% of 7 points is closer to 5.5 than 8. The extra points could have come from craft recovery. Anyway, it's easy enough of a problem to address: run different experiments, or else run this experiment elsewhere. If you take your rocket up to 250,000 m, then you'll reach High Space, which is a different location and for which the Science Jr. has a base number of 48 Science points (of which you should get 37.5 the first time). There are many, many different combinations of altitude, celestial body, and other factors that affect the available Science. Part of the point of the game is exploration, and this is one way that it encourages you to do that. Have fun!

I can at least help you with this part. Here's a link to a relevant comment in the FlybyFinder thread by its author, @PLAD: The link still works, so there's that. The thing to note is that most Lambert solvers (which would be the algorithmic wizardry that makes porkchop plots and calculates flybys, among other things), cannot handle transfers that start and end at the same point. However, this spreadsheet manages to do that by adding a way to track double-flybys through the use of orbit ratios. It involves a lot of trial-and-error and is not very user-friendly, but in fairness, this very high-level stuff, even for KSP.

Good things! You're right! It's been a while since I've tripped over that particular KSP quirk. It makes enough of a difference: the error becomes truly negligible at about four parts in ten thousand. I've edited the earlier post to include that bit of data.

Not to cause an argument, but if @jimmymcgoochie's suggestion holds, then I didn't see a local year readout anywhere in Kerbal Engineer. It might be in later versions, though. To your problem, @king of nowhere: It's Kepler to the rescue! Actually, that's not quite true; KSP does give you some information that Kepler didn't have. However, it's largely the same problem, so we'll solve it the same way: with (simulated) telescopes and a lot of (not simulated) maths. If you don't mind a bit of calculation, then here's how to derive the answer from the information at hand: First, you won't need the parameters window for the planet. You will need it for the sun. If your mod changes the sun, then you'll want to find the number labelled GM. For the stock sun, it has a value of 1.172 x 1018 m3/s2. You can find more precise values in the game files, but this works with what you can get from the Tracking Station. (Also, if you want to figure orbits for a moon, then you'd want to get its planet's GM, instead.) Second, you'll need the altitude and velocity values for your planet. You can get these simply by putting the camera focus on the planet and zooming out until you can see its orbit about the sun. For an example's sake, let's use Dres at time Y1, D01, 00:02:52: velocity = 4,629.8 m/s altitude = 46,499,448,126 m Note that you will also need to add the radius of the sun, since KSP gives the altitude over the surface and we're using a formula that depends on distance from the centre. The radius is the first value in the parameter window, so it's just as easy to find as GM. For the stock sun, the radius is 261,600 km, which is easy enough to convert to 261,600,000 m. Putting it together: focal distance = altitude + radius of sun focal distance = 46,499,448,126 m + 261,600,000 m focal distance = 46,761,048,126 m If your planet has a particularly eccentric orbit, then these values can change quickly. You may be better off using Map View, where you can more easily pause the game, to obtain these values. Next, we need to use the vis-viva equation. Here it is: v2 = GM ([2 / r] - [1 / a]) where: v = the velocity, which we found GM = the gravitational parameter, which we found r = the altitude, which we found a = the semi-major axis of the orbit, which we need As it is, this equation doesn't help us much. We need to solve for a: v2 = (2GM / r) - (GM / a) GM / a = (2GM / r) - v2 a / GM = 1 / ([2GM / r) - v2) a = GM / ([2GM / r) - v2) With the numbers: a = (1.172 x 1018) / ([2 * (1.172 x 1018) / (46,761,048,126)] - [(4,629.8)2]) a = 1.172 x 1018 / ([2.344 x 1018 / 46,761,048,126] - [21,435,048]) a = 1.172 x 1018 / (50,127,191 - 21,435,048) a= 1.172 x 1018 / 28,692,143 a = 40,847,419,449 m, though given the precision of GM, we can only commit to 4.085 x 1010 m. If that's too tedious, especially if you have multiple planets, then I'd recommend a decent calculator, such as the ones at Wolfram Alpha or Desmos. Once you have a, it's a fairly straightforward matter to get the orbital period: T = 2π √(a3 / GM), where the only new and unknown value is T, which is the orbital period--or local year, in this case. Substituting our value for a yields: T = 2π √([40,847,419,449]3 / [1.172 x 1018]) T = 6.283185 * √([6.815439627 x 1031] / [1.172 x 1018]) T = 6.283185 * √(5.8152215 x 1013) T = 6.283185 * 7,625760 T = 47,914,063 s, which in Kerbin days is 2218.2 days. This is off by just a little less than 1 day (which, at .04% error, is better than good for a single observation) and is mostly due to the rounding error, which results from the mere four-place accuracy that we get from the sun's GM. If your mod uses the stock sun, then I can give you a better GM and radius: the most accurate value for GM is 1.1723328 x 1018 m3/s2, and the best value for radius is 261,600,000 m. That won't help much, though: the velocity only has five-place accuracy. Otherwise, you'll have to use the in-game value or else look into the mod files for the system parameters. That should be easier, though: if your mod is configured with Kopernicus, then the planet configuration files should have a section called Orbit that lists the semi-major axis by name. You'll still need to calculate the orbital period yourself, but that's trivial compared to deriving the semi-major axis from (pseudo-)celestial observations. I hope that helps. Good luck!

May I suggest Skylab, instead? I'd argue that that's much more in line with the idea of a single-launch station. The bare minimum for a station is going to be the same as any other orbital mission, minus the provision for re-entry. That means that you'll likely want power, either a probe core or a permanent pilot, and reaction wheels. These are not necessary (you can rendezvous and dock whether it's powered or unpowered, but unpowered is more difficult to dock), but they are so helpful that they might as well be necessary. That said, if you want to do anything with it, then you have a number of options: If you want to have a propellant depot, then you'll need appropriate tankage and a docking port (I suppose you could rely on the claw, but that's a bit later in the tech tree). Nothing says that the appropriate tankage can't come from the rocket that put it in orbit in the first place. You don't even need to remove the engine--though I'd suggest manual deactivation it if you keep it. If you want to transfer crew, then you'll need a crew module with an accessible hatch (no docking port needed; you can EVA them over). If you want to do orbital science, then you'll need appropriate experiments. If you want to process science in a mobile lab, then you'll need one of those and scientists to put in it (and a source of science, but that need not be on the same vessel as the lab). You'll also need an antenna, battery, and power source to return the processed data to Kerbin. If you want to expand the station later via orbital assembly, then you may want a docking port. There are other things that you can do with a station, but a lot of that depends on your own goals (and a great deal on your mods if you have any--space telescopes, passenger terminals, training centres, life support modules, communications relay stations, refineries--all are possibilities). Here's an example: I run a station for tourists that allows me to get them into orbit using my standard passenger tour rocket, then transfer them to an interplanetary vessel that stays in space all the time, and finally a second station around the Mun or Minmus that has the landers for those who want to touch down. That's not necessary, but it lets me run a couple of different kinds of tourist missions at once without needing to take all of them to land on the Mun. Since I also use life support mods, keeping them in a station with overbuilt support machinery means not worrying about them using up all the air on the Mun lander, too. Good luck!

Others have covered the basics of rendezvous, but one thing that I wanted to bring up is that sometimes, the shield icons will go wild when you're very closely matched with your target. If you're in nearly the same orbit, then your distance from the target is nearly constant, and something as simple as rotating in place can affect what the game thinks is your closest approach. The shield icons can only give you a general idea and are no good for final approach and rendezvous. There comes a point in any rendezvous when you need to get out of Map View, for the same reason that you don't use Map View when landing a plane: you need to see details that Map View can't show you. Another issue, which I suspect is closer to what you're experiencing, is that the shield icons represent the next two closest approaches only. It is possible to have two close approaches on one orbit and then have a third closest approach (which is not shown at first) on the opposite side of the planet. Once you pass the first point, the game doesn't have the subtlety or nuance to understand that you're still fairly close--it jumps to the next prediction and if that prediction is for a closest approach on the other side of the planet, then so be it. The solution for this is, again, to ignore Map View once you're close and use other tools for final approach and rendezvous.

@Vanamonde has the answer: The original writer of the mod has a wiki that explains this, located at this link: https://github.com/Ippo343/DangIt/wiki/Failure-modes There's a section on tanks that tells you to click the little green icon in the tank's context menu, which is what you open when you right-click on the part (its official name is the Part Action Window). You may have tried this before and saw that the tank kept leaking; I understand that that's how the mod works. The damaged tank itself will continue to leak until you repair it, but by locking it, you at least keep the rest of the vessel from trying to pump more of the resource into it from intact tanks.

Don't worry about coming to KSP late. Orbits are periodic, after all. Also, welcome, new person! Those badges would be from the World's Firsts milestone achievements. You do get a nominal amount of science from that, but you're right, it's not enough. You'll need to do scientific experiments to go farther. I will explain something that I have not yet seen other people here say, which is to tell you that, with a very few exceptions, the science experiments do not work automatically. When you start a new game, the experiments available to you are EVA Report, Crew Report, Surface Sample, Mystery Goo Observation, and Temperature Scan. Mystery Goo Observation and Temperature Scan require special science parts to be attached to your rocket; these are available under the Science tab in the VAB. You can unlock new science parts (and thus new experiments) in the Research and Development Complex, but it requires science points to do so, so we'll not focus on that just yet. To perform an experiment, you need to right-click on the appropriate part and find the experiment in the Part Action Window. Note that for crew reports, the appropriate part is the crew pod or command module, and for EVA Reports and Surface Samples, the appropriate 'part' is a Kerbal on EVA. Usually, the experiment is obvious in context (to take a surface sample, the button is the one labelled Take Surface Sample). It may seem difficult to run science experiments while you're also flying an untested rocket. It probably won't make you feel any better, but real astronauts flying real rockets thought so, too. There are some tricks that you can use to make things work a bit better: For one, you can run science experiments right on the launchpad: don't ever say that KSP didn't give you anything for free. That will get you some easy science and let you see how the experiments work without needing to split attention between that and flying the rocket. You can open the Part Action Window on a part before you launch. If you click the pin button in the corner, you can keep the window from disappearing when you click on something else. This way, you can have the window open and shoved off to the side while you get the rocket in the air, and can then run the experiment without needing to find and right-click on the part while in flight. Experiments work in certain combinations of biomes (roughly, locations on the planet) and situations (roughly, how high off the ground you are). Some experiments give one global result in certain situations, and some won't work at all in certain situations (there's a seismometer that won't work unless it's on the ground, and a deep space telescope that needs to be in deep space, for example). The early experiments all give unique results (and more science points) when landed in different biomes, and most of them give unique results when flying over different biomes. Don't be afraid to turn a rocket to the west or north to catch some of those biomes, even if only in flight. Rovers and precision landings can wait for better rocket parts later in the game. Situations are considered on an immediate basis: what that means is that an experiment that gives new results in low space will give those results if you run it as soon as you leave the atmosphere. You don't need to be in a stable orbit. When you run an experiment, the result is stored in the part until it is transferred to a science container. There's a dedicated part for that, but command pods also count as science containers. Transferring a result to a container generally requires a Kerbal to go on EVA, so it's not advised to do this while flying through the atmosphere. Transferring the result lets you reset the experiment so that it can be run again. There are exceptions and caveats to this. The Mystery Goo does not reset unless you have a Scientist do it, and for early rockets, you'll often have only a Pilot. Crew Reports necessarily get stored in the command pod where they are generated, but the experiment storage is not the same as a science container, even though both are on the same part. This means that you'll need to exit the pod with an EVA Kerbal, take the data from the pod, and put it back in the pod, whereupon it will go into the science container and let you take another crew report. Transferring data to a command pod is useful because with large, multistage rockets, the pod is often the only part that comes back: the science parts are abandoned to burn up in re-entry or on the Mun or wherever. However, if you're recovering the entire rocket, then you can leave the experiments in the science parts and recover the whole thing when you land or splash down on Kerbin; recovery will extract the science data from the experiments without you needing to do anything more. This means that if you want more science on fewer flights, it may be worth your time to attach multiple thermometers and multiple Mystery Goo containers to your rocket and run each one in sequence as you reach new situations. Also note that you can repeat an experiment in location/situations that you have visited before, but there are sharply diminishing returns. Mystery Goo stops generating useful results after the third time, for example. EVA Reports and Crew Reports give you all of the science they can the first time. Don't bother with transmitting results in the early game. There is a time and place for it, but transmitting reduces the Science you can get from the experiment: you always get the most Science per mission from recovery of the data, either from the experiment part or from the science container. Should you have any other questions, or anything was unclear or unhelpful, please feel free to ask. Have fun!

Yes! While the game tools do offer some easier options for this (such as the claw, as @Vanamonde mentioned, or even just deleting it from within the Tracking Station), this is a great way to practise rendezvous. I will caution you to make certain that any docking clamp that you attach has its axis point through the centre of mass of the booster, if possible, or else you will get a surprise when you light the de-orbit engines. That can work, though you should be aware of which way the MechJeb module points. Orientation is important for a probe core, and if what you think is prograde is a direction that it thinks is anti-normal, then you're going to have bad results. If you want to pursue this seriously, then you might want to look at Stage Recovery to recover Funds. Another option is to fly the booster into the Mun (the mod is a bit out of date, but I always thought that Impact! was a lot of fun, and Strategia, which is also somewhat out of date, has an impactor probe strategy). If you want to try your hand at a flyback booster, then kOS is the mod for you. There are quite a few scripts and script tutorials out there for building flyback boosters; the main problem is flying them while you have another vessel coasting to apoapsis. Next, if you're interested in reusing the materials for some other project (and why not, since you went to the expense of getting the thing into space in the first place--David Brin's short story 'Tank Farm Dynamo' explores a similar concept, though with much harder science fiction), then you should look at Modular Kolonization System, or MKS for the ability to break down rocket parts into material kits that can be used to make other things in space. Lastly, if you just want to blow things to smithereens without too much hassle, you have two mod options: first is TAC Self-Destruct, which is exactly what it says on the tin, and the other is Kerbal Inventory System, or KIS, which has an explosive part that your engineer can attach to something that you would like to make go away. Have fun!

I'm excited for bug reports, if you can believe it. During KSP1's development, I always appreciated the interactions between the developers and the forum community, and seeing things brought up by the community be worked into the game was always thrilling--it made a person really feel like a participant in making the game better. I found that was true even when I wasn't the one who wrote the report.

Not with that configuration, no. The closest you can get is to land the rocket's bottom port on the rover's top port, but don't try it: the exhaust from the engines will destroy the rover. Usually, your best options for surface docking are, in no particular order: Have ports aligned for horizontal docking (such as two rovers, or a rocket with a very low-slung port), though getting them to align is tricky Use an extremely lightweight craft that can fly around on monopropellant, because such a craft will not destroy things with its exhaust Use a claw (be aware that the claw, unlike regular docking ports, requires some velocity to dock, but also be aware that the resultant momentum can damage or destroy parts) Use a mod Don't surface dock (you can refuel in orbit) I don't know what your engineer's capabilities are, but you may be able to move your docking ports to a more accessible orientation. This one may tie into 4, above If you have Breaking Ground, you can try a robotic arm, assuming that the crossfeed rules let you do this.

There is a 'temporary' Kerbal Maps (that has proved to be more or less permanent) that I normally would be happy to link for you, but although the original made was presented as an add-on and only accessed information that was available in the public API, I couldn't find a licence for either it or the temporary version. I do not know whether it is authorised officially, and I don't want to fall on the wrong side of infringement. If there is an official opinion on that, any mod watching is welcome to share. On the other hand, there is a thread on this forum that links to it, and it was commented on with approval by a moderator (who is no longer a moderator, but was one when this was posted), so I'll link that, instead. Here it is:

The Tracking Station shows the locations and orbits and such for proposed contracts. I believe that that extends to placing a marker on the point on the ground that is supposed to remain in view of the satellite. I don't know the extent to which this is affected by the Tracking Station upgrade level, but a fully-upgraded Station should tell everything that you need to know. That said, this is probably the best option in terms of a long-term solution: you either know that Ike is in that orbit, or you'll certainly find out. True. Or you could just move the contract target area to the other side of Duna. My point was more about the fact that there's no way to salvage this contract without some kind of save-editing, and less about the practical complications of how to do so. Also true, and hilarity can often ensue. We've had a few people in here who asked how they were supposed to lift hundreds of tonnes of Ore to Eve orbit, and I quite enjoyed the facepalm moments when they were told, 'Don't bother. Use different Ore.' Technicalities are important: 'Test Launch Clamps on the Launchpad' is a lot easier than 'Test Launch Clamps in High Orbit', but for a while, anyway, both were potential contract offerings.

There is a way, but it is absolutely cheating. That last step is optional, of course, but you might as well get some enjoyment out of it. On a much more serious note, I suppose that this is a good time to point out that one of the unwritten caveats and general gotcha! moments of this game is that, unlike many (most, I think) games that offer repeatable, random missions and quests and the like, no provision is made in KSP to ensure that completing these missions is actually possible: the random number generator will create elements that are possible (so you won't get something that asks for an orbit of 13 Gm over Kerbin), but it doesn't check to see whether the combination is possible. It's up to you to decide, based on the information offered, whether to take the contract. I think that the idea behind it is twofold: first, as the administrator of the space agency, it's your job, not that of the contract writer, to decide whether doing these missions is within your capabilities. The contract writers can be a lot like children who write NASA begging to be taken along on a trip to the moon without really understanding why that cannot be done. Second, the impossible ones can be rather funny. You've got a perfect opportunity to say, 'That's no space station; that's a moon!' right in front of you. You could also say, 'That's not a satellite! Oh, wait, yes it is.'

You're not; the game thinks that your rover is exposed to the outside airflow. Pardon my complete lack of technical expertise on this, but I understand it that there's a bug with occlusion such that objects docked inside closed cargo bays can be considered separate vessels by the game, which means that they are subject to drag. Of course, they're still physically connected to the rest of the vessel, so that drag pulls on the whole works. What I don't know is whether this appears always, or only when there are certain conditions at work (such as certain kinds of clipping). What I do know is that if you want to eliminate it completely, then the only solution that I know will work is to install FAR, since FAR uses a completely different approach to figure occlusion.

@Ghostii_Space: It does seem that Oxygen Not Included, Astroneer, Satisfactory, and KSP all share a certain type. Of course, now that you've admitted it, you're pretty much stuck here. Committed, even, as the nice men in the white scrubs might say while they help you put on a special jacket. One of us! One of us! One of us! *Ahem* I have two questions for you: You are the most recent in a long line of community managers, leads, moderators, developers, and pretty much anyone else who has had a stake in this forum to say that this is among the very best of on-line communities. I was wondering, since you're the first one I know of who has credentials in anthropology, whether you had any special insights into just why that is, or whether there's any kind of objective criterion that informs that assessment. Not to put you on the spot, of course, and not to suggest that I disagree (I keep coming back, after all), but is there something repeatable in that, or is this a group that managed to turn lead into gold by accident and never wrote down the formula? Who made that fantastic Kerbalised portrait, and is it the same person who does the forum avatars? Either way, there should be an offering of fruit baskets and possibly small, fuzzy animals.

If you switch away from the vessel just launched, whether to view another vessel or go back to the KSC, then you will lose the ability to revert. Quicksaves help when reverting is not possible.

In addition to what everyone else has said, I'll add that you may also be trying to take a bigger bite than your program can support at the moment. You're not wrong that there's a hump in the middle of it, but maybe the approach you need at the moment is a Mun orbiter than can manage low and high space in a polar orbit, rather than a multi-hop lander. There are a few early-game spaceplane SSTOs, but there are also much more mission-capable spaceplane TSTOs that exist because the designers didn't feel the need to force conformity to the single-stage constraint. Also, you get quite a lot of manoeuvring reserve when you don't need to use the propellant for landing (and take-off). Don't forget solar orbit, either. The high space science multiplier isn't the best, but it's something. Don't feel the need to get comprehensive. There's nothing wrong with sending out a couple of Goos on a bare-minimum core-transmitter-power stack with not much else. The OKTO is a fine core for probes that don't need to do much (and even a lot of probes that do). On the other hand, maybe the thing to do is to focus more on making money than on retrieving science, since money is what you need to upgrade facilities to get past the parts and tonnage requirements. Either way, good luck and welcome back, and remember: you don't get rusty in space; you vacuum-cement instead.