Zhetaan

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.

Wow. I don't normally see screens that pristine even in stock. Also, nice plane. Anyway, were you executing this burn by hand, I see a potential problem in that you're set to prograde hold in your second screenshot. A sphere-of-influence change would cause a problem there, since prograde is relative to the body you're orbiting. But MechJeb uses a form of manoeuvre hold to execute its burns (actually, it just knows which way to point the rocket, and points it in that direction--which is a throwback to how everyone had to do it back before SAS manoeuvre hold was a thing), so the sphere change wouldn't affect that. I'm starting to think that you've got a bug of some sort; this stopped making sense three posts ago.

Normally, I'd call that a 'control from here' problem as @king of nowhere mentioned. However: ... I'm honestly not sure of how to parse this one. Even if you had previously set up a manoeuvre for your Dres-Kerbin return using MechJeb, that would just be a standard manoeuvre node in the game--you could shut down or even disable MechJeb and the node (and planned burn) would remain. MechJeb works with KSP, not independently from it, which means that a lot of what it does is done merely using automatic control of features that are already accessible to the player. What I mean is that MechJeb shouldn't be randomly changing your target, but even were that to happen, it definitely shouldn't be cancelling existing manoeuvre nodes and setting up new ones. The only time I've ever seen similar behaviour from MechJeb is when someone deliberately created a new manoeuvre in MechJeb's planner and asked it to execute that plan immediately. Obviously, you're not doing that--at least not deliberately. The only way I can think that you might be doing it accidentally is if you keep MechJeb windows open under other menus while you do other things. One thing that a lot of mods in KSP do not have is click-through opacity (assuming that that is even the correct term), meaning that if you have menus open and overlaid on one another, then clicking on one also registers as clicking on any menu underneath that one, because the mods only register the cursor's screen position, not the menu 'depth' under the 'surface' of the screen, to coin an analogy. Is it possible that your MechJeb manoeuvre planner is under, say, the resource panel or a part action window that you're using on your rocket? If so, then you may be accidentally telling MechJeb to plan a manoeuvre and burn for Jool.

It's not completely impossible. There's a mod for that, but of course that requires you to be on PC instead of console. It's called ReCoupler, and in despite of the thread title saying v1.9, the SpaceDock version is rated for the current KSP version. There is also a way to accomplish what you want in stock: connect your flailing pieces together with docking ports. You absolutely can have a vessel dock to itself. You'll need to decide for yourself, though, whether that fits with the aesthetic that you want to achieve.

Putting aside Kerbin as a trivial case, Duna and Eeloo are the easiest to land on. Duna is extremely forgiving with its thin atmosphere, but Mun landings make good preparation for Eeloo. The difference is getting there: if your question is just about landing, then I'd say it's about even. If it's about the entirety of the trip, then Duna wins handily. Moho: It's actually not too challenging to land on, though it's the most difficult planet in the game to reach. Moho is made as a challenge for navigation. It's not totally easy to land on either; the surface gravity is about twice that of the Mun. Eve: Before heating was implemented, this was the easiest landing in the game provided you had a parachute. Now, landing here is tricky. Aerobraking is actually difficult because there's a very narrow range between failing to capture and burning up--and depending on your incoming velocity, there may be no safe approach without a braking burn. Eve is also a challenge planet: it's the most difficult to leave. Kerbin: Landing here is arguably the easiest, but again, it's trivial. Duna: Of the planets with atmospheres, Duna is the most forgiving for aerobraking--even more so than Kerbin. One is cautioned that parachutes often are not enough to carry the mass of an interstellar vessel, and so parachutes on Duna are often best used to assist a powered landing, but totally passive parachute landings are possible if one can control the vessel mass. Dres: Dres is actually easier, theoretically, to land on than the Mun, since it has .115 gee of surface gravity compared to the Mun's .166 gee. However, the gravity is, I think, overcome by the more uneven terrain. The orbit is rather sharply inclined to the ecliptic, so it's more difficult to reach, as well. Jool: Arguably the most difficult planet to land on. Let us know if you manage to do it. Take Dart engines: they're the only ones that work at 15 atmospheres. Eeloo: Essentially identical surface gravity to the Mun (Eeloo is .172 gee; Mun is .166 gee) means that if one can land successfully on the Mun, then one can do the same here. The terrain is easier and more forgiving, too. Eeloo's main drawbacks are its distance and its orbital inclination, but some creative navigation (and a gravity assist from Jool) can readily lighten that burden.

