Zhetaan

You can boost, though, right? If that's the case then it's a matter of one of two most likely causes: pilot error and rocket design. Pilot error is the easiest thing to correct, but it assumes that you are completely new to KSP and need help learning to fly. That's not a bad thing (we were all new at this once), but if you can get a rocket into orbit and fly to the Mun, then it suggests that rocket design is the most likely issue. Just the same, if you are completely new and need help learning to fly, then some basic instructions are in the spoiler. On the other hand, let me ask: are you simulating an Apollo-style mission? Do you have a separable lander of any configuration? Your problem may be that, assuming that they are docked nose-to-nose, your upside-down vessel is the control point for the whole assembly, and every time you orient retrograde to burn for capture, you're actually burning prograde to escape. If that's the case, then right-click on the pod correctly oriented, select 'Control from Here', and try again. Don't forget to tell us whether that worked (and if not, then please provide a screenshot of your rocket, preferably in flight, so we can try to diagnose the problem). Good luck!

I see a whole-vessel delta-V of nearly 7,000 m/s and a thrust-to-weight ratio of 2.3. You're fine. Actually, at this point, I'll caution you that that is a very energetic lifter and you may find that, after launch, you have a hard time turning it in atmosphere without ripping pieces off if you're too aggressive with your pitch control. If that happens, then the solution is to use the thrust limiters on the SRBs. You should be able to turn down the thrust to, oh, 67% or so. That will drop your launchpad thrust-to-weight to a respectable 1.5-ish which will keep your rocket flying upward but with less unplanned disassembly. The other issue that might become a problem is staging away the SRBs when they burn out. They can have a tendency to strike your core after you detach them. I usually prefer pairs over quads for this reason, but don't be afraid to use Sepratrons if you need them.

In Kerbin orbit? That will take you to Minmus and back several times. On the launchpad? Add a launch booster to get it into orbit.

It's also possible to get back to Kerbin for under 1,000 m/s, provided that you go from Dres to Jool. There are flyby trajectories that have you using Jool for a braking gravity assist to drop you into the inner system for a Kerbin encounter; the best flybys that I've found so far can do it for between 950 and 980 m/s. These are obviously very time-dependent (transfers that coordinate three moving bodies--not including your vessel--are an order of magnitude more complex to plan than two-body transfers) but the window does reopen every few thousand days.

Technically, that would be an asymptotic function, not an exponential. Anyway, according to this post, it's probably an algorithm, which is to say that the results change based on arbitrary rules that don't necessarily relate well to a mathematically-precise continuous function. I'm interested in finding out a bit more about it myself, so I think that I'll look into it a bit more deeply. I won't have much time to do so until the weekend, though, so don't expect an answer from me for at least two days.

200.25, in point of fact. @Nicias: Since you are a dedicated mathochist, at the least you'll need to get to eccentric anomaly so that you can figure your time-of-flight and ensure that you'll intersect Vall's orbit at a time that Vall is actually there. Which means that you'll need true anomaly, and well, it becomes an avalanche at that point. Do you use Kerbal Engineer? You'll need a way to get the true anomaly, which you cannot do with celestial observation in KSP (the skybox is just painted on; there's no First Point of Aries, and if there were, it wouldn't stay in the same place). Alternatively, if you're feeling extra insane, you can simply define a coordinate system and solve for it there. So long as you have the relative positions of your vessel, Vall, and their orbits correct, then you can solve for the burn in any convenient system without needing to use mod tools.

I'll second @Streetwind's post, at least for planes. However, nothing in your post says specifically that you're flying a plane; just that you're flying in an atmosphere. Nevertheless, the logic holds. The only really good reason to take a tank full of LFO is if you intend to use it, and if you're using closed-cycle Rapiers when you have Nervs available ... well, why would you do that? Pushing through the upper atmosphere might be a good reason, but you don't need a big rocket tank of LFO for that. Depending on how much oxidiser you need, you may be best-positioned to use a Mark 3 liquid fuel fuselage with a Mk3 to 2.5m Adapter. It still has a lot of LFO--likely more than you'll want--but you'd need the adapter anyway for the cleaner look. Of course, you can always try a mod; there are plenty of rocket-profile LF tanks out there, since people correctly saw that it made no sense for the Nerv to be a fantastically-efficient LF-only space engine and not have any good rocket-profile LF-only tanks to go with it. Some of these are just fuel-switching mods that will make a stock LFO tank into an LF-only tank without the need to add extra parts. It's worth a look: without mod tanks, the result is often that you either get a Mark 3 fuselage assembly that adapts down to 1.25m for the Nervs (and the adapters almost all have LFO, so watch out), or else you get clusters of Mark 1 fuselages because they have the same 1.25m profile as the mid-diameter rocket parts (small in KSP would be the .625m parts, like the Oscar-B). In fairness to the developers, the Nerv originally was an LFO engine like the other rocket engines (it wasn't realistic in its function; it just had great efficiency), so when it was introduced, there was no need for new tanks. They corrected that later, but never added new tanks to go with it.

