Zhetaan

@PrvDancer85: Sea level Isp depends on two things: the engine's configuration file and the atmospheric pressure. The sea level pressure for each body is: Eve: 5.0 atm Kerbin: 1.0 atm (naturally) Duna: .0666667 atm Laythe: .6 atm (its gravity is .8 g; apologies, @Streetwind) Jool: 15.0 atm (not that you would want to go to 'sea' level, and no rocket will have usable thrust that low, but the value exists) I picked a selection of popular first-stage engines (and the Poodle for comparison) and pulled the atmospherecurve values from their configuration files (on the wiki, which may not be completely up-to-date, but it's close enough for now). Mammoth: 0: 315 1: 295 12: .001 Twin Boar: 0: 300 1: 280 9: .001 Mainsail: 0: 310 1: 285 9: .001 Dart: 0: 340 -50 -73.71224 1: 290 -21.23404 -21.23404 5: 230 -10.54119 -10.54119 10: 170 -13.59091 -13.59091 20: .001 Swivel: 0: 320 1: 270 6: .001 Reliant: 0: 300 1: 280 7: .001 Poodle (for comparison): 0: 350 1: 90 3: .001 With these values, you can either use a Unity floatcurve editor to get exact intermediate values, or you can take a few guesses and interpolate for rough intermediate values. The first two values for most of these engines give an exact Isp for vacuum and Kerbin sea level; the third is the effective cutoff pressure in atmospheres. The Dart has a more complex curve because it has to maintain near-constant Isp over a variety of pressures, that's mathematically tricky, so it has extra numbers. These are all cubic Hermite splines, as has been said (@Starman4308), but I'm not at the right computer for that. For values between 0 and 1, the curve is usually linear enough that a linear fit will work, but for values greater than 1 (Eve), the curve is no longer linear enough, so I used a quadratic fit instead. However, that is not necessarily the best fit, especially for values close to the cut-off pressure (Eve's surface is usually in the suspect zone). The Poodle has the most extreme drop in Isp and no clamping on the nodes, so its curve is, in a word, crazy: I tried a logarithmic fit for it as well. Though it gave a better curve than the quadratic, the intermediate values were different enough that I chose to use the average value and indicated the approximation with the tilde (~). It should also be noted that the Dart uses a clamped curve, which is a lot more difficult to draw on my one-lung work computer, so you should probably consider both the Duna and Laythe values to be suspect; unlike other engines, however, the Dart has a defined value for Eve sea level, so that value, at least, is exact. Note further that the Poodle drops out at three atmospheres; it has no significant thrust on Eve. Note further than that that Duna's atmosphere is almost negligible; vacuum Isp can be approximated reasonably as sea-level Isp for any first-stage lifter. Second-stage and dedicated vacuum engines probably have more significant differences. All stock engines have negligible thrust at 15 atm; Jool take-offs are just as impossible as Jool landings. I'll see about doing some more work on this at home later today. Engine Vacuum Duna Laythe Kerbin Eve Mammoth 315 313.7 303.1 295 203.6 Twin Boar 300 298.8 288.4 280 166.7 Mainsail 310 308.4 295.3 285 161.4 Dart 340 335-336 307-308 290 230 Swivel 320 316.7 290.1 270 56.7 Reliant 300 298.9 288.9 280 123.8 Poodle 350 328.2 176.8 90 <<.001 EDIT: I tried this with a spline interpolator and was able to refine the values somewhat. Everything for which a quadratic spline was sufficient changed at the hundredths or less; the values given in the table stand. The Poodle was very close at Duna but I revised by about ten for Laythe. The interpolator I used didn't allow me to use tangents, so I need to wait until later to better refine the values for the Dart.

@Just Jim: I thought the telepathy-vision-dream sequence was very reminiscent of the SSTV signal from Duna. In any case, it was quite nicely done--I don't even want to guess at how much time you had to spend on it to get it right.

Have a look. The short version is that it boosts Tylo's and Vall's orbits to break the resonance (and attendant perturbation) and changes Bop's orbit to retrograde.

@fisune: Also, welcome to the cozy little family. The community here is extremely supportive, and if there's anything you seek to know about how things can be done, please ask. It's true that doing just about anything in this game is extremely difficult, but it's also true that finally seeing it accomplished is extremely rewarding. Per ardua ad astra, and all that goes with it.

@JEB'S DESTINY: @Streetwind has the right of it, and I will only add that when we say 'figure 8', don't expect it to look much like the numeral with the two loops being of roughly the same size. It's a very lopsided 8 where the orbit crosses itself very near to the Mun. About 90% to 95% of the figure is Kerbin's loop, and the Mun gets the tiny bit left over.

Your Skipper only runs for 38 seconds. That's not really enough time to justify the engine; I'd suggest switching it for a Poodle. Usually, it's worth trying to get about two minutes of burn time out of a stage. Assuming that the previous stage is enough to get you to orbit, a Poodle might even give you too much dV for munar transfer--which is a good thing, because it also gives you a lot of margin and reserves for picking a perfect landing spot. You have monopropellant but no attitude jets that I can see; it's just along for the ride and that's a waste. If you do have attitude jets, why? If you get rid of the monopropellant tanks; drain the monopropellant out of the lander can, as well. It's not that big a deal but why pay for it if you won't use it? The high-drag transitions at the top of the rocket are going to cut down on your ascent efficiency a lot. Using adapters or switching to all 2.5m parts would help that. On the other hand, if you have access to fairings, that would work just as well and prevent your lander from being so tall as to tip easily. On the gripping hand, you could run the same mission with all parts on a 1.25m stack, but I got the impression that that is what you tried before and it did not work out too well for you. If you do have fairings, you can do things that don't really make intuitive sense. For example, you can surface attach the small FL-T100 fuel tanks after flipping them up on their sides (so that you join the added tank to the centre tank by the flat face--don't try to join it on the curved face); you can fit three of them around a central tank and get four times the fuel for nearly the same footprint as one tank--but ploughing that through the atmosphere is a pain, so definitely use fairings. Definitely consider switching out the boosters for Thumpers. If that gives you too much TWR, then reduce thrust and run them for longer. Keep some winglets or fins; you shouldn't need those big swept wings for that rocket, but you absolutely will need something. Others have said to consider exchanging the lander can for a Mk. I Pod, and that's something to seriously consider. Since the pod (and utterly necessary parachutes and shielding) is what needs to come back, you may want to consider putting all of the science gear in the landing but not the ascent stage, and letting the ascent stage consist only of the actual Kerbin return package plus a small engine and enough fuel to return only that package. Do you have the 2.5m service bay? It can fit all of the science experiments you brought and save you both height and drag, and you can put it in the section with the landing legs to be staged away once you are ready to make your Kerbin return.

That's funny. I thought he was in Los Angeles. That's quite the craft. What did you use for the air screws?

@BlackWing Pilot: If you decide to use Alex Moon's planner, note that it gives both date and time of departure and a set of two angles called the phase angle and the ejection angle. These angles are better understood with a visual: this is Olex's interplanetary calculator, from which part of Alex Moon's planner is derived. You'll need both of them to be correct in order to get good transfers. The phase angle has to do with the relative position of the origin planet and destination planet, and is the reason that transfers can only occur during 'windows'. If you leave your origin planet outside of the window, then while you will often reach the destination planet's orbit, the destination will not be there when you do. The ejection angle is related to the fact that you begin your interplanetary trip from an orbit around a gravitational body and so your departure point must move a little to account for the way that gravity can change your flight path on your way out of the origin's sphere of influence.

I second this. While there is something to be said for boosting to Eeloo first and then setting up a bi-elliptical transfer to Moho, in the interests of time, tedium, and overall fuel savings, you're better off taking Eve-Moho-Eve first. Also remember that transfer windows are least frequent between planets that are next to one another in their orbits; it may make more sense to skip around the system a bit.

Quite true. But you came to the right place, so let's take another try. First, orbital mechanics and manoeuvring is confusing; everything you thought you knew about motion goes right out when you put it in orbit. When I was learning this, I found it hideously frustrating, but the trick sometimes is to step back and watch someone else do it. Set some appropriately-themed music.... ... And let's see what we can find. If you want better or different tutorials, then you can look here. Remember that some of these are old enough that the game mechanics have changed; for orbital operations, however, anything from 2015 and later is okay. A lot of the stuff from earlier is good, too (they didn't change the Mun's orbit or anything like that) but SAS has changed its behaviour a few times during KSP's development. If you're committed to learning how to do this using the various hold modes, then stick to the later tutorials. If you want to learn how to do this stuff by hand as well, then take a look at some of the older stuff. I found a video series that plays the in-game tutorials (from version 1.1, but nothing has changed in space between 1.1 and today) and it shows the same behaviour that you were complaining of: I linked it at the end of the burn, but you can clearly see that the node hold switches to stability assist when the remaining burn goes below 1.0 m/s. The manoeuvre node also flies off the navball to the right; this is both normal and expected. Even after following the instructions, this video also shows that the burn, as executed, didn't quite lower the periapsis so much as was necessary; to correct this, the player used retrograde hold and that is perfectly acceptable. Later on, during the actual landing, it shows what happens when using too much retrograde hold; the ship stopped descending and began to climb, and the SAS forced the nose to point down. This was not a destructive problem because the vessel was high enough off the ground that it did not crash, but it did waste fuel. And no, I do not know why the navball markers show up in black in this video; it doesn't affect the function.

I'd be guessing as to the exact relationship, but the idea is that as you take contracts but don't complete them, there's a law of diminishing returns. Note that 'available' contracts for you right now is not 15, it's zero, and that implies that the diminishing return begins to assert itself when you're about halfway to the average. I have not tested this myself (hence the guessing), so that may be completely wrong. If you were to set AverageAvailableContracts to 20, it could be that you would then start to see offers go down at about 10 but would be able to squeeze 30 contracts total out of the system, or it could be that you would only see diminishing returns at 15 contracts but could max out at 25. Or it could be something completely different; as I said, it's not well-tested. The only contracts I've seen for more than six tourists are mod contracts. That's another reason to look at Contract Configurator--specifically, Tourism Plus. Take a look at the screenshot in its first post and decide whether that interests you, but the important part is that you can eventually get contracts for up to 50 kerbals at a time. It also has some other interesting contracts such as the Space Camp, where you take 13 tourists and three instructors into orbit for a month and a half. When you're done, three of the tourists join the space program. Of course, if you want to put together some kind of large spaceliner for a mission to Jool and don't want to waste the construction on six tourists, you can always take multiple Jool tourist contracts and send everyone together ... assuming that the game lets you have more than one at a time. If not, you know where to change the setting. No, it means that having two stations is necessary to get the maximum chance for an expansion contract. With one station, you can still get expansion contracts, but there's a lower chance of getting them. I'd have to look at the rest of the file, but I think that if you have only one station, it tends to offer contracts to build a second over expanding the first. I'm not certain whether the game requires a station to be marked as such in the Tracking Station--I suspect so, but I've been surprised to get a World's Firsts reward for station construction just from docking a lander to a transfer vehicle while in Kerbin orbit; it seems that the game automatically thinks of a station as having a docking port, antenna, power generators, and at least a six-kerbal crew capacity (you may note that these requirements are always present in station-building contracts). I do know that Tourism Plus won't give station visitation contracts for tourists unless the station is categorised as such in the Tracking Station.

@ej89: The cake is a lie. So is the 'unlimited contract' feature of Mission Control. @nightingale's Contract Configurator will let you have up to 18, I think (and it offers some other features that you may like, so have a look), but I believe what you'd really like is found in Gamedata\Squad\Contracts. It's a file called Contracts.cfg, and near the top is a line that says 'AverageAvailableContracts = 10'. Change this to what you like. Just be mindful that there is a limit for a reason, so watch out for issues that may arise from raising the limit to something absurdly high.

Escape velocity from that orbit should be about 3160 m/s; the remainder is excess velocity that you need to not only escape Kerbin, but also go to Duna. The way I do it is to set up a manoeuvre that gets close to Duna--I usually don't want the transfer apoapsis to go higher than Duna's orbit, but since this transfer is less than perfect timing, you'll have to make do--and then take the whole node and slide it back along my pre-burn Kerbin orbit. As I do, the warp pulls my final trajectory more in line with Kerbin's prograde, which makes the burn more efficient ... which raises the apoapsis. When it won't go up any higher, then I know I'm close and will check the ejection from Kerbin SOI to compare it to Kerbin's own trajectory. If it looks good, I call it good, and somewhere, a NASA controller dies on the inside a little at my slap-dash methods. Keep in mind that there's no way to see both your low Kerbin orbit and your Duna transfer orbit without zooming out and back in, so it can be a little tedious until you get a feeling for the correct angle. Anyway, when I'm close, I pull slightly retrograde to pull my apoapsis back down to Duna orbit and I begin to slide the node again. I need to do that because the highest apoapsis I got before was the highest for the original burn, but once I changed the burn, that stopped being true. Since the new burn is close to the old one, the new angle ought to be close to the old one, too. I generally don't bother fine-tuning it more than once; the savings in fuel isn't worth the hassle for me after that point. Also, while the tweaks will change your apoapsis height a bit, don't expect something spectacularly dramatic as when you drag the manoeuvre around low Kerbin orbit for a Mun transfer. If you began with a fairly close encounter, then you should end with a close encounter, but it will cost a lot less in fuel.

@hhatch: Pretty much everything @OhioBob said, though I will add one other thing: ejection angle. I know that OhioBob defined it, but I'll flesh it out a bit more because it's surprisingly important. The idea is this: let's assume that you're going to the Mun from an equatorial orbit around Kerbin, so there are no inclination changes, corrections, or anything you need to worry about other than burning at the right time. If you burn prograde for a Hohmann transfer, then the point where you burn is the periapsis and the Mun's orbit is at the apoapsis. If you additionally burned at the right time, then the Mun will be at that apoapsis when you get there yourself. This is all elementary and I've no doubt you know it already given that you're working on interplanetary transfers. A return from an orbit in empty space is similar; point retrograde at the apoapsis and burn. Now consider a return from the Mun: you can't just point to the Mun's retrograde because you're not in empty space; the Mun's in the way and its gravity will warp your path. You also can't wait until you're on the Mun's prograde side and burn to raise the apoapsis on the far side to escape; this is closer to what you want, but again the Mun's gravity will warp your path. As you circle round the Mun, the gravity will sling your vessel to a slightly higher apoapsis than the Mun's orbit. Because the Mun puts some orbital energy into raising your Kerbin apoapsis on escape, it takes that energy away from lowering the periapsis, so you end up with a trajectory that usually isn't enough to reenter at Kerbin without correcting, which wastes fuel. Instead, you need to account for the warp, burn a little early, and as a result use that warp to put your vessel where you want it to go without wasting fuel. The Mun still warps your path, but the idea is that by changing your burn time, when the Mun slings you out, it raises your exit path so that you leave parallel to the Mun's retrograde, which gets you where you want to go. The difference between a burn that accounts for the warp (and burns a little early) and a burn that does not (it burns to raise apoapsis to escape at the Mun's prograde point) forms an angle, and that is the ejection angle. When going on interplanetary journeys, ejection angle is even more important, because the burns are more complicated. Unlike returning from the Mun, where you're leaving from a point (the Mun) to enter a gravitational field you want to reach the bottom of (Kerbin's), interplanetary journeys involve leaving from one point (Kerbin) and crossing a gravitational field (the sun's) in order to hit another point (Duna in this case). Failing to account for the ejection angle puts you on the wrong path through the sun's gravitational field, which further warps your trajectory and may cost you the encounter. It will certainly cost you fuel. In summary, failing to pay attention to ejection angle can ruin an otherwise good encounter. The simple, rough way to check ejection angle in KSP is to watch your post-escape trajectory and compare it to Kerbin's orbit line. So long as the two are parallel at your point of escape (they don't need to be in the same location; they only need to point in the same direction), then you have it right.

The best place to adjust inclination changes depending on when you set up your transfer window. This is because the cheapest transfer window from Kerbin to Duna depends on the phase angle (this is the angle made between planets and the sun if you're looking at the face of Kerbin's orbital plane), but phase angle doesn't care much whether the orbital planes match. The standard approach is to burn for transfer first, then correct for inclination somewhere on the way. This is because, when the planes of two orbits intersect, the line of intersection defines two nodes on those orbits (shown by the right-pointing green marker next to the dotted line--it's close to the Pe marker), and since a Hohmann transfer is one-half of an orbit, you are guaranteed to pass a node somewhere on the trip. Save your inclination burn for then and you'll get the cheapest one possible. Duna is nearly the same inclination as Kerbin; whatever the correction burn costs, it will be low. Unless your node and transfer window occur in the same place and you can do both in one burn, it rarely makes sense to adjust inclination before you burn for transfer (Moho is the notable exception; it's extremely inclined and there are a couple of other factors that help). This is because correcting for inclination requires you to do that when Kerbin is at a node; you have to then make a second burn for a transfer window. While a Hohmann transfer is guaranteed to pass a node where you can correct your inclination within one-half of an orbit, a correction for inclination does not guarantee a similarly timely transfer window. It might be years away, so it is simpler in terms of mission planning to do the transfer when it is available and correct inclination while on the way. In summary, your current approach is correct. To get an encounter, you may be falling victim to the coarseness of the manoeuvre controls. At the start of the transfer, you are as far away from Duna as you can be, so any tiny change will result in massive changes in your arrival. Vessels that leave minutes apart from Kerbin can arrive a week or more apart at Duna. The solution to this is to wait until you're about halfway to Duna to fix your approach and correct the encounter. You spend slightly more in fuel but you have much finer control because 1 m/s there doesn't push your trajectory from one side of the sphere of influence to the other. I will note that the closest approach markers don't align and that your transfer is more than a half-orbit; that means you're a little late in your transfer, so getting a direct encounter from Kerbin without a correction burn may not be possible. You're close, naturally, but it will cost a bit more in fuel. Also, since reverse time warp isn't a thing in KSP, you'll have to either make do or wait another two and a half years for another window. You will definitely need to add a correction burn later in the trip. I hope that helps.

@DankMemes: It's not a glitch. You're just reaching the endpoint of the burn. There are always little sideways errors (sometimes as small as mm/s) involved in any burn. It's an unavoidable consequence of the fact that no system can ever aim exactly perfectly; this is why correction burns are a thing. However, when the remaining burn is measured in m/s and the errors are measured in mm/s, the errors don't even register. When the remaining burn gets below 1 m/s, the errors become more pronounced. When the remaining burn is zero, the errors are the only thing that register--but the marker on the navball can't tell the difference between the 100 m/s burn you planned and what it thinks is a .001 m/s burn that you can't actually do; it only shows direction. To keep your rocket from spinning round forever trying to correct what it doesn't need to correct (and usually can't correct anyway), the system automatically switches you to stability assist when your remaining burn gets low enough. It does the same thing when going retrograde to the surface (if it didn't, then your rocket would try to dive into the ground nose-first on landing) and when moving retrograde relative to target (this is useful when docking). When you get your remaining burn (that's the gauge to the right of the navball) down to 0.1 m/s, that's usually good enough. If you can make it 0.0, that's great, but you don't usually need to be so accurate.

Ion engines should be last because of the ridiculous Isp (great) and despite the ridiculous mass ratio of the tanks (bad). Xenon tanks are terrible (awful). Incidentally, the Mk. 0 LF tank has a wet/dry mass ratio of 10, not 9, so if you're going to min-max your Nerva-powered interplanetary transfer stage, that's the way to do it. Anyway, @Wcmille, I think the wall you're going to hit with this pursuit is less to do with the existence of an 'optimal' rocket and more to do with the presence of three variables in two equations. You have wet mass, dry mass, and Isp (actually vexh in the original rocket equation but KSP reports Isp instead), but you're solving for the more optimal of two stages. The fact that KSP is, in some ways, LegoLand In Space! serves to constrain the solution space a bit (there are only so many discrete choices for Isp because there are only so many engines, each of which has a fixed Isp) but you still have equal-value solutions for anything within that space. I see that you chose to constrain the solution space further by tying the result to TWR, but TWR is not universally relevant. It's also difficult to constrain; a Skipper cannot lift something that weighs 700 kN, but two Skippers can, for exactly the same Isp and nearly the same dV, which means that both thrust and weight are variable--this means that ultimately, there is a number of engines that will work to lift anything provided that the engine can lift itself against its own weight in the gravity field. It's the same problem of too many variables and not enough equations. [Continued...] All of this is summed simply by saying that if you wish to choose the best engine for the job, then at some point, you need to know what the job is.

That makes sense. I know that Krakensbane works by defining the active vessel as the centre of the coordinate system, so it is plausible that it would need (or could use) something similar for the temporal coordinate, too. Of course, barring one of the staff confirming this, we'll just have to rely on ever-wilder speculation and be happy with that.

@CanOmer: The Mk. I Pod does have .35 'wing area' in stock. More accurately, it has a lift deflection coefficient of .35 and a lifting surface module, which used to be only for wings. It also has a slight offset for the centre of lift. The reason your centre of lift is higher than your centre of mass is because your winglets are angled incorrectly to provide lift, but the command pod's lift is supposed to function when it is pointed relative-down (it's meant to give you some directional control during re-entry). If you grab the root part and rotate the whole rocket so it points more horizontally, then you should see the centre of lift move back. Or don't worry about it; the marker is for centre of lift, but of course you're really more interested in drag, which is not displayed. This will not affect your launch--though I would caution you to be careful with those adapter-less diameter changes at the top of your rocket. Abrupt size mismatch will contribute a lot of drag.

