Yakky

My efficient launch strategies: 1. Don't let your first stage thrust-to-weight ratio get too low. You want to accelerate up to terminal velocity as rapidly as possible -- ideally the instant you take off. Don't forget that every ten seconds you shave off your initial vertical ascent profile saves you nearly 100 delta-V by reducing your gravity losses. (But this is only true when you're moving significantly slower than terminal velocity. Above terminal velocity, you lose efficiency from the air resistance.) I've seen massive spacecraft with huge but nearly choked first stages that can just barely get things moving -- in such cases, there are huge rewards to spamming a bunch of initial cheap boosters to get things up to terminal velocity quickly. 2. It's OK to have a low(er) thrust to weight ratio in your upper stages, and this can often save a lot of engine mass. Depending on your trajectory, a TWR of as low as 0.6 on the final orbital insertion stage can work. Don't lug a heavy Kerbodyne/Mainsail/Skipper engine up to orbital velocities unless you absolutely need the performance later. Every bit of mass you can shave off your upper stages has cascading benefits. 3. This is even more true for interplanetary stages. Be patient and use one tiny engine. Do multi-pass orbital boosts to escape orbit. 4. Enter the lowest possible parking orbit. Don't waste fuel climbing higher than 75 km, and make sure your trajectory follows a smooth gravity turn. (Your optimal trajectory shape will depend on stage performance and whether or not you use FAR.) Also FWIW I find the Kerbal Engineer mod to be extremely helpful in understanding stage performance. It shows you you delta-V, thrust-to-weight ratio, and mass for each stage.

In your Mun examples (and in general when at least one of the orbits has low eccentricity), the closing speed of a post-apoapsis encounter is approximately equal to the closing speed of a comparable pre-apoapsis encounter, due to the conservation of energy and the symmetry of the situation. This is not the case if both you and the celestial body you're approaching have highly elliptical orbits with different arguments of periapsis. But fortunately, in those cases it's pretty obvious by inspection where the best (lowest relative velocity) intercept is going to be: you generally just want to look for the smallest closing angle (as others have said). The main benefit to a post-apoapsis encounter in my experience is that it can give you much greater flexibility in creating an encounter window. You can essentially dial in whatever "hang time" you like by boosting or lowering your apoapsis varying amounts above the target body so that you'll run into it on the way back down from your apoapsis. This can be nice when you don't want to wait years for a better interplanetary transfer window to come around. You can play with that in your Mun example by exploring how much flexibility you get to move your encounter window around when you allow yourself to play with the height of your apoapsis and then do a post-apoapsis encounter.

You may not like this one, but... from the top of the ladder is he close enough to manually fire one of the radial decouplers? Maybe you can unbalance the craft enough to get it to tip over that way, which might bring the capsule close enough to the ground to get him back inside. Of course it might also just blow up your entire ship, and even if it doesn't, you're probably stranded on the surface in an unflyable craft at that point. But at least your intrepid astronaut gets back inside the capsule to where his snacks are.

Any chance you also have a probe core on the vessel? If so, you could (gently) lift off the ground a few hundred meters while your kerbonaut is holding onto the top of the ladder, then shut off the engines and jetpack your kerbonaut up to the next ladder while the vessel is falling (i.e. in weightless conditions), then quickly fire the engines back up to ensure a smooth landing. ... or for that matter, just finish the surface mission and take off back into orbit with him hanging on the ladder, then get him back inside the capsule later. BTW I often stick a probe core on vessels undertaking long or complex missions precisely to allow more contingency options in case the need ever arises.

Yup, just realized the numbers are not presented the same way... but thanks for pointing it out. It does raise the possibility that impyre is basing his target orbital altitude off an incorrectly calibrated reference.

I just did some calculations based on the listed Kerbal Wiki orbit data, and it looks like the "on rails" Kerbin orbital velocity may indeed be wrong. Either that or some part of the Wiki data is wrong. Note that for a circular orbit, the orbital speed s = sqrt(mu/r) where r is the orbital radius and mu is a gravitational parameter. More importantly for our purposes, given two different orbital radii r1 and r2, and one corresponding s1, we can quickly calculate s2 as s1*sqrt(r1/r2). We don't even need to mess with mu because it conveniently cancels out. I plugged the following Kerbal Wiki data into that equation: Kerbol radius: 261,600 km Kerbol surface rotation speed: 3.8048 km/s Kerbol synchronous orbit altitude ("r1"): 1,508,045.29 km Kerbol synchronous orbit speed ("s1"): 25.6548 km/s (calculated from the three numbers above) Kerbin orbit altitude above Kerbol ("r2"): 13,599,840.26 km and perfectly circular (Edit: see my note below) Now, plugging r1, s1, and r2 into our equation, we get s2 = 9.16884 km/s. But Kerbin's orbital speed is listed in the wiki as 9.2845 km/s, which doesn't match. So if the Kerbal Wiki data is to be believed, that right there tells us something is inconsistent. So while I haven't fired up KSP to verify what you said, from this math it looks like your suspicion is correct and staying in a Kerbin-following or Kerbin-leading orbit is impossible. But it also seems to me that someone would have stumbled across this already. Am I missing something obvious here? Edit: It turns out that if Kerbin's listed orbital radius is taken as being from the center of Kerbol while the kerbosynchronous altitude is interpreted as being from the surface of Kerbol, then the calculated speed is 9.28446 km/s which pretty much matches the listed speed. But I don't know if the orbital radius is defined that way or not. Seems like one or the other value should be updated in the wiki so they are defined consistently. And since your in-game altitude display is shown relative to the surface of the celestial body you're orbiting, you might be off from the correct altitude by 261,600 km if you're basing your satellite's altitude on some reference that is relative to Kerbol's center (such as the wiki). (I have not launched KSP to look at what altitude Kerbin is shown to be orbiting in the game. Is it above Kerbol's surface or relative to Kerbol's center?)

It's one of those hush-hush marketing contracts Maxmaps has been hinting at. Squad has signed a joint marketing agreement with one of the big mouse clicker manufacturers and as part of the deal, they have to deliver a minimum number of clicks from their user base.

I suspect you're right. But maybe with a big asteroid so that there's an increased chance of collision detection while the two objects are overlapping? Not sure, just curious. Shrinking the delta physics time is one potential solution. But then the game will crawl...

Still could work if you start burning before you enter Moho's SOI. Basically you are going to equalize your orbit to nearly match Moho's, then drift into its SOI at a slow rate of closure. Think of it as docking with Moho. You make Moho your target, then when you get close (but still outside the SOI), you burn retrograde to your target velocity indicator on the nav ball in order to slow your closure rate, same as for docking. Remember the distances will still be huge compared to a normal docking, so don't cut your closing speed too much -- just enough so that you can successfully finish the job once you enter the SOI.

Yes, the guy who designed that mission was fired. Literally. Under a rocket engine.

Even with staged dropping of the LV-N's, your final TWR is still so low that you're going to burn a lot of delta-V just fighting gravity losses during the later stage of your descent. If your TWR is only 1.18, then once your horizontal velocity gets significantly below orbital speed, you end up using 1.00/1.18 = 85% of your delta-V just to fight off gravity. That doesn't leave much for positive control of the spacecraft. It also means that once you're in terminal vertical descent, you can only slow down at 0.18 of a G. Although I don't know exactly how the MechJeb landing algorithm works, MechJeb is probably crashing because the spacecraft just won't slow down as much as MechJeb needs it to. This is also why you're running out of fuel even though you theoretically have enough delta-V for a Tylo landing. Even if you use the approach articulated by others here (come in shallow and then slowly transition from horizontal to vertical burn as you lose speed), there is no getting around the fact that it will take you a long time to slow down and you're losing a ton of delta-V to gravity losses along the way. Edit: see this post for a quantitative look at the delta-V penalty incurred by landing with low TWR. Your gravity losses are, roughly speaking, proportional to the time spent in powered flight at speeds significantly below orbital velocity. If you have a massively high TWR that can slow you from orbital speed to a dead stop in the final few seconds, you will lose almost nothing to gravity losses. For this reason it may be worth lugging a huge engine to Tylo despite the extra mass.

I personally have used retrograde orbits for the thrill factor. If your equatorial LKO is getting crowded with satellites, consider adding a few retrograde sats so you can have the thrill of watching objects race by at closing speeds of nearly 5000 m/s. It conveys a palpable sense of just how fast orbital velocity really is. I've challenged myself to put a satellite into the same (but retrograde) orbit as another satellite to try to get them to collide. In fact, once in a late game after I'd run out of other things to do, I once launched a fleet of 60 "Kessler" sats into retrograde LKO to see if I could generate high-speed collisions with my other sats. Turns out actual collisions are really difficult to achieve, but even the near misses can be thrilling to watch. BTW might be interesting to put a large asteroid into retrograde equatorial LKO. It might be big enough to get some actual collisions. Has anyone done this?

I've created a two-digit entry system that generates a number from 0 to 99 (using Stayputniks as counters) just by typing "00" through "99". Here's how it works: 1. The first key press generates the tens digit by simply retrieving 10x the number pressed, which isn't very hard. It drops clusters of ten Stayputniks and jettisons (with rockets!) every cluster that isn't needed. To keep part count down, I just have it drop clusters of ten rather than ten individual cores, but the logic would be the same if it were dropping individual cores. 2. The trick was coming up with logic for the ones digit (second number pressed) that drops 1x the number of Stayputniks requested on the second key press, regardless of what the first key press was. I finally figured out a way to do this using some clever toggle logic with two consecutive cargo bay doors. Instructions for Use: Just type your number with a reasonable pause between digits. No other keys or actions needed. It works for all 100 numbers from 00 to 99, including repeated digits. Craft file here. Some pics showing the number 27 as an example: Here's what the machine looks like before firing computation. As the "2" key is hit, two clusters of ten Stayputniks are dropped while the others are rocketed far, far away. Then when the "7" key is hit, seven more Stayputniks drop to the ground for a total of 27 Stayputniks. Launch pad integrity not guaranteed for numbers below 30. (BTW yes, all the Stayputniks survive the launch pad inferno. It's easy to modify the design slightly to make the rockets avoid hitting the pad... but what would be the fun in that?) This version does not attempt to do any math, mainly for part count and time commitment reasons. This basic two digit entry machine is already 258 parts and took me a few hours. That said, I'm sure it could be done if someone wanted to take the time to do it. Similarly, I expect this approach could be generalized to handle 3-digit and larger numbers, but the part count would quickly become intractible if the system needs to have individual Stayputniks. If poker chip-style markers are allowed (e.g. different probe cores for 1s, 10s, 100s, etc), I suspect the part count would only grow as O(log(n^2)).

