Zhetaan

Connectivity in RemoteTech is governed by ModuleSPU (SPU means Signal Processing Unit) and, according to the source, all parts with ModuleCommand must also have ModuleSPU or else they will be controllable in real time. If deleting the Mark 2 Drone Core line from the cfg doesn't make it function without a radio link, then my first guess is that you have something somewhere that is searching for all parts with ModuleCommand and adding ModuleSPU. If you can find it, so much the better, but it may be possible to address that with a ModuleManager patch that adds the line: @PART[mk2DroneCore]:FOR[RemoteTech]:FINAL { !MODULE[ModuleSPU] {} } And see whether that does the job. If not, then you may be best off taking it up in the RemoteTech thread.

This is partly exacerbated by the fact that Vall and Laythe are in the same orbital plane; having some relative inclination between your initial and destination bodies offers you a chance to get at least a little help in setting up an encounter. Since you don't have that, you have to provide all of the inclination yourself. This is even more exacerbated by the fact that you're trying to get the correct polar orbit--the problem here is not the inclination but the longitude of ascending node, and the quirks of the Joolian system make it either exceptionally easy or exceptionally difficult to get encounters with the right longitude of ascending node, but without much in between those extremes. To illustrate: I will assume that you are starting in a Vall equatorial orbit. You burn to transfer and put a little normal thrust into the burn so you leave Vall's sphere of influence at an inclined angle. Let's assume that you can get an encounter with Laythe that is close to polar. The periapsis of this encounter is going to be near the equator--but to efficiently change the longitude of ascending node, you really want the apsides to be over the poles. However, you can't do that with an efficient transfer. This happens because while you orbit Vall, your motion relative to Jool is going to follow Vall's orbit. There will be some periodic oscillation because you are also moving relative to Vall, but the total motion will average to match Vall's orbit (as it should, because otherwise you wouldn't stay in Vall's orbit). Even if you begin in a polar orbit of Vall and leave its sphere of influence directly over the north pole, you'll still move mostly in the same speed and direction as Vall--your total inclination relative to Vall's orbit about Jool would be about three degrees. You can deflect the speed and direction but you can't ignore them. Any efficient transfer from Vall to Laythe is going to take advantage of the fact that they're moving in the same direction and plane around Jool (taking that advantage is what makes such a transfer efficient), and that in turn will cause you to enter Laythe's sphere of influence from the side relative to its poles. This will always put your periapsis at or near the equator whether your orbital path is equatorial, polar, or anything in between. As others have said, timing is important, but that will only work well if the craft you want to intercept also transferred in from Vall. If it had, then you wouldn't be asking here how to do it, so instead I will tell you why you cannot do it: orbital resonance. Vall and Laythe are in a 1 : 2 orbital resonance (meaning that Laythe orbits Jool twice for each time Vall orbits once), and while this makes transfer windows regular, repeatable, and fairly common, it also means that that same regularity makes all of those windows identical. There is room for some variation but if you vary it by too much then you'll miss the window altogether. This leaves you with a few options. First, you can try a bad transfer--if you get a Laythe 'encounter' where you just glance through the sphere of influence over one of the poles, then the periapsis will be over the pole. You will be able to close the orbit and adjust the longitude of ascending node fairly easily--in that order, because you'll need to bring big engines and a lot of fuel as you will have a lot of relative speed, not a lot of time to shed it, and no help from the Oberth effect. Inefficient transfers are inefficient for a reason. Second, you can try corrective burns after you arrive at Laythe. If it were me, I'd choose to make an equatorial Laythe orbit and then change the inclination at the correct point so that I can align the longitudes of ascending node at the same time, thus performing two manoeuvres in one burn. Third, if your interceptor is also a lander, then you can spare yourself a lot of aggravation if you simply land on Laythe's equator, wait until the orbit you want is overhead, and launch to match it, just as you would if it were Kerbin. If landing was part of the mission profile to begin with, then you should be in good shape--unless the craft you want to intercept has the fuel you need to launch from Laythe, in which case ... oops? Alternatively, you can take a more scenic route. Tylo is also in orbital resonance with Laythe (and Vall) so there may be something you can work with if you use Tylo as an intermediate. Pol orbits Jool but is not in orbital resonance with Vall or Laythe, so eventually, you are effectively guaranteed to get a transfer that has the correct orientation. I leave it to you to determine whether eventually will arrive in anything less than geologic time, and whether going to Pol to get to Laythe offers any fuel savings. Lastly, you can do something that is in between getting a good encounter from Vall and getting a transfer from somewhere else; you can set up an intermediate orbit between Vall and Laythe and time the transfer from that to arrive at Laythe with the right parameters to easily match your chosen orbit. Get into your intermediate orbit, make the node, and check the encounter. If you don't like it, advance the node by an orbit and slide it up the orbital path until you get a new encounter. Rinse and repeat until you get an encounter that you do like. Assuming that each new Laythe encounter occurs at a different point on Laythe's orbit (stay away from orbital resonance), then each encounter should also have a different longitude of ascending node. This is still theoretical--I prefer to correct from equatorial, as I said--so I don't know how well it would work, and there's no easy way to test without doing it, either.