Hmm. Well, it doesn't seem right that it would reference field work (as opposed to contracts) and then not convert field work. Perhaps 'field work' refers to things such as part tests and experimental surveys--these are things that generate science because of the contract, but are not counted as part of the science reward for completing the contract. To put it another way, if you have, for example, a contract to test some part on the pad, then the test itself will often generate science over and above the listed contract reward. I must offer my apologies because I did not test this myself. I'll take a closer look later today and report on what I find; I have a test install of KSP that I can use for this. In your mission summaries (these would be both the report after you recover a vessel, and the contract completion report that you access from the toolbar) does it show a number in parentheses next to the science total? That would document the effect of your strategy. I ask because it may be that the devs decided to leave actual experiments available as a source of science points if you needed them (this would be from before they made the changes to the mobile lab, mind), though it boggles the mind that they would not have been thinking of these experiments as field work. I'll look at the cfg files as well when I run the test rig. There are couple of other possibilities to consider, as well. How high is your reputation? One important difference between science and rep is that science is a running total that cannot go below zero, whereas reputation asymptotically approaches the endpoints on its -1000 to 1000 scale. If your reputation is sufficiently high, then you cannot gain more. (The same is true in the other direction: the general public becomes inured to your indiscriminate and reckless disregard for property and the lives of your Kerbals, and your reputation cannot go below -1000, either.) In other words, the more reputation you have, the harder it is to get even more. I think that the game would take the many disparate sources of science, add them up, and only then convert the total into reputation points, but if it does each conversion individually, you might be gaining thousandths of a point and thus seeing no practical change. What this means for your strategy is that if you already have a high reputation, converting science points into more rep may just be a way to get rid of excess science points. and nothing else. Another alternative is to ask whether you committed 100% to the strategy? You mentioned unlocking the entire tech tree, so I assumed that you also had a level 3 Administration Building, which you need for 100% commitment. I'll have an answer within twelve hours, I hope. Edit: Did it in eight! Anyway, the strategy configuration file is very clear: 'field work' consists of ScienceTransmission, VesselRecovery, and Progression. ScienceTransmission is straightforward. VesselRecovery covers, I think, both experiments recovered with the vessel and the vessel itself (for those times that you bring back the first vessel to fly by, orbit, or land on a body). Progression is the internal name for World's Firsts rewards. I also ran a short career save with the strategy turned up to 100% and with a number of experiments in different situations. The vessel recovery window showed the science value of each experiment, but the bottom of the window showed zero science gain. The notification window (the one with the green checkmarks for completed contracts and blue globes for World's Firsts--it's the first button on the toolbar) showed the correct subtractions of science and additions of reputation as I expected, and my actual science total did not change after the mission. Perhaps that was the problem?

It just means science points from doing actual experiments, as opposed to the science points that you may receive from completing contracts.

