Zhetaan

@Lymark1: First, welcome to the forum. Enjoy your stay. Also, if you're planning a landing, then clockwise orbit (also known as a retrograde orbit) moves against the Mun's own rotation. This means that in order to land, you expend more fuel to match the velocity of a surface that is rotating away from you. To take off and make orbit again (assuming you want to go back to a retrograde orbit), you need to zero the velocity you have from moving with the surface and only then work to attain orbital velocity. Because the Mun is tidally locked to Kerbin, its rotation speed is very slow, so it's not a tremendous waste of fuel--but it is still worth noting. The reason the Apollo missions chose the free-return trajectory is because they: Had the fuel to spare, and Cared more for safety than for absolute fuel efficiency. Apollo 13 specifically proved that reasoning correct; if that crew had needed to make a larger correction burn ... well, let's just say that they'd have an eternal monument.

Have a link: And this:

Thankfully, this one is easy: There are a few ways to do this in stock; it all depends on whether you're willing to suspend enough disbelief to regard aeroplane parts as hydroplane parts. In any case, stock rover motors will not move you in water; if you go in the water, stock electric-only vehicles are right out. As far as terrestrial routes on Kerbin are concerned: they exist, but if you want to keep a near-circular route, then you will need to jump water at some point or another. That's because Kerbin actually has only one giant landmass (plus islands), but the ocean is lobed, in a sense. Eve is easier; there are polar routes that are terrestrial-only. That's because Eve's seas are separated from one another, though some of the coastlines are nothing but jaggedy fun if you're trying to find a pure overland route.

@Tyko, @Jimmidii, @severedsolo, @pizzaoverhead (And any others who would like to see suit 'chutes as part of a building upgrade and not Kerbal experience): I added https://bugs.kerbalspaceprogram.com/issues/17912 to the bug tracker, if you're interested.

I looked over the change log (I can't download until later today, unfortunately) but didn't see it: Can anyone please confirm whether they've added a 'Don't Show Again' check to the 'Warning: Only Scientists Can Restore This' box that you get when running the Goo and Science Jr. experiments?

@bjerrang: The table given earlier is rather cumbersome. Also, whatever a given solar panel's rated output, the EC produced is dependent on the same power source for all panels, so the distance-intensity relationship means that solar panels will see a percentage drop in output depending on distance that holds true for all panels. There are other factors, as well: I know that atmosphere affects power output and I think temperature may affect it also. The summary is this: a solar panel produces its rated output at Kerbin's orbital distance from the sun. We'll call that 100%. For other planets: Planet Intensity Moho 667.7% (May be affected by temperature) Eve 191.3% Kerbin 100.0% Duna 43.06% Dres 11.09% Jool 3.910% Eeloo 2.277% (average: this is for orbital distance 90.1 Gm) You need not quite double the number of solar panels at Eeloo to match the output at Jool. Call it just about seven panels at Eeloo for every four at Jool. Put another way, a Gigantor at Eeloo produces approximately 33.34 EC/min compared to the RTG's output of 45 EC/min. You'll need approximately two RTGs for every three Gigantors. That being said, don't necessarily drop the idea of solar panels completely. You can still scrape a bit of sunlight off the face of Gigantors, and they do produce plenty of power to run reaction wheels and the like when you are making your embarkation burn in the inner system. It's also not a bad idea to try using RTGs as maintenance-level power--just enough to keep the probe core warm and the radio on--and having fuel cells for the rest of it. Fuel cells make a marvellous backup power supply; they will supply power only when it is needed and shut off as your batteries fill. That keeps you from spewing fuel even when no one is occupying the station.

There are a couple of possibilities here. I'll refrain from repeating what others have said as much as I can. First, use Alt-X to cancel any trim in case you have accidentally set it. However, trim doesn't work when you use SAS, so if you're veering while using SAS (I don't think MechJeb counts as using SAS for this) then it isn't your trim. Thus the main reason that you veer off course is most probably due to a thrust offset that exceeds your gimbal capability and a thrust value that exceeds your reaction wheel or RCS torque. Because torque depends on both the force and the length of the lever arm, you can choose to modify one or both to get the result you want. If it's not a spaceplane, it's usually silly to use RCS just to fly in a straight line on a long-term mission (and temporary--you're out of luck when you run out of monopropellant), so adding more is not the best option. I will also assume that a complete redesign is not an option, seeing that you already have this in orbit. Symmetry is your friend, but since that ship has sailed rocket has been launched, let's try to fix the rocket you have rather than build the rocket you need. You can reduce engine thrust either differentially or unilaterally, but the drawback to this is that your burns will take longer. You can reduce the torque angle by adding a counterweight. If you want an adjustable counterweight, see which direction the vessel wants to veer and add a locked fuel tank to the other side. Putting this somewhere such that the line between it and the centre of mass is at right angles to the thrust vector is best but I assume that you don't have an abundance of docking ports, so use what you can. If the rocket starts to veer towards the side with the added tank, then transfer fuel out of the tank and into the core stack until it does fly in a straight line. Fuel isn't especially massive, though, so it may take a lot. An ore tank would work better, but you likely have fewer places to put ore. The drawback to this is that you add dead weight, so you lose capability (less delta-V, less acceleration, longer burn times, etc.) Of course, you can also shorten the lever arm; if you assembled this craft in orbit, then unless you have an engine right in the middle of the engine module (which you probably do--and I don't know how many engines you're using here--but it's worth mentioning), there's no reason why you can't move the engines closer to the middle of the vessel, or even the front (I use puller designs to move asteroids about). Just be sure you don't turn the rearward parts of your rocket into a barbecue with impinging engine exhaust. This means minding the gimbal angle, too. The drawback to this is that you lose some manoeuvrability: that should make sense because the problem in the first part is that your engines can spin your rocket round too easily. You also end up with a bit of 'clunkiness' in your design. On the other hand, the pretty rocket that doesn't fly is certainly not superior to the ugly rocket that does. Tweak it until it works, then ship it! ...Refinements can wait for Version 2.0.