That'll do it. In both cases, being already out at a distant moon, it's tempting to think that since you're already close to solar orbit, you ought to go the rest of the way there and uncomplicate the manoeuvre. Maybe that's not your reasoning, specifically, but either way, it doesn't work very well. Here's the main reason why this wastes propellant and delta-V: once you get to solar orbit, as in the instant you leave the local sphere of influence (whether Kerbin or Jool), your vessel still has an orbit that looks a lot like that of the planet that you just left. Burning for solar orbit does change it just enough that you become separate entities, but only barely just enough. In other words, with the way that you're doing it, most of the burn for solar orbit is wasted propellant because once you're done, you're effectively only marginally different from where you started. One may imagine launching a rocket by burning until the engines are absolutely spent ... and then releasing the launch clamps. That's not a perfect analogy, but it's illustrative of the idea: you move, but the way that you're using the propellant isn't helping you much. I don't know how you run your Minmus missions, so this is an honest enquiry: when you do a mission to and from Minmus, do you return to Kerbin by burning to break Minmus orbit into Kerbin orbit, and only then burn to drop your periapsis and actually get to Kerbin? Or do you arrange the Minmus return by burning such that your Minmus escape also happens to throw you back along Minmus's own retrograde so that you both break Minmus orbit and return to Kerbin with one burn? If you do the latter, then that (or something similar) is what you need to do, albeit on a larger scale, for interplanetary transfers. The reason is backed up with a lot of mathematics, but the short version is that there is a lot of energy bound up in a high orbit of a planet, whether or not you happen to also orbit a moon. This is because high orbits have a lot of potential energy, which is actually a circular definition because these orbits get potential energy by virtue of being high: in an important way, potential energy refers to how far something has to fall. The problem is that when you burn to break from high orbit without first using that potential energy in some way, then it ends up literally being wasted potential. The thing to do is to burn to dive for a low pass of Kerbin, and when you're at that periapsis, that is where you complete your burn for Jool. The reverse applies for returning to Kerbin from Jool. There's a lot that goes into the timing for a burn like that, and I won't get into it because @king of nowhere and @Streetwind already covered it, but what I want you to take from this is that high orbits have a lot of potential energy, and that you can save yourself a lot of propellant if you make the effort to realise that potential by first diving into the lower planetary system from these high-orbiting moons. If potential energy is a measure of how far your rocket has to fall, then actually falling essentially converts that potential into energy of motion--and energy of motion is what gets your rocket to new and interesting places.

In the TAC-LS standard loadout, waste is the one waste product that you cannot recycle into anything else. Carbon dioxide and wastewater can be reclaimed or recycled somewhat, but waste is essentially the final end-state that represents an utterly spent resource. If you want to do anything with waste, then you'll need an additional mod. There are a few greenhouse mods that will use TAC-LS waste as an input to grow food. In the literature, TAC-LS does specify the different types of waste generated by each reclamation or recycling process (Water Splitter produces hydrogen, Sabatier produces methane, Bosch produces carbon), so it wouldn't bee too far off the mark for Realism Overhaul or RealFuels to make use of that, either. Again, it requires another mod.

The only mod I know that dynamically shifts coordinate systems is Principia, but that's because it simulates n-body orbital dynamics. There are ways to solve your problem, though: you can use the Law of Cosines to get a velocity vector for a combined plane-change/altitude-change burn. Here's a link to some example problems. For your case, you'd want to get the relative inclination between your initial and final orbits (since neither of them is zero with respect to the primary) and solve on that basis. I believe that would be the 31.58 degrees that is listed in your Kerbal Engineer window. Bear in mind that this method considers both initial and final orbital velocity, so you probably have a bit more calculation to do to determine the final velocity post-burn.

I believe that that will only work when the game considers it a single vessel, though, so you're not going to get away from needing to dock, in which case @NewtSoup has the general idea. Ground docking is usually a pain, because even if you took two identical copies of the same rover with docking ports on their noses, for example, putting them together on anything but perfectly flat terrain can cause issues because the docking ports may not be angled to meet correctly. There are some pre-robotics, stock solutions to the ground docking problem, up to and including making the refinery a landing pad and dropping the tanker onto it, but these tend to be cumbersome at best. That being said, you should be aware that quite a few people have reported problems with combining docking ports and robotic parts, so be wary. Anyway, there are some general tutorials out there for robotics parts, but I'm not entirely certain of how useful you will find them for your application. Regardless, here are a couple of them: Good luck!

Certainly. The general calculations, or at least an example of them, can be found here. A more practically useful step-by-step demonstration for Duna, which you can (and should!) use to evaluate your Duna trip so you can get a feel for how it works, is here. Also note that the second link is a part of a series of KSP Let's Do The Math videos, and the next planet in that series is Moho, so you may find it especially useful. The equations used in the video all follow from the vis-viva equation, which is as follows: v2 = μ[(2 / r) - (1 / a)] Where: v = instantaneous velocity at that point of the orbit, μ = standard gravitational parameter for the primary body (it is Kerbin for the escape, the Sun for the transfer, and Duna for the capture), r = orbital radius at the point of the burn, and a = the semi-major axis of the orbit. Calculating these for your parking orbit and your transfer orbit, then subtracting to get the difference, will yield the burn delta-V. You'll need to do it multiple times, considering each leg of the trip, but that's all fairly straightforward--especially if you have a good grasp of algebra. The nuance is in selecting where and when to burn. I understand that to be part of the challenge, so I won't deprive you of a chance to figure it out for yourself.