@kerbalfreak: To elaborate a bit more, some of these elements have different names, as @GoSlash27 indicated when naming the parameter you were seeking as both argument of right ascension and as longitude of ascending node. It's also the case that there are other elements that either derive from the seven given or can be derived from them, which is important because KSP doesn't always give the more common elements. For example, the semi-major axis and eccentricity can both give or be derived from the apoapsis and periapsis (plus the planetary diameter, because KSP reports apsides as altitudes from the surface, not distance from gravitational centre), and the apsides are what you see on the screen. Interestingly, the internal computation is based on semi-major axis and eccentricity--when it shows you apsides, it's calculating them from SMA and ECC. KSP stores inclination but reports it with the ascending node--and of course the descending node, which may also be used to calculate inclination--and does not report ascending node except as relative to a target, so finding the inclination with respect to the equator is only possible if your target is also at the equator. KSP knows longitude of ascending node (LAN) but doesn't report it numerically. It does report LAN visually in map mode by showing you where the ascending node is on the orbit, which makes things especially fun when you have an orbit contract that requires a specific LAN and all you can do is eyeball it. The same is true of argument of periapsis (which can also be calculated from longitude of periapsis), but KSP at least reports periapsis without needing to pick a target. Mean anomaly at epoch can also be considered in terms of time of periapsis passage--or actually, time of passage for any defined point on the orbit. Orbital period about a given gravitational point is dependent on semi-major axis and no other thing--not even eccentricity. A circular orbit and an eccentric orbit with the same SMA will always have the same period--but keep in mind that the eccentric orbit will both have an extremely low periapsis and a corresponding high apoapsis, and the orbital speed will be similarly very fast at close approach and extremely slow when far away. KSP doesn't appear to use a common epoch for all vessels (that would be the obviously simple choice of 00:00:00:00:00.000, the start time of the game); if I were forced to guess, I would say that the epoch value it stores is the time of launch. That makes sense; using any particular reference time is the same as using any other so long as the relationship between references is known (and the relationship is known because all reference times are in terms of seconds since game start), but that choice of time allows KSP to calculate both the mean anomaly at epoch and the mission elapsed time from one stored value. I will additionally clarify that the direction of reference in KSP is not so much a random point on the skybox as it is a specific point that cannot be found via what we would call normal astrogation. Calling it random suggests that it changes, which is of course self-defeating for a reference line. In real life, the First Point of Aries is something that can be located because of its relationship to the surrounding stars (and from first principles, Earth's axial tilt, which would be a problem in KSP). In KSP, the sky is 'painted on' to an otherwise completely featureless box (hence, skybox) and the stars that you see in it are mere decoration. You can't point to them in the sense of having them as valid targets because they have no definition as celestial structures--this is one of the many necessary simplifications needed for KSP to work as a simulation in the Unity environment. There's no need to process other stars, and the Unity system gives a zero-angle direction anyway, so why not use that without care for where it points, so long as it always points the same way?