High-level pilots and probe cores can point directly towards (or away from ) the target using SAS, but if you're asking whether the node creator in map mode will give you a handle that lets you easily plan an intercept, then no; that is something you'll have to do on your own. As you will discover, when dealing with orbital mechanics, pointing towards the target and burning the engine doesn't work unless you have already completed a rendezvous. The SAS target marker only points the direction; it's doesn't account for the fact that everything is moving, so the only time it also points in the direction to burn is when you and the target are already moving in exactly the same direction at exactly the same speed. The aerodynamic indicator is mainly for fixed-wing craft (meaning aero- and spaceplanes). For most rockets, it doesn't mean much. The centre of mass ought to be fairly towards the top of the rocket, though when it is fully loaded with fuel, it is acceptable for the centre of mass to be a bit closer to the middle. The centre of thrust should be where the engines are. This marker also has an arrow pointing out the bottom of it that shows the average direction of the rocket exhaust. What that means is that the rocket should move in the exact opposite direction--and if you draw an arrow exactly opposite the thrust arrow, it should go directly through the centre of mass. Achieving this is easy if you keep your rockets symmetrical.

@coguar: Your links are were broken, but I was able to see the photos anyway. Your problem is that you've matched orbits too soon; since both ships are in the same orbit, they orbit at the same speed; one will never catch up to the other. You need to put one ship into a different orbit so that it can catch up or fall back to the other ship. Think of it this way: let's say you have two balls and want to throw them so that they hit the ground at the same time. The problem is that you cannot throw them at the same time; nevertheless, they must still hit the ground at the same moment. If you throw the first ball, and then you throw a second ball along the exact same path, would you expect the second ball to catch up to the first so both hit the ground at the same time? Naturally, that won't happen. The way to do it is to throw the first ball very high up so it takes a long time to fall; then you can throw the second ball so that they both hit the ground at the same time. Therefore, the solution to your problem is to take one vessel (I recommend vessel 1 because it has more delta-V) and 'throw it high' by burning prograde. Normally, the way to get an encounter is to burn prograde if you're ahead and need to fall back or retrograde if you're behind and need to catch up, but retrograde in this case might drop you into the atmosphere (which definitely keeps you from catching up), so we want to avoid that. The amount that you need to burn prograde is something I can't guess from the picture, but we don't need to do that. Your orbit is just about circular, so where you burn is unimportant. Set a manoeuvre node some distance ahead of you (a few minutes at least, so you have time to plan properly) and, while still targeting the other vessel, pull on the prograde handle. The intercept markers will move with the predicted encounter, so keep pulling until the intercept markers align. You should be able to get an encounter under 5km very easily. Make the burn and wait an orbit until you come back to your burn location. When you do, your target will be there. The next thing to do is to go back to your previous orbit; in theory, this would mean burning retrograde by the same amount that you burned prograde before, but because there's probably a bit of difference in how your two vessels are moving, your best course is to match with the other vessel directly. You do this by clicking on the velocity readout at the top of the navball until it is in Target mode; this arranges the prograde/retrograde markers to align with your velocity relative to the target vessel. Burn retrograde in target mode until the velocity difference is zero; you will then have matched orbits. After that, it's simply a matter of closing the remaining distance and docking. Simple may turn out to be relative; it depends on your fine control. But at least you'll find out.