In that case, this is pretty much the definitive post on the subject. It's also the case that you'll be looking for something more nuanced than just passing in front of or behind celestial bodies, because the main trick to those multiple-assist trajectories is getting the timing right for the intermediate legs. For example, there's a multiple assist to get to Moho by way of Eve: you can get to Moho by way of Eve but the problem is that Eve cannot, on its own, slow you down enough on an infalling trajectory from Kerbin to both get you to Moho in one pass and save enough propellant to be more worthwhile than just flying there directly. So the way to do it is a K-E-E-M assist. For that middle leg from Eve to Eve again, the exact flyby orientation is less important than the timing of the interval, which needs to be exactly 65.5 days (one Eve year) or else you'll miss the Moho encounter (or make it very expensive, at least). But that means that you need to take the assist that will give you that interval, not the one that reduces your solar speed the most. It's not so bad as it sounds, because the assist that gives you the right interval will put you in the right place for the next assist, which is the point. But it means that you're not looking for the maximum possible effect on the flyby, either. That's okay, since multiple assists are really just chained transfer windows, and transfer windows are mainly about timing. Your mission may be about propellant efficiency and delta-V budgets, but the windows don't care one bit about that because the planets move and align regardless. Unlike, for example, a Tylo gravity brake to get into Jool orbit, where it's ideal to approach Tylo from directly behind (if possible), swing round at nearly ground level (if possible), and exit exactly in Tylo's retrograde (more or less required), you may find yourself exiting (or approaching) the intermediate celestial bodies at a weird angle, because that's the angle that gives you the right timing for the next encounter. Do not neglect your course correction budget, and remember that when you correct for an upcoming encounter, you should really be looking at the encounter after that. Well, maybe glance back to ensure that you're not getting that 'encounter' via a collision course with Kerbin or something. Otherwise, this encounter should be all about setting up the next encounter. Do that and you'll be fine.

If you mean passing in front and passing behind, then ... roughly, yes. It would be more accurate to say that your exit speed relates to how close your exit direction is to the celestial body's prograde direction. If they are roughly parallel, then you speed up in the primary sphere of influence. If they are anti-parallel (meaning that you're aligned with the body's retrograde), then you slow down. B and D show the craft leaving the body in something like the body's own prograde direction (it isn't exactly parallel, but it's obviously more prograde than retrograde), so the craft speeds up. A and C show the craft leaving roughly retrograde, so it slows down. There's a whole list of caveats and addenda to that, mostly relating to your speed, angle of approach, and periapsis (and a lot of it deals with the fact that, being in three-dimensional space, you can do other things like change inclination with a gravity assist).

Apsis is borrowed from ancient Greek. 'Apses' is an attempt to use a Latin pluralisation on a Greek root, which is not correct. The correct plural is apsides. Wall of explanatory text in the spoiler: In the end, though, languages--even dead ones--change over time, so eventually, apses is probably going to be accepted as a legitimate plural of apsis. However, if you do decide to use the correct Greek form, then please be aware that the pronunciation is ap-si-DEES, not ap-SIDES. It rhymes with keys or freeze, not rides or hides. In theory, they can be anywhere. Of course, an escaping comet or asteroid has no apoapsis because it is not on an elliptical orbit, but escape is not a function of position; it's a function of speed. There is no magic line where an object on one side is captured and an object on the other side is escaping. You see this on any interplanetary launch from low Kerbin orbit: with enough speed, you escape Kerbin from a, for example, 100 km orbit and go to Duna. Burn in the retrograde direction and your orbital speed drops to zero and you land (or 'land', in the sense that the char and ash will eventually hit the ground). Do nothing and you orbit until the hard drive fries. It has nothing to do with being in low Kerbin orbit: all three scenarios are possible. Another way to look at it is in terms of eccentricity. An elliptical orbit has an eccentricity strictly less than 1, but the problem is that the formula for eccentricity is this: e = √(1 - [b2 / a2]) Where e is the eccentricity, a is the semi-major axis, and b is the semi-minor axis. The problem with this is that eccentricities less than one are achievable for arbitrary values of a and b, because a can tend to infinity and b can tend to zero while keeping the b2 / a2 term nonzero. A parabola, which has an eccentricity of exactly one, can be seen as an orbit where a is exactly infinite. A radial orbit, which while not a parabola also has an eccentricity of one, is the case where b is exactly zero. Practically, comets are going to have some nonzero speed which will constrain the possibilities for apoapsis if they have an elliptical orbit, but I don't know the range of those possibilities.

I agree, but I will also say for the sake of posterity that one of the drawbacks of KSP1's tutorials was that the tutorials were made while the game was still in alpha. Thus, a lot of the tutorials were incomplete because they didn't cover new features, or existing tutorials were broken when things were changed. For one example, the change to the atmospheric model between .90 and 1.0 completely ruined most stock aeroplanes. For another example, the updated engine models (and deprecation of the engines that they replaced) broke one of the rocket design tutorials--the tutorial looks for a part that no longer exists, and of course it won't complete until the user places that part on the rocket. KSPedia helped a lot, but it's not the same thing.