I use the Trajectories mod with FAR and have found that it sometimes undershoots quite a bit. Frankly I haven't spent enough time investigating why this is, so I can't offer too many thoughts on whether it's correctable or not. I have learned to manually correct for it based on the type of craft and the steepness of the re-entry trajectory. The undershoot seems to be worse on shallow re-entry angles and heavy atmospheres like Eve. Note that Trajectories has settings to let you define what angle of attack you're going to have at various stages of the re-entry. It's important to adjust those to get meaningful predictions. Re-entering sideways in FAR yields a very different trajectory than head-first or butt-first. Trajectories also doesn't seem to understand aerodynamic lift too well if you're flying winged vehicles. While it does take entry angle into account, my conclusion is that it still assumes a ballistic flight path (i.e. only thinks about drag effects, not lift). Somebody correct me if I'm wrong here... but anyway... Re-entering a lifting Space Shuttle type vehicle that can actually glide pretty well in the atmosphere can lead to overshooting the Trajectories estimate. What Trajectories does very well in any event, however, is help map out the impact of planet rotation when you are still many hours or days away from re-entry. The Trajectories "X" is still going to be in the right vicinity and then you can simply correct based on experience to get a pretty good line-up. None of this is to rain on the Trajectories mod parade... it is a terrific mod and I'm very glad to have it. What it's trying to do is just very hard to get right.