@Emil Alexandru: First, welcome to the forum. The good news is that you came to the right place to get help. The bad news is that at this point in the career, it would be very difficult to provide that help. I'm not saying that Jeb cannot be rescued--quite the opposite, in fact. The problem is that you don't have the means to rescue him right now. Part of that is that you don't have access to the high-level parts, part of it is that you lack Funds, and part of it is simple timing, which is to say that because he's on an escape path directly away from Kerbin right now, you're better off waiting until he's moving in a more convenient direction relative to the planet. Another part of it is technique--by this I mean to say that, for example, when you chased down his ship by going in the direction, even if you had caught him, it still would have left you with a ship that was escaping. You'd still need to burn just as hard to stop and come back. Since you got into this mess because your ship could go out but not come back, it's just the same problem over again, only with an additional lost pilot and wasted money. You mentioned that you can orbit and escape: that's good! To efficiently rescue Jeb, you're also going to need to know about transfers, rendezvous, and intercepts. You can learn about transfers by going to the Mun and Minmus. You can do rendezvous in orbit of Kerbin (or either of the moons). Intercepts (which I here define as combining transfers with rendezvous) will require you to work out trips from the Mun to Minmus, or vice versa. You can also do this with interplanetary journeys, but advanced transfer windows between the moons occur about every twelve to fifteen days and mistakes still leave you in Kerbin orbit, so you'll have more opportunity to practise them and less cost for failure. Once you have all of that, then you ought to be able to set up a mission to rescue Jeb. In the meantime, your missions to the Mun and Minmus can get you more science and Funds, which will allow you to buy the better parts and make a rocket that's capable of performing the rescue without being unwieldy. If it makes you feel any better, I timewarped my very first mission to the Mun and not only missed the capture burn, but got a gravity assist right out of Kerbin planetary space before I could slow time again. Jeb spent six years working on his tan in solar orbit before I had both a craft capable of rescuing him and the skills to complete the mission, but he did get home. You can do it, too.

@Vojta: First, welcome to the forum. I'm sorry to hear about your rocket trouble, but from what you've shown so far, I have a few ideas. Nine seconds is very specific, so it points to a problem with the design rather than with the piloting. I would expect both engine exhaust damage and staging issues to destroy the rocket more quickly, but it is worth checking both of those. However, I suspect that your main issue is a combination of too-flexible connections in your core stack and too much thrust. If your rocket flexes a lot before you release the launch clamps, that may be a clue. In that case, the boosters burn off fuel which decreases their mass, increases their thrust-to-weight ratio, and increases the severity of any oscillations to the point of rapid unplanned disassembly. Since the burn rate is constant, the destruction is predictable; hence it always happens at nine seconds. As to the thrust, I noticed that you reached a maximum gee force of 6.0 gees. That may be because of the way the rocket was destroyed (blasting the root part away at high speed will often trick the accelerometer) but it also says that you reached a speed of 213 m/s and at least an altitude of 1,120 metres. If you could do that in nine seconds, then I think you have too much rocket. Extremely high thrust will also stress the connections between parts and try to break your rocket apart. If the connection is even a little flexible, then the tip of the rocket (which, if well-designed, has most of the mass) will deviate from the thrust direction. Add the distance to the engine and you get a lot of torque on the joint; add extreme thrust and you multiply that torque to the point of breakage. Torque, for the lay physicist, is force times lever arm times the sine of the angle between them; in KSP, this is roughly related to thrust times rocket length times the sine of deflection. Given that the last item in your crash report is a linkage failure between a fairing and the base ring, I suspect very much that this is your issue--torque-related destruction is about the only way to get a base-fairing linkage failure in Procedural Fairings. I don't know how TweakScale deals with connection strength, but it's possible that when you take a small part and make it into a large part, it will not scale the strength enough, or it scales the mass or thrust too much, or what-have-you. If nothing else works, try a scaled-down version of your rocket and see what that does.