TAC Fuel Balancer The mod thread does say that it is available on CKAN and updated for KSP v1.12, so you should not have any trouble there. I did look through the history to see whether, in the chain of people who have maintained it, anyone changed the name from 'TAC Fuel Transfer' to 'TAC Fuel Balancer', but didn't find it. The mod does transfer fuel, so I think it's just a case where someone got the name wrong and the wrong name caught on. I'm not certain that it does precisely what you want it to do, but at least now you can try it and find out.

5% cosine losses would be the dividing line that I know. There's no physical threshold or change of state for this; it's a matter of convention, like the unwritten rule of thumb that says that launch stages should have a burn time of about two minutes each, or that a launch thrust-to-weight ratio of 1.3-1.7 is ideal. What are cosine losses, you ask? I'm assuming that you know that the best time to thrust for an escape burn is at the periapsis. There are a lot of reasons for this, but two of the factors involved in making an efficient escape burn are that it's better to adjust the apoapsis (because it's the part of the orbit that is closest to escaping in the first place), and that it's better to thrust prograde or retrograde to change the shape of your orbit (normal and radial do change the shape, but they primarily shift the orbit's orientation, which a prograde burn does not). The periapsis is the one point on the orbit where both of these factors work together at maximum potential effect. Cosine losses, then, are the inefficiencies that you get from burning anywhere but at the periapsis. That's a generalisation, but it captures the idea. For an easier-to-understand example, let's imagine that you have a rocket with two engines side-by-side. Ideally, both engines point straight back: you want the rocket to go forward, all of the available thrust is pushing you in that direction, and there is no loss. Now, let's rotate the engines so that they both point outward somewhat in a V, like a lot of cartoon rocket ships do. The combined thrust vector still points out the back, but it's smaller because some thrust goes out to the sides (and is counterbalanced by the side-thrust of the other engine). That side-thrust is useless, the propellant wasted, and is an example of cosine losses. In the extreme case, we rotate the engines by 90° to point directly sideways, which results in a full cancellation of thrust and the rocket going nowhere. That would be 100% cosine losses. This example has a caveat: you don't need two opposed engines to have cosine losses, because any thrust that is not in the direction that you want to go is lost thrust. One engine pointed sideways gives 100% cosine losses, and one rocket pointed sideways gives 100% cosine losses, too. This means that thrusting normal when you want to thrust prograde is also an example of 100% cosine losses, even though in such a case, your rocket does go somewhere. Thus, thrusting in a direction that is not prograde at the periapsis, even though it does something, and though that something may be mostly what you want it to do, is not 100% ideal. Since it isn't possible to have a 100% ideal burn, cosine losses can also be said to represent the unavoidable difference between the ideal and reality. You calculate cosine losses by taking the angle of interest (engine deflection in the previous example, and angle difference from periapsis in the orbital one) and taking the cosine of that angle. The difference between that cosine and 1 is the fraction of the burn lost (so cos 90° = 0, and 1 - 0 = 1, therefore 100% of the burn is lost when you thrust sideways). That said, some cosine losses are inevitable. The only burn that is perfectly efficient is instantaneous, which of course does not happen in reality. This is where burn time becomes important, especially for low-thrust rockets: you want the burn times to be long enough to actually do something with the orbit, but not so long that you're wasting the thrust on something that you'll need to correct later. 5% cosine losses correspond to a window of a little under 13° on either side of the periapsis (and around two minutes in low Kerbin orbit) Depending on what you're trying to do (and how tight your propellant reserve margin is), you can adjust that limit up or down. I prefer something a lot tighter (I try not to go over 6° unless I can't avoid it), but I'm willing to split a long burn up into more parts to make that happen. You may want a margin of 20° or more, but you should know that the loss goes up rapidly when you deviate from the periapsis. As far as planning a split-burn, that's a little more complicated, but the key is that you usually want your last burn to do the work of setting up your interplanetary transfer. This means that your next-to-last burn (and the others if you need more than two burns) works to set up your escape, and your very last burn must occur at the same time as you would have burned if you were doing it all in one big push. It's tricky in KSP to start with a later burn and work backwards (KSP is set up for planning multiple burns in succession going forwards in time, instead), but it can be done. Here's what to do: Note the transfer window time and location on the orbit. Also get the delta-V for the burn, and note your orbital altitude (the altitude is important; don't forget it). Set up a burn that is somewhat less than an escape burn. For a circular orbit, the delta-V needed to escape is a constant for a given orbital altitude. Let's say that you're in a 100 km orbit of Kerbin: to escape requires 3,176.5 m/s. You're already going at 2,246.1 m/s just being in orbit, so the escape burn requires 930.4 m/s. For the sake of easy numbers, let's go with a 900 m/s burn (to set up an orbit that almost escapes--and if that's too long of a burn, then yes, you can divide it into 3 burns of 300 m/s, or 9 burns of 100 m/s, or, if you're a dedicated masochist, 900 burns of 1 m/s). Note the amount of time that it takes to complete one orbit (you can do this from the map view). Whatever the orbital period is for that orbit, you simply go back that amount of time from the transfer manoeuvre and set up the burn. It likely won't be exact: you need the final manoeuvre node to coincide with your periapsis, so to make that work, you'll need room for corrections and adjustments. On the other hand, a close orbit of Kerbin takes about half an hour, so it's not like you're going to miss your window. Remember to take the 900 m/s off of the final burn. Well, yes. That's exactly how it works. A typical transfer to Duna (typical defined as: I used the alexmoon tool and took the first one it offered) costs 1,030 m/s of delta-V. 930 of that is spent just in escaping Kerbin's gravity. That does not mean that only the last 100 m/s can be said as being for going to Duna. That is exactly the wrong way to look at it: the transfer burn needs to be considered as a whole rather than as a sum of independently-movable parts. All of it is used in going to Duna, and all of it is spent in getting away from Kerbin to do so. The truth of this is seen in the execution: if you don't complete the burn, then you don't get the encounter. You can split a burn in two and do it in two distinct steps, provided that you don't change location (that being, in this case, the periapsis of your ejection/transfer orbit). You cannot split it into two pieces, do one in low Kerbin orbit and the second in solar orbit, and expect the burns to add the same way. The reasons for this take a while to explain but the short version is that the energy of the orbit is distributed differently, which for you means that the energy available to exploit for the transfer is also different. The same kind of thing applies to launching from the surface of Kerbin: at or near the equator, you save a few hundred m/s by launching to the east because the surface of the planet is rotating in that direction. If you launch from the north pole (putting aside for the moment that there is no east), it doesn't matter your direction because there, the surface of the planet is only rotating in place. Kerbin's rotation didn't change; you just put your rocket somewhere where you couldn't take advantage of it. Thus it is with your choice of interplanetary burn: you end up wasting a lot of the second one by burning somewhere other than at the periapsis. It's not cosine loss, per se, but it's a similar sort of problem.

There is a difference, but not at a point that matters. Since you intend to orbit both, there is no gravity assist to help you. The only place to save delta-V, therefore, is in the braking burn on return to Kerbin. That makes the Kerbin-Mun-Minmus-Kerbin route the better choice, because you'll be coming in from Minmus slightly faster and can shed more velocity for 'free' by aerobraking ... at which point, the mission's over anyway.

From what I can see, you should try adding engines (and propellant for those engines). I hope that does not come across as condescending, since it is a sincere reply to your question--but because I see no engines, what you have in orbit right now is what I would call the return capsule, or the very last part of the rocket that is left when the rest of the mission is done. If you took this to orbit, then the only thing that you can do with it is return to Kerbin ... but to do that, you need either an engine or else an orbit that hits the atmosphere. If you want to do other things, like go to other planets or moons, then you need more rocket. I can't be more specific about what to improve without knowing what you want to do with it, because those mission types, and the rockets needed to complete those missions, vary dramatically with the destination and intended goals. Given what you've shown so far, I'm going to guess that you're a new player (or else you're very dedicated to using the demo). That's great--we love introducing new players to the game!--but it also means that there are ideas at work here that you're probably unfamiliar with, and sometimes, we experienced players forget to explain them. Instead, let's talk about it from a different direction. There's no such thing as a 'best' rocket, because rockets are designed completely differently to carry out completely different missions. There may be a 'best' rocket for a specific mission, though, so let's talk about the mission. What do you want the rocket to do, which it is not currently doing?

@HebaruSan is correct, so I'll give a bit more context and explanation. You can't stop it. This is an emergent property that arises because you're in a rotating frame of reference. Because your orbit is a curve, the direction of forward motion (what you and I know as prograde) changes with respect to any absolute frame of reference. Anything that moves to intercept is necessarily on a different curve, and so the different directions of prograde will result in relative drift. This is true even if you match orbits perfectly first, because moving to intercept necessarily changes the shape of your orbit. This is also the reason that all of the counter-intuitive manoeuvring (i.e., decrease altitude to increase speed, and so forth) works in orbital mechanics: you have to account for the rotating frame of reference. That's true on the surface, as well, but we can usually approximate things with straight lines and flat surfaces (though there are notable exceptions in navigation: following a great-circle course, with a few edge case exceptions, means constantly changing your heading). This rotation affects everything in any combination of prograde and radial directions. You may note, for example, that radial in at the periapsis points in the opposite direction of radial in at the apoapsis. Over the course of the orbit, the compass rose of prograde, retrograde, radial in, and radial out rotates around one time. This rotation is parallel to the axis of the orbit and perpendicular to the plane of rotation, i.e., about the normal direction. What this means is that normal does not change over the course of the orbit, and you can use this to your advantage when docking. Provided that you do not change inclination much, you can approach from normal or anti-normal and get a dock without the target vessel rotating away from you. This only works for small relative inclination differences because matching orbits in every way but inclination means setting yourself up for a collision later--either controlled docking, or the more explosive version. Other alternatives include docking in a high orbit (with its slow rotation) or simply docking quickly (this could mean rendezvousing, matching at a close distance, and waiting for a potion of the orbit for the target to point the docking face that you want towards you).

I'm glad to see that you figured it out, but in the interests of education, you should know that there is an interaction range around the experiments, beyond which they are what I will call 'out of reach' of the Kerbal. This is something to remember if you're in the habit of putting science gadgetry in service bays. This range is called interactionRange in the .cfg files and it can be modded, but it's usually not necessary for stock science gear. For the Science Jr., the range is 1.85 metres. For the SENTINEL telescope, it's 1.2. It appears that for all of the others, it's 1.5 (I'm not certain about the magnetometer, but it is 1.5 for the rest).

How many boosters? I try to avoid this when I can, but I have taken a rocket with a four-booster radial stack and thrust-limited two of them so that I could stage them in pairs. The trick, then, is to execute a roll program so that the pairs of boosters decouple to the sides, rather than above and below the main rocket body. If you're still having a problem getting the boosters away from the vessel, then you have a few possible solutions. One is to use a Seperatron. My preferred configuration is to use one on the outside side of the nose cone, upside down and essentially pointed so that it pushes the nose of the booster down and away relative to the rest of the rocket. I keep the decoupler near the nose, as well (fuel lines work a lot like struts and hold the bottom steady), but I don't know what the limitations are for a Kerpollo, so you'll need to see for yourself whether that fits in the rules. Another solution is a passive one; use aerodynamics to pull the spent booster away from the rocket. You can do this with nothing more than a basic fin on the outside of it; once you decouple, the drag from the fin will pull the booster away. You could possibly see a similar result by using a radial drogue parachute, but you'd need to be low and slow enough that it would at least semi-deploy. Another solution--admittedly, a bad one--is to carry the empty tank with you until you're far enough out of the atmosphere that you won't need to worry about collision when you do decouple it. If you run out of booster right before you start coasting to apoapsis (assuming that your program has you doing that), then you'll lose a bit to drag but otherwise won't spend too much in letting the tank ride until you're nearly ready to thrust again and put some distance between it and the main rocket.

Aside from a general hope that they go with region over biome (which I think is rather a silly descriptor for a portion of a lifeless, airless moon), I do like @Tw1's general thinking that science should feel more like a process than a game of fetch. I can't speak to ease of implementation, but I think that there's something to be said for splitting out science from a general collection of points to something a bit more subject-based. I'm not looking for something so involved as to be confused for the real thing, but I don't see why taking the temperature of the ocean (or, for that matter, recovering a rocket for the first time) should help me build a more efficient rocket engine. Perhaps have a few broad categories, and having running experiments (or recording, in the case of sensors) in a given region will help to add to the collective body of knowledge in that subject. Linking the tech tree to interrelated fields of science, rather than an arbitrary point total, would probably help the thing feel a little less slap-dash, too. However, though I cannot speak to ease of implementation, I can say that this would probably become unwieldy in a hurry, which is unfortunate.

Well, don't apologise for asking questions. That is the literal point of this forum, and besides, if you ask certain questions frequently enough then we can put it in a special place for questions that people ask frequently. We can call it 'Things People Ask About a Lot', or the TPAAL--something catchy like that. Anyway: For the Clamp-O-Tron Jr., you get two such to mate by having the shiny rings touch. This means that, assuming that you're going for an Apollo-style configuration, you will want the assembled Command-Service Module to have the shiny ring pointed up (assuming that the main engine is pointed down and for the Lunar (Munar?) Excursion Module's shiny ring to point down onto that of the CSM. However, I do feel compelled to point out that if you want authenticity, then you should have the LEM (MEM?) in a fairing under the CSM, which is at the tip of the rocket. Then, once you've achieved trans-Munar injection, you blow the fairing, release the CSM, and then turn around to dock with and extract the lander. For the other docking ports, the one that routinely gives people trouble is the Clamp-O-Tron Sr. The general rule is that you want to see a short slot on the docking face, and no plus sign. That's the mating face. Have a look at the part in the VAB (start a sandbox save or look at the wiki) and you'll see what I mean.

@jimmymcgoochie has the essential limitation, so I'll merely flesh out that answer: In the stock game (meaning no DLC or mods), the total available science is indefinite. I won't say infinite, but it is unlimited. First, there is no limitation on the number of labs that you can have running at any time. You only need to supply them each with copies of the experiment data. Second, there is no limitation to the number of experiments that you can feed into a lab past the stipulation that each experiment be unique (so there are no repeat experiments in any given lab). The number of biomes (and biome-derived experiments) is finite ... but the number of asteroids and comets is not. The only real limitations on it are computer memory and, more likely, your patience.

As others have said, loss of power is the likely culprit here. Assuming that that is the problem, here are some solutions: If you have solar panels, then turn the spacecraft to face the sun. This may require you to get out on an EVA and nudge the vessel with your suit jets. You don't need a lot; you just need to get it moving so that a panel eventually rotates to face the sun. Don't push the panels themselves; you'll break them. Just nudge the nose of the rocket a bit. This happens sometimes with the deployable panels when their rotational axis ends up pointing at the sun; they can't get power because that's the direction that they cannot turn to face. It's preventable by having panels that are not 180° from one another (I like to use either 3-symmetry, or if I don't need that much power, having two panels at 90° from one another). Be certain that nothing is on and drawing the power; you may want to use stability assist to keep your vessel facing the sun, but turn off any lights or other power-draining modules. If you are using the right rocket engine (a Swivel or Reliant, for example) then you have an 'alternator' installed that generates electricity while the engine is running. It would not take much, but of course you will need to make a course correction afterwards. The best part is that in the stock game, you don't need electricity to start the main engines. If you have the right trajectory, then you may need to do nothing at all. Once you are on a re-entry trajectory, you don't need to worry about power. You may need to use the engine to brake a bit, but you can do that once you're committed to the atmosphere. To get on that trajectory, you may need to get out and push (which is possible with your suit jets, albeit slow), but it is doable. Hopefully, you designed your rocket so that its aerodynamics orient you correctly on atmospheric insertion. If you need the electricity to keep your heat shield pointed in the right direction ... well, let's hope that you don't need that. Good luck!

Here are the actual stats (from the wiki, so though not completely canon, they're probably accurate). Valentina: Courage = 55 Stupidity = 40 Jebediah: Courage = 50 Stupidity = 50 Valentina is slightly braver and moderately less stupid than Jebediah. However, it should be noted that both of them have 'BadS = Yes', which means that they ignore these stats and remain blissfully content even in the face of certain annihilation. 'BadS = Yes' has a way of equalising the attitudes of the Kerbals who have it to the point of making the actual stats completely irrelevant. It also should be noted that these traits only affect their facial expressions and even then are for aesthetic flavour only. A Kerbal pilot in the midst of a panic attack is still perfectly capable of controlling the rocket. Therefore, Jeb and Val are exactly equally capable, barring differences in experience--but that's a decision that you make by choosing to send one over the other on missions; it has nothing to do with raw, base talent or ability. Neither is more 'powerful' than the other. On an historical note, Bill and Bob were also equally capable back before KSP had specialisations (indeed, they were more equal to Jeb, because experience was not yet implemented, either). The only difference between them was the level of panic on display, and even that was something only seen on launch; reaching space gentled everyone very quickly.