If you mean terrain scatter, the boulders (and trees and cacti) don't have physics; you can walk right through them. That usually means that one of your parts clipped into the ground accidentally while you were out of physics range. The physics ease-in is supposed to help with this, but sometimes it doesn't. The problem is caused by small errors in the coordinates of the rocket versus the ground. When the physics engine loads, a tiny mismatch between the distance from the rocket's landing feet to the centre of Gilly and the distance from the surface of the ground to the centre of Gilly causes your rocket's feet to load embedded slightly in the ground. Since the ground is a thin repellent surface (this is why, if you clip totally through it, you fall into oblivion), it tries to force the offending part upwards, and the stresses of that end up looking exactly the same as a violent crash. Setting unbreakable parts just lets the ground force the rocket up without adding breaking stress; it does nothing to slow down the resultant speed. You may want to be sure that your rocket isn't thrown so far that it escapes.

@Rocket In My Pocket has the link to follow, but that is the technical explanation. For a more straightforward answer: yes and no. Yes, you get science points, but no, it does not count exactly the same as returning science to Kerbin. What I mean by that is that if you take an experiment to the lab and process it there, then you get some amount of science eventually, but it does not count at KSC as a returned experiment. The science returned by the lab is more of a 'general science' point value that is not specific to any experiment, much like the science you get from some contracts, strategies, and world's firsts. The MPL has other uses, too: it can store duplicate science experiments and reset one-time experiments such as Mystery Goo. Scientists can reset Goo as well but the lab can do it without needing an EVA, which could be important on some missions and is convenient on most missions. If you have your game set so that kerbals need to return to Kerbin to level up (though I don't know why anyone would choose that setting now that there's a choice) you can use the MPL to award any pending experience and level up the kerbal while you are in space.