There's no good reason why they have to be exactly polar; the orbital synchronisation is only dependent on orbital period, and orbital period is only dependent on semi-major axis. In other words, so long as your apsides match, the satellites will remain in sync. (You can match SMA without necessarily matching apsides--there's a range of solutions--but matching apsides will guarantee a matched SMA, and since KSP actually gives you a readout for that, it's easier to do.) You can get a latitude readout from Kerbnet. It won't give you inclination directly, but the maximum latitude you see will be your inclination, and the point of zero latitude will be your node. If you're close to equatorial, you can probably get away with only paying attention to the zero point; lightly thrust normal or antinormal as needed when you cross it. For orbital period, you'll have to calculate, but it can be done with stock readouts. Also, the apsides given in KSP are altitudes from the surface, not distances from the gravitational centre; you'll need to add the diameter of Kerbin to get the semi-major axis. In KSP, you'll need to calculate it this way: T = 2π * √ ( [ (Ap + Pe + rbody) / 2]3 / [G * M] ) Where: T = orbital period, (Ap + Pe + rbody) / 2 = semi-major axis (apoapsis plus periapsis plus body diameter, all divided by 2), and G * Mbody = gravitational parameter (different for every body, but constant for a given body: universal gravitational constant (6.674 x 10-11) times body mass) I believe that both planetary radius and mass are given in the information window in either map mode or the tracking station. It may be diameter; be certain to verify for yourself. That being said, I will tell you that @Geschosskopf wrote an excellent tutorial and that the setup he recommends is absolutely my first choice when I need to have a minimum-fuel network for my far-flung probes, but for a more permanent no-blackout network, I prefer to do things a bit differently. I keep the low-orbit equatorial satellite, but I circularise my high-orbit relays at the apoapsis with ninety degrees' difference in longitude of ascending node. In other words, rather than have two orbits be co-planar, I set the orbits so that they 'cage' Kerbin; their orbital planes are both polar, but at right angles to one another. (For lovely word pictures, if you were to look straight down at Kerbin's north pole from far away, these orbits would appear to be an X.) I also set the satellites in those orbits so that when one is over a pole, the other is over the equator, and the polar satellite can always see the low-orbit satellite (so I want my 'low' orbit satellite to be quite a bit out of the atmosphere or off the ground; I don't want terrain or what-have-you to get in the way). This completely eliminates blackouts and requires a lot less finesse, but it also requires a lot more fuel and careful timing. It's only easy to do for Kerbin, but it gives top-notch coverage, which is what you really ought to have for Kerbin anyway. My go-to Kerbin network doesn't work so well when sending a fleet of com relays to far-away planets because those com relays will generally enter the sphere of influence from the same direction; changes to the longitude of ascending node are thus very expensive. On the other hand, it's trivial to adjust orbital inclination from just inside the sphere so that one satellite passes over the north pole, one over the south, and one over the equator. After that, your main concern is closing the orbit when you reach periapsis; only the equatorial relay needs a substantial fuel budget to bring the apoapsis down to circularise. Changing the timing to put the polar relays 180° out of phase is a matter of temporarily adjusting the apoapsis for one of the polar relays--still trivial and you get to use Oberth for extra fuel savings--so for initial communication at a new planet, it's an exceptionally slick system.

My advanced stations usually include a docking tug; it's essentially a flying monopropellant tank with a docking port (and maybe a claw; that would let you dock things with only one port by keeping the tug from occupying that only port). I use it to put together all of my modules while keeping the part count low; it cuts down the need for attitude jets and monopropellant on every module I add. I simply rendezvous 100 metres away (which I can do easily on main engines) and send the tug for the fine manoeuvring. It may be a bit late for yours given that you've already assembled most of it, but it might work for you if you want to give the station a finished look. I have also begun to include sample return modules on my dedicated science facilities. I use these when I want to get the greater value of recovery over transmission; it's sadly a one-time use thing, but if I have multiple experiments on a returning science mission and don't want to recover the lander (or don't want to take the time in the lab, or have repeat experiments and can't add them to the lab, or whatever), then I can use the return module, which has a science container, a parachute, a probe core, a heat shield, and just enough engine to reenter.

Good catch. I don't know whether it makes the mission doable, but you're right. Have a like. 18 m/s. Tylo is tidally locked to Jool, so that slows it down by a lot compared to moons with respectable rotation.

Something is going on with your upper-stage engine--or engines, most likely. Your lower stage has the same TWR and the whole rocket has the same mass so you didn't remove payload, but you went from a sea-level thrust-to-weight ratio of .08 to .14 between VAB and pad with no change in burn time. Absent an altered payload mass, that suggests to me that you have multiple isolated engine-fuel stacks mounted on the upper stage, but that for some reason, one or more of them was shut off in the VAB or else MechJeb was blind to it for some reason. If the engine-fuel stacks are identical, then the burn time would be the same, but the delta-V would be very different. On the other hand, are you using multi-mode engines? I don't know how well MechJeb handles engines that can burn fuel in different ways. Did you launch the rocket? Which value was accurate?

Well, you're not wrong about it being inefficient. However, that does not automatically mean that the turn is suspect. Rocket design and aerodynamic efficiency play a role, as well. This can range from the obvious issues such as pancake-shaped and heavily-greebled versus smooth and needle-shaped rockets ploughing through the atmosphere to less obvious issues such as a low thrust-to-weight ratio in your first stage. I'll assume that you have a good shape with no extra parts studded to the surface and a 'good' first-stage TWR of at least 1.2-1.3 on the pad. Try to keep your TWR below 1.6 until you have these turns figured out; too-high thrust at the start requires a more aggressive turn and it's better to understand why that is abnormal than to begin with it and assume that it is normal. Usually, I launch straight up until I get to either 100 m/s or 1000 m altitude, which generally occurs at about the same time; this is to establish some momentum and also to give the fins at the base of my rocket some wind to bite, which generally stabilises the rocket's flight. Turning earlier than that is valid, but it's more difficult to control because it's easier to overshoot the proper angle. At the end of the straight-up portion, I pitch the rocket about three to five degrees east and hold it there until the prograde marker pitches that far east as well. Some people advise setting SAS to prograde; I will tell you that a properly-designed rocket doesn't need it. You can shut SAS off entirely and it will fly to space on its own. Setting SAS to prograde is generally needed for either feel-good value for you or to help an otherwise-good but slightly-unstable rocket make it to orbit. @Human Person is right about aiming for about 45 degrees at about 10 km; use this as a rough guide, but don't revert if you hit 45 degrees at 11 km or something like that. For the rest of the rocket, I try to design stages to burn for about two minutes each with the possible exception of the third stage, since that's usually my orbital manoeuvring stage. Your second stage TWR doesn't need to be more than about .8 and it shouldn't need fins if you have a gimballing engine. Your third stage doesn't need to be more than .5 if you're using it to circularise; it can be a goodly amount less if you circularise on your second stage. Have a look at @Norcalplanner's Cheap and Cheerful Rocket Rules of Thumb for some ideas; the thread is old and has some formatting problems, but the ideas are solid. This link gives a better step-by-step guide on gravity turns, but it advises a pad TWR of 1.5 and an initial pitch of 5 - 10 degrees at 50 m/s. As you can see, there is some room for variation of style in gravity turns; the best thing for you to do is to go into Sandbox mode and try it a few times. Also, welcome to the happy collection of (only moderately) mad rocket scientists!

You've targeted the correct docking port and you're aligned. There's no reason why you shouldn't be able to dock. Remember that the target marker on the navball only shows the direction of the target docking port; it can't show the port's orientation. If you were to wear a GPS tag, for example, I could use a tracker to see where you were in terms of direction and distance, but it could not tell me which way you're facing. For that, you need either a mod or liberal use of the camera combined with a Mk. I eyeball. I would suggest that you not bother with trying to target the ship with the station. It appears to me that your station is fighting its own inertia when it tries to align with your vessel, and that is not good. I have the best results when I set the station to SAS-normal (that's the marker) and then dock to it; in other words, make the station as ... er ... stationary as possible, and let the smaller ship do all of the manoeuvring.