The Oberth effect is probably the easiest to calculate. You'll need the vis-viva equation and a decent working knowledge of algebra, but it obviously can be done: the ship flies, after all. Longitude of Ascending Node (which I assume is what you meant; how large the ascending node is is simply your inclination angle, but where it is is the longitude) is much more difficult to do. The problem is that in reality, LAN is defined based on a 'fixed' (that's only relatively, locally, and temporarily true, but it works for navigation for now because of the scales involved) point in space, and the only 'fixed' points in space are the stars. KSP, on the other hand, doesn't have stars. It has a pretty skybox, of course, but that skybox is essentially painted on the face of the universe for aesthetics and without any consideration for navigation. In other words, it has no fixed orientation, which means that you cannot take repeatable, reliable bearings from stars. That said, there may still be ways to help you: I find it difficult to believe that there would be an impossible challenge on the Discord without someone else figuring that out and announcing it. What is the challenge?

@Just Jim: My apologies for arriving so late to the article, but I wanted to express my appreciation: you've largely become the epitome of 'local boy makes good' for the forum, and to see how much you've been able to chase the dream is very gratifying for someone who's been a fan since Chapter 1 of Emiko Station (considering that it's been nearly seven years, now,--wow!). I have two thoughts: first, considering how unique KSP is, I'll say that if, after you've finished, KSP is only half as unique, then you've done the best job possible. It looks like that's what you're trying to do, and it also looks like you're succeeding. Not to diminish the contributions of your teammates (far from it--they sound like great colleagues), but I know that there has been concern in the past about whether KSP2 was going to be a, for lack of a better term, 'spiritual successor' to KSP instead of merely a sequential one. It is beyond satisfying to see someone whom we already know 'gets' KSP doing so much to curate the tone of the sequel. Second, are you certain that you want to go with Advanced Photonic Generation System? Electromagnetic Radiation Generator System abbreviates to a much better pun. On a side note (and much more seriously), I hope you've managed to dodge the storms without too much trouble. Stay safe, good luck, and thank you.

That's because orbital period defines the resonance implicitly. Resonance occurs when the two orbital periods are in a ratio that can be reduced to low integer terms, such as 1/2, 2/3, 5/4, and so on. For satellite networks, you generally want 1/1 because that keeps the spacing, and manoeuvres for that are more a matter of relative positioning rather than resonance. The reason that specific values for the apsides don't matter is because orbital period, in turn, is dependent on the semi-major axis, and only on the semi-major axis. The eccentricity doesn't matter; only the semi-major axis does. That said, for a comm system, having the satellites in high-eccentricity orbits will change their relative positioning on a cycle even though the average is constant. This can be a feature rather than a bug: satellites in Molniya orbits exploit this in combination with inclination to spend a long time above the northern hemisphere in resonance with the Earth's rotation, thus repeatably giving better satellite coverage to certain longitudes in the northern hemisphere. There are other important features of Molniya orbits, as well, but the point is that the resonance works because of the semi-major axis and its relationship to orbital period, not because of any other factor, which means that there's a lot of room to modify those other factors and thus many potential applications for different types of resonant orbit.

The only way I know to do what you want without mods is to use what I will call the contract slot machine. Normally, there's a penalty for declining contracts, but you can turn that off in the settings (it's one reputation point per decline, so it may or may not be worth it for you). Then, start declining contracts. Mission Control will generate new ones, and you can keep declining contracts until you get one that you want. However, there are two points of caution: Some contracts are locked until you do certain things in the game, whether it be visiting a celestial body or something else. If a contract is locked behind a milestone, then no amount of random number generator abuse will get the contract that you want. There's a weighting system in place for contracts. If you decline a contract, then the system takes that as evidence that you won't want that type of contract in the future. If it's a contract type that you don't ever want to do, then that's fine, but if it's a contract that you'd like, but not right now, then it may be a problem for you to decline contracts of that type too many times, because it means that you won't see that contract type when you decide that you do want it. If, however, mods are something that you might like, then I suggest that you give Contract Configurator and its associated contract packs a try. It will let you choose the contracts that you like from a list of available types. It won't necessarily have every contract possible (random numbers and player progression are still part of the game here), but it will show you contracts of the various types available as well as the requirements needed to unlock other types of contract.

Docking mode does change the controls. If you're having this problem, then it is possible that you have a keybinding issue or a conflict of some sort in your settings. However, it seems more likely to me that you have a CommNet problem. Are you playing with comms, as well? You might be having a problem where your radio signal (or lack thereof, actually) is only letting you have 'limited control', in which case it's not a docking mode issue at all. Does the vessel respond to rotation input when you turn SAS off? It may help to know that in normal flight mode, WASD provides rotational control (technically, it's WASDQE, because roll is a thing in three dimensions), and IJKL provides translational control (technically again, it's IJKLHN for a similar reason). The nice thing about that is that it allows you to have simultaneous control of rotational and translational motion, and also doesn't train you to press the shift key for anything other than engine throttle.