I made a video demonstrating my Kerbal rocket multiplication rig:

Sure! Here's the craft file for my 6x6 multiplier... just credit me if you do anything cool with it. BTW I recommend launching from the SPH rather than VAB so that you have more wide-open flat space. :-) Instructions: 1. Press space to activate 1st stage. 2. Enter 1st number to multiply (1-6). 3. Press space again. 4. Enter 2nd number to multiply (1-6). 5. Press space a third time to, uh... "calculate". 6. (Optional!) Press space a 4th time to clear away most of the truss structure. Or you can leave it. 7. Count your winged rockets on the ground at the launch pad... that's your answer!

I've come up with a Kerbal technique to handle multiplication and have built a demonstration device that will multiply any two numbers from 1 to 6. It consists of 36 two-stage rockets (arranged in six groups of six) that are clamped to the launching rig by their upper stages, and works like this: 1. All lower stage rocket motors are lit, but no clamps are released. 2. A key press from 1 to 6 will shutdown from 1 to 6 lower-stage motors within each group of six, leaving the others going. 3. Lower stages are separated. In cases where the rocket motors are firing, they simply rise up and push against the bottoms of the upper stages. In cases where they have shut down, the lower stages fall away and are destroyed. 4. All upper stage motors are lit. Clamps are still not released. 5. A key press from 1 to 6 will again shutdown from 1 to 6 of the groups (i.e. not the same assignments as for the lower stages). The lower stages that are already firing are not affected, because they have already been separated. 6. Rockets are released. Any rocket that has a lower stage or an upper stage firing will be lifted up and away, and are eventually destroyed. 7. Any rocket that has neither the upper stage or lower stage firing simply drops onto the launch pad and is counted. 8. Count the total upper stages on the pad... that's your answer! I have tested it many times and it works (aside from the occasional stray upper stage that tips over and explodes. Edit: Craft file is here. I recommend launching from the runway (SPH) rather than launch pad (VAB) so that you have more flat space. Otherwise a result bit will occasionally tip off the launchpad and explode, as in the pics below. Calculation Instructions (basically a restatement of the above, but more streamlined here: 1. Boot up the system by pressing space. No need to adjust throttle. 2. Enter first number 1-6. 3. Load the number into the register by pressing space again. 4. Enter second number 1-6. 5. Compute by pressing space again. 6. (Optional) Clear away some of the machinery by pressing space a third time. 7. Count your upper stages to get your answer. Pics below: Here's the craft on the pad before "calculating": We will multiply 3 x 5. Here the first stages have been lit, and 3 in each group have been shut down by pressing the "3" key: All stage separators are fired and the upper stages are lit, leading to some mayhem as three lower stages in each group (no longer running) fall away and are blasted into the ground by the rocket wash of the upper stages. The remaining lower stages continue to burn, but are now disconnected and won't respond to any more keyboard input. Next, the "5" key is pressed, shutting down 5 of the 6 groups of upper stages. (Note that the lower stage engines are still burning as before because they're not connected and don't respond to keyboard input anymore.) After pressing the "5" key, we release all the rockets. Some that have no engines burning fall to the pad, while others depart for destinations unknown! Once the smoke clears, we count and find exactly 15 upper stages on the pad! (Well, actually one of the 15 fuel tanks exploded, but we still plainly see the three wings and engine of the 15th upper stage. So if we count sets of wings, or if we count engines, we get 15.)

FWIW I run KSP on a Mac with 32 gigs of physical RAM and still have these problems, so I don't think the main culprit is a memory paging or swapping issue, although it's possible that it could compound other problems.

At the risk of necro-ing this thread, I was doing some research on the same topic and wanted to share my results. Wmheric covers the case of a 90-degree plane change, but what if you have some other plane change angle you need to perform? I did a bunch of Mathematica calculations to come up with a more exact answer. For a circular (or nearly circular) orbit, the distilled version is pretty simple: -- For plane changes of less than about 45 degrees, you're best off to just do them directly. -- For plane changes from about 45 to 60 degrees, you want to first raise your apoapsis to about double the periapsis* (and make sure to orient your burn so the apoapsis lines up with the plane change node!), then do the plane change, then lower your apoapsis again.** -- For plane changes of more than about 60 degrees, you want to raise your apoapsis as much as possible (to the edge of the SOI), then do your plane change, then lower your apoapsis again. * Double relative to the center of the planet, not to its surface. So if you're orbiting Kerbin with its 600 km radius at an altitude of 100km above the ground, you are actually 700km above the center and would therefore need to increase that to 1400 km from the center, which is to say 800km above the surface. ** This is an approximation. The actual optimum is to use a higher and higher apoapsis as your required plane change angle increases from about 45 to about 60 degrees, but you will be darn tootin' close to optimal if you just use a 2x increase as a rule of thumb. This Mathematica plot shows the required delta-V of doing the plane change directly vs. using the bi-elliptic approach. The blue line is the delta-V required by a direct burn (as a fraction of your current V). So for example, if you want to make a 180-degree plane change (i.e. stopping and reversing direction), it will require 2.0x your current velocity, which makes intuitive sense. The orange lines show the total delta-V of the bi-elliptic approach. The steeper orange lines are for smaller boosts to your apoapsis, while the totally horizontal orange line is for an infinite boost to your apoapsis. A couple interesting things jump out from the chart. The first is that if done optimally, no plane change should ever require more delta-V than about 85% of your current speed. Why? If you increase your apoapsis to infinity (or thereabouts), your orbital velocity falls asymptotically to zero, so it costs you nothing extra to do any plane change you like. All of your delta-V is spent on the apoapsis maneuvers and a vanishingly small amount is required for the actual plane change. The second interesting thing is that there's a surprisingly small range where the optimal amount of apoapsis boost varies. Below (about) 45 degrees, you are best off to just do a direct plane change, and above (about) 60 degrees, you just want the largest apoapsis boost you can get. And between those two numbers, simply raising your apoapsis to double your current orbital radius will get you most of the possible benefit. (BTW the curve for doubling your apoapsis is the 2nd steepest orange line. The steepest is for a 1.5x increase.) (Remember when we talk about apoapsis heights here, it's relative to the center of the planet, not to the surface. So be sure to add in the planet's radius when calculating your burn altitudes.) That's pretty much it for circular orbits. The case for how to handle highly eccentric (elliptical) orbits is a bit more complex... I will try to come back to address it later if I have time to get through all the math.

One of my proudest achievements in KSP was getting to the Mun and back in hard career mode, fairly early in the game with no patched conics and no SAS. The no SAS was accidental -- I forgot to select a Kerbonaut who was a pilot and didn't realize my mistake until after liftoff. The experience definitely made me a better keyboard jockey... ... but being able to fly without SAS doesn't mean I enjoy it. It's a lot of work and a lot of stress. It quickly puts your left hand at risk of carpal tunnel syndrome!

There are lots of ways to implement it and I would leave it to Squad to do what they think is best. That said, FWIW I was just envisioning a choice of 5-degree angle snap or no snap. Five degrees should be good enough for just about any project, is compatible with all the usual symmetries (2-way, 3-way, 4-way, 6-way, and 8-way), won't ever try to twist things very far at docking, and still requires some amount of pilot skill to line up. I do like the idea of Sumghai's API framework that would give modders the ability to customize the details, of course. But for stock methinks it should be kept pretty simple.

BTW dynamic pressure is called "Q" on your FAR data display. Just watch for that number to get low enough. You don't need fairings anymore when Q gets negligible. It would actually be interesting to know what Q values are safe enough -- I just wait for it to get "really low" but I haven't run any experiments to see how low is low enough. Does anyone have any data points on what "Q" value causes extended solar panels to break off, for example? If the dynamic pressure is low enough that solar panels don't disintegrate, it's probably safe for most things.

Here's the specific procedure to follow: You send a Kerbal outside into space and have him grab onto the ML capsule. Then right-click on the capsule somewhere, and select "retrieve experiments" (I can't remember exact words but it's something like that). Then float your Kerbal over to the other capsule (CM) and grab onto it. Now right-click the CM capsule and select "store experiments". BTW this is the same way you can collect data from experiment modules and transfer it to your command pod. For example, you can stand next to an exposed Mystery Goo container and right-click it to collect the data. Then you can deposit the data in a command pod. This saves having to bring the Mystery Goo container home with you. You don't actually need to be grasping the capsule/object. However, you have to be in close proximity. If your Kerbonaut is too far away from the capsule in question, he won't be able to reach the capsule with his arms and the options won't be available when you right-click on the capsule. Hope this helps.

It will depend on how you define volume. Do you mean visual clipping surface? Collision mesh? Or some kind of bounding box (e.g. the smallest cylinder that will contain the object)? What is your goal in finding the highest density part? Depending on your goal, you might consider the toroidal aerospike engine, which has a mass of 1.5 in what is essentially a small flat disk with a spike poking out of it. With clever packing I would think you could easily get more than four of those in the volume of a Mainsail.

Always use protection to reduce the risk of unsafe re-entry, and never enter too fast.