For simplicity, let's call the docker the Vessel and the dockee the Station. Try right-clicking on the Station's docking port and selecting 'Set as target' while you're still in control of the Vessel. Also try right-clicking on the Vessel's docking port and selecting 'Control from here'. I suspect that what you are doing (and the images in your first post seem to support this) is targeting the Station and leaving it at that, and the problem is that when you set a target in KSP, KSP defaults to pointing the target indicator towards the target's centre of mass. The centre of mass on the Station is nowhere near the docking port and it doesn't pay any attention to alignment, so even though you may be pointing the Vessel's docking port straight at it, the target on the navball doesn't make sense. The ability to right-click the other vessel's docking port and select 'Set as target' was specifically created to solve this problem.

It's not too difficult to solve for a suicide burn that accounts for horizontal velocity; the trick is to take your trajectory and decompose it into horizontal and vertical components. Then you can apply the gravitational acceleration only to the vertical component, solve for how much acceleration is needed in each direction to reach zero velocity at the same time, and compose the answers into your thrust vector, which is necessarily going to change direction as you descend because the vertical part has constant acceleration, whereas the horizontal part does not. It's certainly not something that you'll do on the fly, but it is doable with not-too-complex maths and so is well within the capability of a good autopilot if you want to install or write one. And you will need to install something; to do this calculation, you'll need to know the gravitational parameter of the body you're orbiting, your descent angle relative to down, and your exact distance to both the ground and the gravitational centre of the body--all this is information which is available or calculable, but none of it is given in the standard KSP HUD. One of the more common new-player approaches involves reducing the horizontal component to near-zero while still high up and focusing on the vertical component only on the way down. Because the horizontal velocity is zero, it's an easier calculation, but it's also horrifyingly inefficient--any net gain from the suicide burn is lost in the amount of burn required to cancel the horizontal velocity to zero in the first place and again in cancelling the gravitational vertical velocity acquired on the descent. On the other hand, you can employ @Starman4308's trick of using what's called a trivial solution to solve the problem low enough to stop you near the ground and quickly enough to leave a bit for pilot reaction time: drop your periapsis to just above ground level and while there, thrust to hold the vertical velocity (and acceleration) at zero (the readouts are accurate for that) and use the rest of your engine's thrust, without bothering to see how much it is, to reduce the horizontal velocity only. You still need to constantly change the thrust angle relative to gravity, but with a simple readout to tell you whether you're holding zero vertical velocity, it's easy to see how to correct. Once the horizontal velocity is zero, then you can shift focus to the vertical and manage a controlled descent. It takes longer than a straight suicide burn, but so long as you don't go down you're not going to hit anything, and if you set your orbit so that you perform the manoeuvre while close to the ground, it leaves you with only a few m/s to cancel out when you make your final landing. The real beauty of it is that it allows you to make a very efficient landing without requiring a physics degree and a bank of computers. @Delay: I think that what @Flavio hc16 meant by saying 'as soon as you move just 100 meters' is that even with an actual-distance-to-ground altimeter, the value given is for the distance to the ground directly underneath the spacecraft. Since terrain is sloped and quite variable, drifting by 100 metres in any sideways direction would skew that figure and leave you at the end of the burn ten metres too high or, worse, too low. I agree with your simple expedient of adding extra velocity in order to ensure an above-ground stop, but there is a point to the concern.