@jonpfl: Without seeing your craft, I can't tell you specifically what to move in order to lower the centre of mass, but since it's already in orbit, you can't change it anyway. For that case, I agree with @ManEatingApe in that your options are either to hope that you have enough SAS control to force your capsule retrograde and ride it down with a death-grip on the stick or else to get it into a stable orbit and rescue everyone with a more reentry-stable craft. In general, for the part that is meant to reenter, you want to have heavier things at the bottom (such as the heat shield) and lighter things at the top (such as reaction wheels if you intend to recover them). This by itself is reason enough to stage away your empty tanks and recover only the capsule, heat shield, and parachutes--engines are often fairly heavy, but a large, empty fuel tank shifts the centre of mass upward and can cause a lot of problems when you reenter. Don't put a lot of electronic equipment on the capsule so that you can save or recover it, either--maybe you can do that with the lighter science experiments, but that's all. A capsule with a heat shield and a parachute is stable with the heat shield pointing prograde and needs no electric power to keep that orientation. If you flew a contract that paid for your rocket, then you can afford to get rid of the extra stuff anyway. If saving every possible penny on every possible launch is important to you, fly spaceplanes. For fuel flow, you can change the flow priority of the fuel tanks in the VAB. It may be an advanced feature that you need to activate in the settings--I don't recall because I've always used it. The idea is that each fuel tank is assigned a number, and fuel will flow from a tank with a higher number before it flows from a tank with a lower number. There's a lot of room to make changes: KSP increments stages by ten so you can make shift things around without much risk of interfering with other stages. For bottom-draining priority, you'd want to set it up so that the bottom tank has the highest number, then the next tank up is one less, and so forth until you reach the top of the stage.