@Vllama87: Clicking the box in the resource tab will show you all the parts that have the selected resource (as you have discovered) but it does not open the transfer dialogue. For that, you need to Alt+Right-Click the tanks. To do that, you have to be able to select the tanks, which is an argument against clipping. However, you can get around that if you position the camera inside the part that you've clipped your monopropellant tanks into (this may require some tricky camera work and zooming; don't be afraid to use the 'Aim Camera Here' button on different parts if you have trouble), because then that part you're in will disappear and you will be able to see your clipped monoproellant tanks. If you're playing career, you also need some upgraded facilities to be able to do resource transfer, but if your buildings are all level 2 then you should be okay.

This is being discussed in the NFE thread: In short, there's a stock heat allocation bug, it is known, and it is being addressed. There was a workaround discussed that involved using MKS's distributed power mechanic, but that may not work in 1.3.1, and of course it would require you to send a separate power module to run your drills.

Unfortunately, I fear that your understanding is correct but incomplete. You have it correct that the argument of periapsis will change, but the change is predictable: when reversing orbital direction while holding apsis positions constant (meaning that the apsides will remain at the same points in 3-space, so you keep the semi-major axis and eccentricity), the inclination and longitude of ascending node will change by 180° and the argument of periapsis will become the supplement of its original angle. For example, if your original argument of periapsis is 78°, then the new one will be 102°. For angles greater than 180°, it may be easier to consider them in terms of negative angles (though it is still technically true; the supplement of 265° is 275°, which does add up to 180° if you take the full turn as a return to zero).