To do that, you would have to change the definition of gravity in the game and make it a finite-ranged force. If you do that, then it isn't gravity any more, and in any case, leaving such a hypothetical SOI is identical to leaving the universe (and in a departure from modern cosmology, the KSP universe nods to Galileo and Copernicus by making the Sun the centre of it). If I'm not completely mistaken, you can leave the KSP universe every time you quit the program[citation needed]. Of course, your spacecraft can't, but if you were to somehow rewrite KSP to let you take a craft with you and run it all over your desktop, then although it's an interesting idea, it wouldn't tell you anything about the behaviour of the stock program what with the program no longer being stock. It's not really a proper question to ask how something will respond when you do something that exceeds its constraints, except perhaps to characterise the type of overflow error that would result. That's somewhat like asking what happens to the characters after the end of a book--the question has no meaning in the context of the story because everything that happens to the characters happens in the pages of the story, and if more was supposed to happen, then it would have been written. This happens in a way with sequels, but that's no longer quite the same story.

Given the timing, I wouldn't worry. @Just Jim will be back just as soon as you can say Form 1040 or Offshore Account. (Key West doesn't count, Jim! Save your money!) On a more serious note, there are a few possibilities when it comes to alien biochemistry. If you believe in panspermia, then it is possible for the Laytheans and the Kerbals to have somewhat similar metabolism and nutritional needs. That, in turn, would depend on the relative complexity of the progenitor cell--a primordial bacterium that lacks chloroplasts means that Laytheans and Kerbals might be susceptible to the same diseases but subsist on totally different food sources. Food for one could be poison for the other. On the other hand, Laythe plants could be adapted to be hyper-efficient in the use of the much weaker sunlight (3% of Kerbin) at Jool, or they could be adapted to extract more chemical energy, which Laythe ought to have a lot of for a number of different reasons. If KSP modelled radiation and tides, Laythe would be a lot more active; the amount of electrical exchange between Jool and Laythe could fill the place with high-energy nitrates. If you believe in deliberate seeding or in exactly congruent co-evolution (which can be a component of panspermia), then it's probable that the Laytheans and the Kerbals are biologically compatible. That's not to say that you could have interbreeding (Spock is most likely a biological impossibility), but they could eat one another's food without problems aside from the usual risk that some plants may produce poison, and different species can be poisoned by different chemicals. Mint's cooling sensation on the tongue is mostly pleasant to us but it gives small mammals a very bad day. Chocolate is great for humans but bad for dogs, and so forth. Caffeine is an insecticide. Onions make you cry because they don't want to be eaten ... you monster. And don't even begin to speak about fugu. The point is that Laytheans may be perfectly able to eat Emiko's tacos ... but maybe they won't taste right unless they have a drizzle of machine oil on top (for extra hydrocarbons to simulate the water back home) or a coating of dried rotten bugs (for that slimily piquant hint of chitinous crunch!), or something like that. If you believe in autonomous biogenesis (this is the 'life finds a way' camp), then it's possible for Laythean and Kerbal life to be completely alien to one another. Clarke touched on this in his book 2061: a ship had crashed in Europa's sea and a crew member's body fell overboard, whereupon it was eaten by a large Europan shark-like creature. A minute later, the creature vomited and died, inadvertently confirming that there was no food to be found in the alien biosphere of Europa. Given that the Laytheans stole food, the second possibility is most likely, but given also that we don't know how long the Laytheans have been living on Kerbin, it's possible that they began in one of the other two camps but though extreme selection or deliberate modification (their own or a benevolent boulder's, perhaps), they adapted to be able to survive on Emiko's tacos. Of course, aliens being alien, it's possible that we've got it completely wrong and the tacos aren't food for Laytheans at all. It said that the Laytheans were relieved at the sight of food, but they never actually ate on-screen. Maybe the Laytheans need the tacos for some kind of religious ritual that dates all the way back to the ancient scrolls. Maybe Emiko is superimposing her own judgement on the Laytheans' actions: she sees the tacos as food, so she's making an unconscious assumption there. Maybe the Laytheans are hungry, but they can only eat from their hidden on-base food synthesisers ... which happen to be powered by a Tacomak Fusion Reactor .... Okay, I couldn't resist that one. I probably deserve the beating. But what else were the Laytheans supposed to think? They've been waiting all this time for the Kerbals to develop a fusion power source so they can go home (and the Grand Kerbal banning nuclear technology had to be a disheartening blow), and then when a neutrino source shows up not one hundred kilometres away, of course they grabbed the container that looked as though it had tacompatible reactor fuel .... Yes, I'll stop now.