@jonpfl: All right, I can still help you. While it's true that if you wait long enough, more pilots will appear in the Astronaut Complex, that doesn't address the basic issue of stranding them in the first place. Besides, you pay good money to hire those pilots; it would be nice to use some of them more than once, especially after you've hired a number of them and hiring new staff becomes stupidly expensive. Without knowing what kinds of missions you're trying to fly, I can't say much about your flying skills and how they are contributing to this, but even if you're a terrible orbital pilot, I will say that the root of your problem here is resource management. Obviously, you have the basics well-in-hand and can reliably fly a rocket to orbit (otherwise, you wouldn't have been able to strand every single one of your pilots in space), which means you probably have a good grasp, or can get a good grasp, on how to get back down again. What's happening instead is that you're not taking enough rocket to orbit to manage efficient in-orbit burns, and you're not keeping an eye on the fuel gauge, either. Knowing how much fuel you need to de-orbit and return to Kerbin is critical, and so is cultivating the ability to say, 'I need to re-think this,' scrap the mission, and get home while you still have the fuel to do so (especially if you've saved and reloaded, which means 'Revert Flight' won't work). For this, I say that you should take an empty probe-controlled rocket and fly it manually. You may need an antenna to keep a link to KSC (and thus be able to use nodes) and a bottom-tier probe core with Stability Assist would be nice (so no Stayputnik), but this is perfectly doable. Good rocket design will give you something that can reliably make orbit with a little nudge right off the pad (of about three to five degrees prograde) and no further control input from you except to touch the throttle. Designs for these kinds of rockets are all over KerbalX but you'll get more out of it if you try it yourself--also, I don't know what tech you have unlocked, so there's no guarantee that someone else's design is something that you can even use. Besides, given that you can reliably make orbit, this is a valid next step in developing your skill set. Go for tall, thin rockets with fins at the bottom and with fuel flow figured so that it drains from the bottom up--you want the mass to concentrate in the tip and the drag to concentrate at the base. Try one, and if it doesn't make orbit, revert, redesign, and try again. Next, you need to be certain that once in orbit, you can accomplish a rescue, so that means adequate fuel. First, this means efficiently using what you have, so take out any monopropellant--you won't need it. Rescue in this case means rendezvous, not docking, and you can accomplish that with a Terrier and thrust limiters. Don't take science parts, and you likely won't need more than a single OX-Stat solar panel and one small battery for power. Take out half the ablator from the heat shield to start and be ready to take more--you may not even need a heat shield at all, if you're careful. Keep the orbital stage short and you can use the capsule's reaction wheels; it'll be slow to turn, but it will turn. Second, this means avoiding the problem that got you into this mess in the first place, so I'd suggest having an FL-T100 or ROUND-8 tank in your last engine stage, but with the tank locked so that you won't accidentally use up the fuel until you unlock it. A low-mass rescue rocket should be able to reenter from any low Kerbin orbit on the contents of a ROUND-8, but the FL-T100 has the benefit of being the same diameter as the Terrier and the Mk. I capsule. Do that until you are comfortable with the idea of leaving a de-orbiting reserve, and then you can take out that tank--and if you forget and strand that crew, you'll know how to fix it. Finally, pick one pilot who is in a good, near-circular orbit close to Kerbin, and rescue that one. Rendezvous with that pilot's capsule, set relative velocity to zero (or near-zero; it doesn't have to be perfect as you won't be staying for long), and EVA the pilot over to the rescue ship. De-orbit the rescue ship and now you've got a pilot. Do this a few times. You may be tempted to put together some kind of massive rescue mission that will save everybody at once, but don't do it! You need to practise bringing one pilot home before you can get on to bringing all of them home. Additionally, if you've got your stranded ships on eccentric orbits, do your de-orbit burn at the apoapsis as this will take less fuel. Be sure to check your rescue rocket before launch; the VAB likes to auto-crew your rockets and that is a problem if you need a free seat. P.S.: This all assumes that you're stuck in Kerbin orbit. If you've managed to throw your pilots into solar orbit, you may be better off starting with a clean slate.

The first answer that comes to mind is that the delta-V you see is an idealised amount that assumes your burn is instantaneous. Reality spreads that burn over time and causes you to use more delta-V. This effect will be magnified by longer burn time, which in turn relates to available thrust from the engines. Therefore, the ion engines, being the weakest, suffer the most from it ... but that's a lot of loss. If you'll tell me the orbital parameters, I can run it through the equation and let you know whether your delta-V readout is bugged.

@jonpfl: You're going to have to get out and push. It's not strictly necessary, but since your apoapsis is above 650 km, you'll be waiting for hours for the tiny amount of drag you experience to slow you down enough to reenter. However, there is some good news: because your apoapsis is so high, you won't need to push much. Wait until you're at about your apoapsis, point retrograde, and send a non-pilot outside to give a push to the middle of the heat shield as was suggested earlier. If it's your engineer, then you can watch the KER readout and know roughly how close you are to being done. Because you're at your apoapsis and the apoapsis is so high, only a comparatively tiny nudge is needed to put your capsule below 50 km at periapsis, and that will shorten your braking time considerably. It is also possible that you are completely out of power. That's okay; it just means that you'll have to use your Kerbal's EVA navball to figure out where retrograde is (since your Kerbal shares an orbit with the capsule, retrograde for one is retrograde for the other) and you're probably going to end up pushing on the side of the capsule. That's okay; it doesn't have to be perfect so long as it lowers the periapsis. Just be sure that you don't run out of EVA fuel. You can always get back in the capsule and get more; ten pushes that get the job done are better than one push that puts you in a worse situation.

In fairness, he said they were stuck in orbit, which is not the same thing as saying that they were stranded in orbit; his pilots may simply be running missions and he wants to run more. @jonpfl, would you mind clarifying? Are your pilots stranded in orbit and you want to rescue them, or are you simply looking for more pilots so you can fly more missions at once?

Since the initial question was answered ... @Ignacio Urteaga: Kolonization (or MKS) is responsible for all of the extra professions. It also changes the way you hire Kerbals, though if you rely mainly on rescues, you may not see that right away. The Modular Kolonization System thread is the place to find out more about this, but in the interests of thoroughness, here's a link to the MKS Wiki page that details what all of those extra professions do. Also: Thank you for making me laugh today.

@ArmchairPhysicist: Have a look at @Pecan's excellent 0.90 Design Tutorial, Exploring the System. I strongly suggest that you use the PDF (it in the OP) rather than try to read it on the forum; the tutorial predates the last big forum switch. You'll probably find the most useful information in chapters three and five, especially five, because that covers the example Mun landers. However, do note that this tutorial is for an old-enough version of KSP that just about everything needs to be tweaked to work in today's version. For example, the 0.90 Nerv used LFO and for a lot of missions, you got better results with a Spark. However, the important part is that the principles of design don't change much even after taking into account things such as reentry heating and an atmosphere that's made of air instead of mud. With that in mind, you may find some ideas on how to get the result you want without feeling as though you are launching a full colony mission to the Mun for two hours. Next, I have @Norcalplanner's equally excellent Cheap and Cheerful Rockets tutorial that is quite a lot more up-to-date. It's still a bit outdated and has not seen a new post in over a year, but the designs there need much less tweaking. Where Pecan's tutorial takes the form of a structured campaign, Norcalplanner's is more a set of rules of thumb illustrated with examples. In other words, Pecan's tutorial gives instructions to duplicate exactly the example rockets and is intended for the complete beginner who starts knowing only which way is up but not how to get there, and Norcalplanner's tutorial is intended to guide one into building designs that fit the overall philosophy without starting from the same assume-you-know-nothing, take-by-the-hand position. I will assume that you're much more at the level of Norcalplanner's tutorial given that you can reliably (albeit expensively) reach the Mun and return. However, there is still good information to be gleaned from a 'back-to-basics' approach and I do not wish to deprive you of that. Good luck with your designs.

And if you'll permit it, I think the best elegy for Gregmore is yet older: With proud thanksgiving, a mother for her children, Kerbin mourns for her dead across the sky. Flesh of her flesh they were, spirit of her spirit, Fallen in the cause of the free. Solemn the drums thrill: Death august and royal Sings sorrow up into immortal spheres. There is music in the midst of desolation And a glory that shines upon our tears. They went with songs to the battle, they were young, Straight of limb, true of eye, steady and aglow. They were staunch to the end against odds uncounted, They fell with their faces to the foe. They shall grow not old, as we that are left grow old: Age shall not weary them, nor the years condemn. At the going down of the sun and in the morning We will remember them. They mingle not with their laughing comrades again; They sit no more at familiar tables of home; They have no lot in our labour of the day-time; They sleep beyond Kerbin's glow. But where our desires are and our hopes profound, Felt as a well-spring that is hidden from sight, To the innermost heart of their own land they are known As the stars are known to the Night; As the stars that shall be bright when we are dust, Moving in marches upon the heavenly plain, As the stars that are starry in the time of our darkness, To the end, to the end, they remain. I only had to change four words. Otherwise, everything fits perfectly. @Kuzzter, I'd say therefore that if your end was to use this story as a lens to project something important about human nature, you've succeeded admirably. @Chemp: Time to cheer you up (I hope) .... What does it say about us that Gregmore had to die to be remembered? That is an excellent question, but I think it focuses too much on his death and not enough on his life. Consider this: Gregmore has never, ever, in the entire history of his time with Kerbfleet, raised his voice in anger over people failing to remember him. In spite of what may be horrible mistreatment--we'll get to that--by virtue of his being continually forgotten, his last act was an insistence on seeing the good in one whom he refused to see as an enemy. Was that misguided? Possibly--the mistake did kill him. But it also saved Kerbin. Let's consider another case: Mort. Mort is known almost solely for his pursuit of profit, but don't forget that when he unveiled his plan to recall and retire Kerbal crews, part of the reason was so he could pursue low-cost and low-risk probe exploration, instead. He also told Bill and Jeb that he didn't want to risk losing them to Eve after Bob and Tedus. Whether his motives emerged from a belief that Kerbal lives were valuable or only from a belief that they were expensive, the point is that it was mentioned that risk was a motivator. Val's impassioned argument that the value of the lives is, at least in part, offset by the value of the experience of living is wholly beyond his understanding, but on the other hand, if Mort truly believed that Kerbal lives could only be measured in Funds, then one could expect him to own slaves. Instead, though none believe him to be unilaterally good, none consider him to be inherently evil, either. At most, he is seen as misguided, but not uncaring--doesn't that say something about us, as well? Back on Gregmore, we have his possible horrible mistreatment. But I'm not sure that's the case here. After all, I think it's a stretch to say that everyone else deliberately forgot him--I may as well tell you not to think about elephants. Really, don't think about elephants. You're not thinking about elephants right now, are you? Whether Gregmore projected some kind of telepathic amnesia or was simply eminently forgettable is irrelevant. Whatever was going on, he clearly was not in control of it--this was seen by how he kept trying to get people's attention--so he had cause to be extremely frustrated and upset. And yet we don't see that. If anything, he had every reason to simply snap, ram his Gliido into the Ghost's missile bay with explosive force, and let out all of that pent-up frustration in one grand and unforgettable explosion. He did not do this: he rammed into the missile bay, yes, but not to kill his opponent. Instead, he merely stopped his opponent and extended an offer of friendship and understanding. He died with that offer on his lips, which shows absolutely immeasurable restraint--by rights, his forbearance alone justifies remembering him as Saint Gregmore. I think that Gregmore happened to have a disability. It was unusual, certainly, but that's what it amounted to be. He refused to allow that disability to either define him or limit him, and when it came to his outlook on life, he could choose to wallow in it, or he could choose to acknowledge but surpass it. He wasn't perfect: the one time he chose to wallow in it, he tried to stow away aboard the Intrepid, but luckily for him, a friend came to his aid and he snapped back to himself. His weakness was that he wanted to be remembered so much that it clouded his judgement. The rest of the time, he surpassed the disability, even as he appeared to accept the flaws of those same friends who were limited by that disability--much like when a hearing person speaks to a Deaf person while facing the interpreter, it's rude but it's also (at least a little) understandable. What does it say about us as the ones who were limited by, or paid too much attention to, Gregmore's particular idiosyncrasy? It says we're not perfect. It doesn't say we need to be perfect. The presence of a larger-than-life hero does say that we need to be perfect. The heroic archetype gives us inspiration by showing something that is both virtuous and larger than life, but it is impossible to reach because larger-than-life means exactly that, and if we're always looking upwards, we're never looking inwards. This means that the hero is actually flawed by his apparent perfection, and understanding that paves the way to understanding a lot of human nature. The heroic sacrifice, in this way, can be a sign of a permanent maturation because the death of the hero is also a sign of one's acknowledgement that while the hero's values do not die with him, the example he sets is impossible to reach. I'll throw in another little bit that came out of Eve: Order Zero, spoken by Newdun Kerman: 'Sure, a hero that's some kind of super-kerbal can be a lot of fun. It's an escape, yeah. But the real heroes are the ordinary kerbs who find a way to do extra-ordinary things.' To wit, there was a time when we, as children, considered our parents to be perfect. Later on, we come to understand that our parents are people, often deeply flawed, but usually trying their best to make something good out of what they've been given. The fact that we know that the lessons came from flawed teachers doesn't invalidate their truth: it's still nice to share, you should always say 'please' and 'thank you', and you're not going to make a new friend unless you're willing to get out of the Gliido and extend the offer. Does Gregmore count as an impossible hero or a realistic hero? I'll let you decide that for yourself. So yes, it took Gregmore's death to make people remember him. That says some pretty awful things. But on the other hand, even though the cost was terrible and tragic, he is remembered. Perhaps the Kerbals will forget him again, and if so, then maybe they are, at their core, irredeemable. But that hasn't happened yet, and so I think the lesson here is that if you want to prevent such tragedies in your own life, the most I think we can do is get out of the Gliido, hope for the best, and find a way to do extra-ordinary things.

@linuxgurugamer: The main reason is convenience in the calculation. For a slightly more mathematically-inclined explanation, the reason is because the relationship of mass to delta-V given by the rocket equation uses the logarithmic function to take the endpoints of the continuous loss of mass (continuous over the expenditure of fuel, not over the passage of time) and then use those endpoints to describe the changes seen in delta-V over the course of that loss. In the rocket equation, these endpoints are naturally defined by the mass of the rocket at the start of the burn and the mass at the end of the burn, and in the most extreme possible case, this means the mass of the rocket when full of fuel and the mass when empty of it. However, the mass of the full rocket necessarily must include the mass of the empty rocket, so it appears on both sides of that relationship. Your information about ratios is correct, but I respectfully suggest that your information is incomplete: one must not confuse the colon of a ratio with an addition sign, because the colon of the ratio states only that a relationship exists--the exact nature of the relationship depends on the units of the values. For example, in the link you gave, one example ratio given is 1:3 as a ratio of boys to girls. Is it not equally valid to say that there is a 1:4 ratio of boys to children? Each description has its place and its use. One may even describe relationships that cannot add directly: for example, after every rapid unplanned disassembly, let's say the KSC sacks ten engineers. This implies a relationship--a ratio--of 10:1 unemployed engineers for each rocket failure, but that does not add up to eleven sacked-engineer-failed-rocket-hybrid-things, because although engineers and rocket failures are units, those units are not related by addition. (Correction: they don't add unless the KSC terminates employment with some gruesomely extreme prejudice.) To that end, the 9:1 wet-to-dry ratio for fuel tanks is useful for comparing theoretical maximum delta-V of a spacecraft in a convenient, ready-to-plug-into-the-rocket-equation form. The elegance of it is that if we take the rest of the rocket mass to be constant, we can use the mass fraction to decide at a glance whether one fuel tank is more or less efficient than another without having to go through the full calculation. By contrast, using the 8:1 fuel-to-tank ratio requires an additional step. It is still useful to compare tank efficiency, and one can even use it in the rocket equation (change wet mass to dry mass + fuel mass; it certainly isn't difficult), but given the fact that it is easier to get total rocket mass from KSP rather than fuel mass + part mass components, the 9:1 mass fraction is the convenient one. Similarly, the version of the rocket equation most often used for KSP is not the one that relies on effective exhaust velocity--even though that is easy to intuit, KSP reports Isp, not Vexh, so it is more convenient to incorporate the conversion into the rocket equation and use the values that display on the screen. Edit: For completeness's sake, here's a version of the rocket equation that uses fuel-to-dry-mass: ΔV = Isp * g0 * ln (1 + (mfuel / mdry)) Where: ΔV is delta-V, Isp is specific impulse, g0 is acceleration due to gravity at Kerbin's surface (9.81 m/s2), ln is the natural logarithm function, mfuel is the fuel mass, and mdry is the dry mass of the rocket. Nothing prevents anyone from using the 8:1 ratio, but it has to be used correctly.

Correct; you can enter an orbit such as you describe, but as the planet revolves around the sun, the day/night line (called the terminator in astronomy) will rotate around the planet as well, for one full rotation per year. Simulating an orbit that changes to keep itself always over the terminator that would require your polar orbit also to have a variable longitude of ascending node with the rate of variation equal to 360° per local year. However, KSP doesn't simulate orbital variation. The value of the LAN is treated as constant unless one of two things happens: either you execute a burn to change it, or you intercept another celestial body's sphere of influence (in which case the orbit technically remains constant; it is simply recalculated with respect to the new primary celestial). You may get results if you try it in Principia, which is an N-body gravity simulation mod. I would assume until proven otherwise that there is a way to simulate your orbit there, but I must confess to admit that I don't know how to set one up.

Not to backtrack the topic, but since this hit me well after I read it, I suppose it's a qualifying example: Kerbfleet: The Next Generation. #FridgeLogic

You should ask @Cydonian Monk; no one alive knows more about how to resurrect old and buggy persistence files. ... And I'm ninja'd by the man himself. Good work.

Even the devs fell to that one: I recall a Squadcast (link to 5thHorseman's summary) where Max had an absolutely terrible Mun landing Minmus landing orbit flyby come in too hot, somehow managed not to burn up on Kerbin reentry ... and blew his parachutes too soon. Max's quote is priceless. Of course, Max usually played terribly, but it was also usually fun to watch, and he took it in good humour. In that particular Squadcast, Max also forgot to turn his throttle up all the way ... so he added six more engines, instead. I hope it's archived somewhere; that one really was a gem.

Oh, Stelrine ... don't you know that when your only tool is an exotic-matter-powered trans-dimensional wormhole generator, all your problems start looking like interstitial spacetime fissures? On a much more serious note, the purple-tinted hurricane whirlpool is absolutely captivating. I had to remind myself to read the words in that panel. That was a truly marvellous feature: top marks.

To continue the animal theme, let's go with mammals. I'm not certain whether you're making individual craft for each biome, but that is my assumption because anything else would require a shorter list: therefore, this list should cover your needs. Ice Caps -- Caribou Northern Ice Shelf -- Lemming Southern Ice Shelf -- Crabeater Tundra -- Marten Highlands -- Wildcat Mountains -- Ibex Grasslands -- Aurochs Deserts -- Xerocole Badlands -- Bison Shores -- Platypus Water -- Beluga

I am minded of when Claw released his stock bugfix modules and then there was the occasional discussion over whether using them constituted a mod for all of the stock-only purists. Of course, Claw then went to work for Squad and all of the fixes became stock, thus ending the discussion. My contention is simply that, given the fact that we're in a pre-release anyway, it doesn't hurt to put the idea in the bug tracker. Actually, I think it is quite a bit simpler than what you described: if the devs add the 'Don't Show Again' checkbox, then it would be just as much a case of preferences or play style if you choose not to check it, in much the same fashion as sandbox mode is now a matter of preference, but it was not back when this was a sandbox-only game. My UI fix is your feature request, et cetera. But that position still leaves us with an impasse of opinion, to which I don't really have a defence. In any case, adding the option doesn't interfere with the auto-samplers, so that shouldn't be a point of contention.

@rocketBob: There is an equation, but it is not a pretty one. Also, inclination is not a problem provided that the orbital period is resonant with the Mun's rotational period. For example, a circular, Kerbin-synchronous, one-day, polar orbit will still pass over the same longitude once every orbit (that is, once per day). An equatorial version of the same orbit holds position over that longitude indefinitely. Intermediate inclinations and eccentricities show greater and greater apparent motion with respect to a surface observer, but so long as the semi-major axis of the orbit remains the same, it also remains synchronous (and the motion will appear periodic ... because it is). The equation for orbital period is this: T = 2 * pi * (a3 / GM)1/2 where: T = period a = semi-major axis GM = gravitational parameter, which for the Mun is 6.5138398×1010 m3/s2 In your case, the easy solution is to have your T equal to 138984 / n seconds, where n is some integer and 138984 is the Mun's rotational period in seconds. However, you don't want the period; you want the apoapsis, which means we need to rearrange the equation: a = (GM * T2 / 4 * pi2)1/3 To simplify this for the Mun, we can pre-calculate a number of the parameters and combine constants: a = (6.5138398×1010 * T2 / 4 * pi2)1/3 = (1.649974896×109 * (138984 / n)2)1/3 = (3.18718×1019 / n2)1/3 For n = 1 (a synchronous orbit), the value of a is 3.170556×106 m, which, less the 200,000 m of the Mun's radius, gives a circular orbit at an altitude of 2.9706×106 m. This cannot be used because the Mun's sphere of influence ends at 2.4296×106 m. For n = 64, the value of a is 198159.8 m, which puts the orbit under the Mun's surface. The reason this is undesirable is left as an exercise for Jeb's piloting. For n = 58, the semi-major axis is 211600.6 m, and that means a circular orbit at 11,600.6 m because such a low orbit is only barely enough to clear the Mun's mountaintops. It also means that you will have to wait 58 orbits to get a resonance. Keep in mind that for all of these values of n, the number of orbits is largely irrelevant; excepting cases of crash or escape, the orbits will add up to one overhead pass of your chosen landing site for every Mun rotation. The spacecraft will pass over the correct longitude many times--58, to use the maximum safe value--but those passes will also but for one be at the wrong latitude unless the landing site is on the equator. If the orbit could precess, then it would be possible to achieve your goal a little more often (at the cost of some truly frightening calculations), but precession requires n-body gravity. To take these values with a fixed Pe and obtain a useful Ap requires one more bit of mathematical wizardry. The semi-major axis is to an ellipse something like a radius is to a circle, but because it is an ellipse, you can have varying Pe and Ap values that still give the same semi-major axis. For the Mun, the semi-major axis is: a = (Ap + Pe + 400000) / 2 where the 400,000 is the Mun's surface diameter and the Ap and Pe are taken as altitudes from the surface (as KSP displays them). If we hold the periapsis at 15,000 m then the equation simplifies to: a = (Ap + 415000) / 2 and combining this with the earlier equation gives: (Ap + 415000) / 2 = (3.18718×1019 / n2)1/3 and once rearranged, this gives: Ap = 2 * (3.18718×1019 / n2)1/3 - 415000 This constrains n by quite a bit: for example, you can no longer go above n = 56 because that lowers the 'apoapsis' to below the periapsis. You can also no longer go below n = 4 because smaller values of n require either your Ap to be outside the Mun's sphere of influence or your Pe to be above 15 km. I will assume that your mission profile is such that you will prefer either a long, languorous time at a high Ap or a close-in, near-circular orbit. For this reason, my suggestions to you are to use either n = 4 or n = 56. For n = 4 and a Pe of 15000 m, the Ap is 2.101473×106 m. The orbital period is 34,746 seconds. For n = 56 and a Pe of 15000 m, the Ap is 18218 m ... approximately. The important thing is to make certain that the orbital period is 2481.9 seconds.

I created Issue #14922 and threw a bug report on the tracker for this. I'm just guessing that the issue exists on all platforms, but you're right in that it really does need to go. The warning made a lot of sense back when the only way to reset those experiments was with a mobile lab, but now that we can send Scientists to do it instead, a one-time warning with a 'Don't Show Again' checkbox is the best way to continue. I appreciate that mods to gather science for you (thus bypassing the warning entirely) exist, but I like the gameplay aspects of having a scientist climb out to gather experimental observations. The warning breaks immersion, but an auto-sampler denies it entirely--and in any case, this kind of thing ought to be handled in stock, if for no other reason than to help the console players. The mods fix the gameplay problem of the science grind, but at the core of it, this is really a UI problem. To wit, a lot of the spaceplane addicts would raise a tiff if the high-timewarp warning appeared, with no option to cancel future warnings, every time they flew; this is really no different.

@Kowgan: First, I'd like to thank you for your ongoing work on this; I have a very battered copy of this map printed out and taped to the wall next to my monitor. (Back in my day, we had to make our own KSPedia. We also flew up the gravity well both ways, and only had one space suit--it was sleeveless!) Second, I appreciate very much that you've included the return window cycle time on the map ... but unfortunately, I don't know how to use it. Does the indicated time index to the arrival in the system, or to the beginning of the initial transfer? In other words, let's say that I begin a transfer to Duna on Mission Day Zero. Being a perfectly nominal transfer, I arrive at Duna in exactly 300 days as indicated by the transfer time on the map. The return cycle gives a time of 2y 54d: does this mean that my return window opens on Mission Day 2Y 54D, or on Mission Day 2Y 354D (2y 54d plus the 300 days of travel time)?

That depends on the window; most orbits are eccentric. Most Delta-V maps include approximate travel times.

That's a tough one! In that case, I definitely urge you to put this question to the Challenges sub-forum. Maybe you can attract some attention from the KSP Caveman Challenge, too: for obvious reasons, most Eve ascents use high technology to achieve an economy of mass and part count, but I don't know of any attempt to do a Caveman-style Eve ascent, and they'd be the ones to take this idea and run with it. They're the people who know how to make orbit on a stack FL-T100 tanks that is stabilised entirely by wishing: they'd love this. ETA: I did a bit of checking, and if you can somehow find, buy, or steal a vessel with 1700 dV, then it is possible to use an Eve-Eve-Kerbin flyby transfer (assuming that Kerbin and Eve have the same orbital characteristics as stock in Eve Space Program), so that is the number you need to be able to do anything other than bounce about on Gilly.

You ought to look through the Challenges sub-forum to see whether anyone has figured optimal Eve ascents. If not, I suggest putting this question to them. You've already got your own attempt and the example craft; if you turn it loose among the people there I guarantee that you will get either the best humanly-possible ascent profile or confirmation that you already have that profile. A cursory first-pass search shows the Eve Rocks challenge (from version .90, so not at all the same) and a couple of lightest/smallest lander challenges, which all operate from the idea that whatever comes up is not going to reenter. The idea of an optimal ascent is probably touched on in those challenges, but the mission profile that starts on Eve with the intent of returning there introduces new difficulties that these earlier challenges simply do not address. As for addressing your Gilly difficulties, I'd suggest putting all of your focus on unlocking the Tier 5 Clamp-O-Tron Jr and the Tier 2 R&D (for fuel transfer). If you can make orbit with anything left in the tank, then you can make orbit with a tanker--even if that tanker looks suspiciously like a ship. The problem then is connecting to that tanker and extracting the fuel. Thankfully, you can get the part without a Gilly return mission. It will require some precision piloting, but you can fly by Gilly (total contact time will be minutes, given Gilly's sphere of influence, so I suggest having your science experiments on an action group--I often use landing gear or the abort group for the Tier 2 VAB). You may want to consider a big stack that launches a probe straight out of Eve's sphere of influence--no gravity turn at all is required on that one; it merely requires that you not overheat the rocket on ascent--and that will get you some solar science at the cost of having a probe on a weird orbit. Once that's done, the R&D upgrade, if you don't have it yet, only requires Funds.