@Dman979 is far more tactful than I. I would have said that the green head was the dead giveaway. Anyway, the story comes when it comes. Just be certain to pop in every now and again and wave your cavalry hat to remind us you're still around, if you can. I don't know how many of the supremely dedicated mod maintainers read this (I love your work, by the by, @linuxgurugamer--you keep KSP alive for a lot of people), but I think we can all agree that Community Kerbfleet Continued Redux is something we'd like to avoid.

Here's a picture. That's in the tracking station; you find it with the 'Object Info' button. Here's some more information about it.

@Streetwind, @PrvDancer85, @Starman4308, @Spricigo: Here's the update. I kept getting weird numbers when I tried to fit the curve. My initial guess values tended to be off a bit--which I expected from trying to use a quadratic fit on a cubic spline--but when I tried to fit a cubic, I started to see values that didn't make any sense, especially for Eve. Either KSP or Unity is doing something odd with the spline, and since I don't need to bother figuring out the equation when I want obtainable data points, I decided to get empirical data instead. That means that I strapped every engine in the game onto a sandbox monstrosity, turned on all the cheats, and went to every planet with an atmosphere. Duna has no sea-level terrain; I believe the lowest elevation is about 170 metres but I don't know exactly where it is, so I decided to use a spot at about 270 metres. Cutoff pressure is taken from the configuration files. Normal LFO engines: Engine Vacuum Duna Laythe Kerbin Eve Cutoff Pressure (atm) Ant 315.0 299.4 160.0 80.0 0 3.0 Spider 290.0 288.1 272.5 260.0 114.1 8.0 Twitch 290.0 287.4 266.1 250.0 83.8 7.0 Spark 320.0 316.4 289.5 270.0 88.9 7.0 Reliant 310.0 307.1 278.9 265.0 88.2 7.0 Swivel 320.0 315.7 268.9 250.0 48.4 6.0 Terrier 345.0 327.7 173.4 85.0 0 3.0 Vector 315.0 313.7 303.5 295.0 193.3 12.0 Dart 340.0 335.3 303.6 290.0 230.0 20.0 Thud 305.0 303.1 286.6 275.0 139.7 9.0 Mainsail 310.0 308.4 295.8 285.0 147.8 9.0 Skipper 320.0 317.4 297.2 280.0 57.4 3.0 Poodle 350.0 332.7 160.2 90.0 0 6.0 Twin-Boar 300.0 298.7 289.1 288.0 147.6 9.0 Rhino 340.0 331.1 252.9 205.0 0 5.0 Mammoth 315.0 313.7 303.3 295.0 193.3 12.0 Solid Rocket Boosters: Engine Vacuum Duna Laythe Kerbin Eve Cutoff Pressure (atm) Flea 165.0 163.4 150.2 140.0 28.3 6.0 Hammer 195.0 193.4 180.2 170.0 57.4 7.0 Thumper 210.0 207.7 188.9 175.0 35.0 6.0 Kickback 220.0 218.4 205.4 195.0 66.7 7.0 Jet Engines: Jets operate differently from other engines. Their Isp is always the Kerbin sea level value; the thrust varies with the velocity of the engine and a curve called atmCurve which is distinct from atmosphereCurve. Of course, there needs to be enough oxygen entering the engine to keep it from starving for the lack, but technically, the Isp on Eve or in space is the same as on Kerbin. Utility, Odd, and Other Engines: Engine Vacuum Duna Laythe Kerbin Eve Cutoff Pressure (atm) Nerv 800.0 759.3 375.7 185.0 0 2.0 Rapier 305.0 303.1 283.3 275.0 139.7 9.0 Puff 250.0 241.4 165.5 120.0 0 4.0 Dawn 4200.0 3927.2 1480.9 100.0 0 1.2 Sepratron 154.0 151.6 131.5 118.0 22.6 6.0 Launch Escape System 180.0 178.7 168.2 160.0 69.7 8.0 There were a few interesting discoveries here. One thing to note is that, in terms of performance, the Vector really is one engine from a Mammoth cluster; everything is exactly the same. Another is that the Spider is much, much more capable than the Ant in terms of atmospheric operation. This by no means is an assertion that the Spider is a valuable launching engine, but it does mean that you could probably make some fun glider drones with it, and these things would work on Eve, too--the Spider can operate at some truly high pressures. The Hammer cuts off at a higher pressure than the Thumper; if you are silly enough to take SRBs to Eve, then take Hammers over Thumpers because Thumpers at Eve sea level are operating too close to their limit, and the Isp values reflect this. The Dart is the only engine that operates at 15 atm; if you're even crazier than the one who took SRBs to Eve, then the Dart is the only thing that works at Jool's datum (zero altitude point). I don't know whether any rocket can climb out of that far down Jool's gravity well (pressure may be a problem before you get that low anyway), but the Dart is the only thing that can try.

@ATLUTD_741: You typed your program into the command line, not the text editor. The text editor is the box under the terminal on your second image. You created a new file, ran all of the commands one by one at the command line rather than typing them into the text editor, and then saved the empty file. When you tried to run the program, there was nothing in it to run. Technically, at least, you did run your first kOS script; it was just a null script. Does extreme minimalist programming count? Edit: Ninja'd.