Search the Community

I think I made a post about this a while back, and I agree. I would add one thing- the ability to plot a trajectory using the “fixed” point-thrust mode, then convert it into a relative one (approximately). One of the main issues with the new maneuver nodes is that you can’t just make a maneuver at your apoapsis to circularize- where you make your maneuver depends on the length of your burn. You should be able to make a maneuver in this simple mode, and have the game recalculate to find a true trajectory of best fit which approximately matches the trajectory you made in instantaneous impulse mode. I haven’t really thought this through, but I THINK this solves your cosine loss problem. The cosine loss is really just burning at the wrong time in your orbit. I THINK… PS if you have math that shows I’m wrong I’d be interested.

I made a Revan Orbiter for RSS Scale. Revan in RSS Scale is 10,400m/s orbit velocity, 85km atmosphere (actually 106km due to a bug), and 1.38g. The ASL pressure is 2.9ATM but due to a sigma dimensions bug it's 1 ATM, and rises to 1.7ATM before dropping like normal. That's an advantage of us, since we can accelerate at a higher TWR and get past the thicker bits faster rather than crawling up. The rocket probably would barely reach orbit without that. Separation of the booster stage. Very quickly, the first stage rotates from being 45 degrees above the horizon to almost at the horizon. The first stage also runs out very fast, and the apoapsis of the current orbit is 160km. The visual artefacts start popping up high above Welcome Back Lake. It's a scatterer+sigma issue, and the velocity is over 3000m/s. Due to the low TWR of the middle stages, it took 12 minutes to reach orbit and I suffered a loss in vertical speed during the ascent, losing up to 500m/s. I decided to kill the speed immediately rather than reaching orbit as pitching 30-40 degrees up gave us 60% of the boost from the pitch while only suffering 25% from cosine losses. I managed to stabilise the orbit at 110 kilometers, and it took 6 stages. Now in orbit. Still had some fuel left in orbit, so I decided to use the 4500m/s to escape revan. Final orbit sends us nearly to Vera's orbit. BONUS: Minmus SSTO in an LMP Server! No quicksaving or reverting flights. Couldn't plant a flag due to the fairing, since I needed to return. Managed to single-aerobrake the landing after slowing down using my remaining liquid fuel. Very unstable in flight and wants to go backwards, but I landed it on water, with the craft barely surviving. Part count is 50 and the mass is something like 40 tons. the engines alone are half the mass, I need to cut down on them (like 2 rapiers and 2 nervs rather than 4 each) to get a better range.

I believe I have heard it called cosine losses, so presumably the cos of the angle (0.71 for 45 degrees) should be the effective thrust multiplier(so almost 30% loss at 45 degrees) It would only prevent liftoff if you do not have enough thrust after accounting for the loss due to the angle. Presumably you would switch to the main engine once you were an appropriate height above the surface, so hopefully the total wastage is not too bad.

Last but not least, a list of the mods I used which made a significant difference in the trip, and/or which I used heavily.: ABookCase Orbital Reference System. Mouse over your orbit for contextual details. I've been using it so long I forget stock doesn't do it. Action Group Manager Renewed. Manage action groups in flight. Great for this kind of mission where you might dock something, undock something else, find some entirely new mode of operation you didn't even dream of when setting out... Alternate Resource Panel. The mode that displays time to full/empty is very useful for projecting ISRU outputs, and unlike the stock panel you can mouse over it without every part on the ship with ElectricCharge getting highlighted at once. Astrogator. MechJeb's transfer window planning is sometimes a bit erratic; it was useful to have something else. Atmosphere Autopilot. I flew halfway around both Kerbin and Laythe - and with this, given the aircraft design was sensible, I could plot the course and leave it to it. B9 Procedural Wings. Generally, I'm a fan of building ships out of blocks that maybe aren't quite the right size - I don't use procedural tanks, say, or TweakScale in arbitary increments - but particularly in a FAR world it's pretty hard to get satisfactory wings; the stock modular wing parts are very fiddly to get a useful wing out of. My own Campaign for Real Electric Charge. A make-your-life-difficult mod; rovers had to carry nuclear power (or perhaps huge LFO tanks and fuel cells), there is no chucking a 55 tonne EV around by sticking three solar panels on the roof. Connected Living Space. Another make-your-life-difficult mod, important on this trip where the QA and Hangarmoth's crew spaces were nowhere near each other. Dated QuickSaves. I was quite willing to quicksave and load outside of the actual roving, and this makes it enormously easier to work out which quicksave you want. Dock Rotate. There are other options - Infernal Robotics and the new stock Breaking Ground parts - with a wider range of functions, but Dock Rotate did everything I wanted here for vessels that change shape - the Hangarmoth swapping to belly-sitter mode, the anti-roll arm on the rovers, the self-righting mechanism on the Mk VIII - but it's also just very useful for its original purpose, to line up everything nice and square after docking. Dock a drill module, point the drills at the ground? Easy. Get the Fertiliser tanks precisely fore and aft to aid with balancing mass? Also easy. And if I'd thought of it, rotatable auxiliary engines would have been a huge boon. Docking Cam. Camera view out the docking port itself, and some stats on relative positions and speeds. A tremendous aid and one that makes a lot of sense. Docking Port Alignment Indicator. Valuable once you know how it works, but if I had to give up one of these and Docking Cam, it would be this. EasyBoard. Press 'B' to want to board, 'F' to want to grab a ladder. The kerbal does it when in range. Sounds trivial, but it makes life so much nicer. Editor Extensions Redux. Vastly better control of part symmetry and positioning. Indeed, now I look at it, it does a bunch more stuff I've been doing by hand with Precise Editor. FAR. Important for more plausible flight physics, especially for the Eve ascent. Fuel Tanks Plus and other mods by NecroBones (Lithobrake, Modular Rocket Systems, Space-Y, Space-Y Extended). A generous corpus of extra rocket parts, many of which are useful for building excessively huge rockets. Hangar. Hides craft from the game (turns them into lumps of mass in the part they docked in), then pops them out on demand. I could maybe have got one rover into the bay on the Hangarmoth, docked it up, and suffered the results of adding that part count to the Hangarmoth/QA package. Two? Never (although there is space). Hangar made this mission vastly easier, but not in an unrealistic way, just by offering a lot more effective part count - and, at that, even though my use of it could have been much better arranged. Hangar Extender. Nothing to do with Hangar, it lets you go outside the VAB/SPH to assemble huge craft. I may have employed one or two huge craft on this trip. Hooligan Labs Airships provided the inflatable envelope to get off Eve. Inline Ballutes are the big doughnut-shaped balloon/parachute things that got me down on Eve and Laythe. Kerbal Alarm Clock. Warns you of upcoming maneuvers and SOI changes for unfocused craft. Vital in the early stages with ScanSAT probes en route to the entire Kerbol system. Kerbal Attachment System / Kerbal Inventory System. I gather stock has an inventory system now, but I'm used to this. Mainly used for sucking the fuel out of rover delivery probes that some idiot didn't put a docking port on... and yes, there is a better answer to that, but the ability to carry spare radiators in case some were damaged then decide just to fit them anyway was valuable, too. Kerbal Engineer Redux. There are other mods to plaster the screen with information about vessel and flight, but this one is the one I used. Kerbal Foundries / KSPWheel. Without this wheel physics mod and the accompanying parts I think this journey would have been vastly more frustrating. KerboKatz PhysicalTimeRatioViewer. Sure, the clock is yellow, your computer can't keep up - but by how much? This tells you. Useful early with a slower computer and a mod for fine control of physwarp to adjust physwarp to play in more-or-less real time, and also useful later when the physics time per frame setting was wrong; it told me immediately something was up, and by how much. kOS. A programming language inside KSP. Landed the Hangarmoth, balanced the fuel, ran the fuel cells on the rover, controlled overspeed by turning the brakes on, stopped me flipping downhill by turning the brakes off if the rear wheels weren't on the ground, tapered off pulse size during maneuvers. ManeuverNodeSplitter. I wish I'd known about this ages ago. Where you've got a maneuver (like one of those week-long LV-N transfer burns) that's long enough to give a significant cosine loss in dV, you can split off some smaller chunks and do one of those each time round your orbit when correctly aligned. MechJeb. Besides the obvious maneuver planning and execution functions, its Rover Stability Control does its very best to keep your wheels facing the ground. (However, https://github.com/MuMech/MechJeb2/issues/1572 was an unfortunate interaction I had to patch out myself). Mk2 Stockalike Expansion. I really like these Mk2 parts - most unusually, an early prototype of the Eve lander was a plane with a rocket piggyback, as for Laythe, but the higher fuel needs gave it three Mk2 hulls side by side, done with this mod's T and X pieces. Mk IV Spaceplane System. Bits of it got used in the Hangarmoth, but the main thing is that the Kerbian Sea Monster is a Mk IV hull upside down. NavHud. Puts the navball's lines and markers on the main display, so they're not so teeny-tiny. Near Future Construction. A wide selection of mostly-structural parts. A huge chunk of the Hangarmoth, and bits of the rovers, are made from its Octo-Girder struts. Part Commander Continued. Use part right-click menus without finding the part and right-clicking it. Pretty handy when a bunch of converters and whatnot are buried deep inside some monster vessel. Precise Editor. Set parts' position and angle with great precision while editing. I used it for all sort of fine adjustments, but most obviously it was necessary to make the engines rotating around on the Hangarmoth come into the correct position relative to their new docking ports. QuickExit, for those times when KSP's jankiness or my own bad decisions demanded an immediate halt to proceedings. Just quits the game without going through half a dozen menus. RasterPropMonitor (along with the DE IVA Extension and various IVA prop sets). Makes the in-cockpit MFDs functional, which if you want to do all your roving with a kerbal's-eye view, is very useful. Recoupler. Connects together stack-attach parts that meet, so you can make circular stations. Connects up the Hangarmoth's living space and the rovers' rollcages. RemoteTech. Light-speed delay communications with remote probes, which need appropriate antennae. Another make-life-hard mod; one I quite enjoyed given that you can control probes from a ship with sufficient crew, which gave another reason to bring 12 kerbals not the boring-but-optimal two (one to drive the rover, one to run the ISRU). SCANsat. Altimetry and biome maps were nice, and I've not even tried the stock scanning facility, but for this trip a big benefit was the Been There Done That part - once I had it working, you don't need a stack of flags to see where I've been, the path is just there on the map. A great pity I didn't have it working for Eve, which was by far the most complex route. Ship Manifest, mostly because it gives a handy way to move crew around which respects Connected Living Space restrictions. Station Keeping. Expend a bit of RCS in the Tracking Station to make a very fine adjustment to an orbit. I can't think of any other way to have communications satellite clusters that stay correctly spaced. Stockalike Station Parts Expansion Redux. Provided the centrifuge habitats on the QA and a certain amount of other crew movement space. Given the USI Life Support requirements, the alternative would have been a huge bus of USI Tundra modules, much less interesting to look at. Stockish Project Orion. Otherwise I'd have to get around the system burning LFO like some sort of caveman. Structural Tubing Restructured. The rollcages on the rovers. TAC Fuel Balancer. Not so much for balancing per se, but a handy interface for pumping the stuff around after docking or before undocking, or just for monitoring one specific resource. Targetron Adopted. I find it very hard sometimes to target stuff from the map. This lets me just pick out the ship I want. Tracking Lights. The smaller spotlight in this was the big headlights on the rovers, far more effective than the ones they came with, and with exact control of facing. (Indeed, they can be configured to ludicrous levels, but I just wanted something more like a high-power headlight for roving off-road in the dark than leaning out the window with a flashlight). TweakableEverything. Adds a few useful part tweaks... indeed, I'm kind of wondering if this configured the brightness/range on the Tracking Lights? The USI mod constellation, mostly for the Life Support mod which provides a more complex system than "if one kerbal-day needs x grams of supplies, 12000000 kerbal-days needs 12000000x grams of supplies", but its Tundra parts provided the metal and uranium manufacturing for pulse unit manufacture.

Cosine Loss XII, you are cleared for takeoff Love the story. A bit rough around the edges but the central premise is fascinating. Please keep it up!

As I said, in actuality the reusable SSTO gets at or above the payload of the reusable TSTO because of the severe payload loss from the reusable TSTO having to keep a large amount of propellant on reserve in the first stage to cancel out the forward motion then boost back to the landing site. You've said this several times before. It is false. Absolutely, categorically, wholly wrong. This is not how the math works. Consider a putative vehicle with a launch mass of 2000 tonnes. For the sake of simplicity, let's say it is launching methalox propellant as payload to an orbital prop depot so we don't have to worry about fairings or payload mass. Let's make all the assumptions in favor of SSTO over TSTO: equal structural mass ratio on both stages, same engines, same specific impulse, same recovery mass penalty, same T/W ratio. Let's set the structural mass ratio at ~30:1 and use enough sea level Raptor 2 engines to give a T/W ratio of 1.5 (or as close to it as we can come). Let's set the recovery mass penalty at 10% of total dry mass even though that's wildly unrealistic (it will be much lower for a first stage and much higher for a second stage or SSTO). Finally, because we'll be using vacuum thrust and isp, let's set the required dV for LEO at 9.6 km/s. Then we can just figure out how much propellant we have remaining when we reach 9.6 km/s of dV, which gives us our total payload. Raptor 2 masses 1.6 tonnes and produces 230 tonnes thrust at sea level. Using your 358 seconds of vacuum specific impulse and 330 seconds of specific impulse at sea level, that's 358/330 or 8.5% greater vacuum thrust, for a total of 2448 kN of vacuum thrust. However, for liftoff thrust considerations, we need to use sea-level thrust. Since the launch mass of 2000 tonnes is going to be the same whether it is an SSTO or a TSTO, the liftoff thrust needs to be 3000 tonnes, which will require thirteen Raptor 2 engines off the pad. First we do the math for the SSTO case. Thirteen Raptor 2 engines mass 21 tonnes, leaving 1,979 tonnes to play with. Using our structural mass ratio of 30:1, that gives us 64 tonnes of structural mass which means 75 tonnes of dry mass. But as you'll recall we have a 10% payload penalty for recovery which we will pretend is enough for deorbit props, TPS, landing gear, and landing props, so that adds 8 tonnes, bringing dry mass to 83 tonnes with 1917 tonnes of propellant. By the rocket equation, mf = m0 / eΔV/ve, and ve is 9.81 m/s2 * 358 s or 3512 m/s. e9600/3512 = 15.39 and m0 is 2000 tonnes so mf = 130. 130 tonnes minus 83 tonnes of dry mass means this SSTO reaches LEO with 47 tonnes of propellant as payload for the propellant depot. Now let's try doing the same math, but for a TSTO. We assume that the first stage provides impulse up to a total ΔV of v1, where it stages at a velocity of vs. Note that vs is significantly less than v1 because v1 includes gravity drag, aerodynamic drag, and pressure drag. To return to the launch site, the first stage executes a boostback burn vb which is equal to the horizontal component of vs plus whatever additional impulse is needed to get a ballistic trajectory back to the pad. In order to make this as generous as possible to the SSTO case and as punishing as possible to the TSTO case, we will set vb = (vs + v1)/2 even though it would never be that high in reality. Gravity drag is negligible for the second stage, so the second stage needs only provide ΔV equal to 7.8 km/s - vs. This means all of the drag is concentrated in the first stage, making v1 = vs + (9.6 km/s - 7.8 km/s). The question then becomes, where do we put vs? Well, we can balance the first and second stage however we want. General wisdom says to make the total calculable ΔV on both stages approximately equal, but since reuse changes the calculation, we don't necessarily have to follow that advice. We know the total mass of the vehicle is 2000 tonnes so let's look at what happens when we vary the total wet mass of the second stage. As you can see, as long as the second stage wet mass is greater than ~10% of the total launch mass, TSTO is going to beat out SSTO every time. This is precisely what we would expect. The efficiency of staging is vast; losses due to boostback propellant reserves are not going to cut into that unless your upper stage is comically small. Changing the math won't help you because any changes to one stage will be translated to the other stage. And this was with ALL the most generous assumptions. A TSTO first stage will NOT need as much recovery mass and an SSTO will need significantly more. A second stage can use a vacuum engine and a better structural mass ratio. Anything an SSTO can do, a TSTO can do better. There are certain advantages to SSTO architectures, but the math does not support your notion that the TSTO boostback penalty is significant enough to overcome the efficiencies of staging. There is no forward skirt that extends beyond the tank. The top dome of the tank is 3.7 meters so that's the most you can subtract off the top. No, you can't subtract off the height of the bottom tank dome, because the thrust structure transfers the engine thrust directly to the tank walls, so you need the walls to extend down to the bottom. Sure. You also need the shielding around the engines but that can be thinner steel so we'll set it aside for now. So the actual first stage tank wall height is 70 - 3.7 - 3.1 = 63.2 meters. A fraction, yes; negligible, no. You can't just ignore the mass of parts of the vehicle. Plus, there are actually three domes since Superheavy uses a common bulkhead. So the total area of the steel required is going to be 63.2 meters * pi * 9 meters + 1.5 * 4 * pi * 4.5^2 or 2,169 square meters. With 4mm walls that's a volume of 8.676 cubic meters; with 3mm walls that's a volume of 6.507 cubic meters. The density of low-carbon 304L stainless is 8 tonnes per cubic meter. So the actual structural mass of Superheavy tanks alone is going to be 52-69 tonnes depending on whether 4mm or 3mm steel is used. By the way, you don't have to worry about mass flow rate in calculating the vacuum thrust. Just multiply sea level thrust by the ratio of vacuum isp to sea level isp. Sea level isp for the raptor is 330 seconds. I think you're underestimating thrust a little. Anyway, Elon's BOE estimate at 40 tonnes was with no fairing. If you want to get a payload to orbit you need some kind of fairing. And if you want to add "reusability systems" then the fairing can't be jettisoned. So you think that you can make a stripped-down expendable Starship fully reusable by adding only 5 tonnes of dry mass? That doesn't make sense. There IS a fully-reusable Starship, and it has a mass of 85 tonnes. That's just the fairing and the flaps and the flap drive motors and the heat shield, no crew quarters. And if you added three more engines to it then it would be 90 tonnes. And it needs to reserve 30 tonnes of propellant for re-entry and landing. So "dry mass" in this scenario is 120 tonnes and the actual useable propellant is 1,170 tonnes. Plugging that into Silverbird: Doesn't close. The Dragon 2 crew capsule dry mass without the trunk includes aeroshell, heat shield, and parachutes. The square-cube law is going to help if you're scaling up, since there are a lot of things that don't scale linearly when you increase passenger capacity. So no, you cannot simply multiply out and subtract 60 tonnes. The 40-tonne mass Elon quoted, again, is without flaps or heat shield or recovery propellant or anything else. I don't see how you're claiming you can make a stripped-down 50-tonne Starship recoverable using only 5 tonnes of recovery mass. You talk about PICA-X being lightweight and everything, which is great, but let's do the math. The Apollo CM heat shield was 1400 kg and covered a surface area of 11.95 square meters. The tank section and skirt of Starship, with no fairing at all, is 28 meters high, so covering one-half of it with TPS would mean 28 meters * pi * 4.5 meters = 396 square meters. Let's suppose PICA-X is half the weight of Apollo-era ablative TPS. 0.5 * 1400 kg * 396 m2 / 11.95 m2 = 23.2 tonnes. Let's be generous and say you can cut that in half again, both because Starship is fluffier than a crew capsule and because you only need to deal with LEO re-entry and not cislunar re-entry; that's still 11.6 tonnes, which is more than twice your estimate for total recovery mass. But let's go with that. You've launched your stripped-down 9-engine Starship to LEO, and your 48.6-tonne payload capacity has been cut back to 37 tonnes due to TPS weight. How are you going to get it back down to Earth? You'll need deorbit propellant, about 100 m/s worth. That's about 3 tonnes. With 9 engines in the back and nothing in the front, Starship is a tail-first lawn dart, so you're going to need wings or flaps of some sort to keep the heat shield oriented properly. But let's pretend you don't need wings at all for attitude control (perhaps you have four mini-Raptor thrusters mounted dorsally?), and you're going to just land the whole thing with parachutes in order to avoid needing any more reserve propellant. You'll need a lot of parachutes. Total dry mass is now nearly as much as the Shuttle SRBs, which each required 3.5 tonnes worth of drogue and main parachutes in order to reduce splashdown speed to 23 m/s. Let's imagine those mini-Raptor thrusters you used for attitude control (using no propellant to do so) are going to provide your soft landing. If they're mounted dorsally, then you're looking at cosine losses of at least 30%. To get the 2+ gees required for an efficient landing, they'll need to produce a total of 123 tonnes of thrust plus another 43% to make up for cosine losses, so that's a total of 176 tonnes of thrust; if you can scale down the Raptors perfectly then you're looking at a total of 1.2 tonnes of engines. Even though a smaller engine won't be as efficient as Raptor, let's pretend it will. Your isp of 330 s is cut back to 231 seconds due to cosine losses. Factoring in gravity drag and the need to cancel out residual horizontal velocity from the chutes, you'll need about three tonnes of propellant. You're also going to need some sort of landing gear, which is going to be around 2-3% of landed mass. Let's be friendly and call it 2%, so that's 1.3 tonnes. So your actual payload to orbit has been reduced from 48.6 tonnes to 25 tonnes. That's still something, right? Yes...but you have no fairing, no RCS, no propellant reserves for controlling re-entry attitude...nothing. And that's making all the assumptions in favor of the SSTO.

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

How much dv is needed to actually land? Use the vertical fairing, the nose has chutes to do much of the work. Underneath is engines, LES style for Crew Dragon (cosine loss), but designed not for LES, but soft landing on Mars. Legs flip down per my image (maybe connecting as a ramp on one side), and with engines up at the nose, it lands VERY low to ground (self leveling). Rover can roll out, which gives to a 5.4m circle of which a rectangle is rover. One side can have an airlock, with stairs leading up to crew decks. You could probably get chutes, landing props, a rover deck, and 2 crew decks (stretched fairing height). Any excess volume for consumables. That's 44 m2 of crew floor area, kinda dinky. The question is, how light could those be, they are mostly open volume after all. What's FHce mass to TMI? F9e is ~8t to TMI, FHe is 16t. Just throwing away the core has to be in between. They could send a few habs, only 1 needs the rover deck, the other can be 3 crew decks (66 m2) Maybe there could be an inflatable passageway to connect them (if the rover is capable of moving one)?

Very nice walk-through with pictures, thank you! I tried a manual gravity ascent myself, with a craft pretty similar to yours. Managed a slightly-over-5km circular orbit with 578 m/s of dV spent, so that's a fairly consistent result. My main impression, from reading your two cases that you tried, was essentially the same as @king of nowhere's. If you try it twice, and the difference is only 10 m/s of dV, that's so close as to be a negligible difference in these two cases, given the randomness of piloting. Well, not quite. Note that @king of nowhere said he had trouble with constant-altitude ascent, not descent. And I never said that the ascent was easier at constant altitude. Quite the reverse-- a continuous burn is fairly simple, just crank it over to start the turn, set it to hold and floor it. My comment about suicide-burn landing being tricky is purely a matter of judging when to start the burn. The actual piloting is trivial, just let SAS hold and be prepared to cut thrust when needed, that's it. I'd say that a constant-altitude landing would require considerably more tweaking of steering and so forth. Less risk than a suicide-burn descent, but more interaction and, I'd say, more piloting skill needed. I think that this comment is pretty relevant: Because your approach (@camacju) and mine are, in practice, usually very similar in terms of the actual piloting. Regardless of whether one is doing a suicide burn or a constant-altitude landing, it's still the case that it's a bad idea to descend steeply to the surface. My suicide burn advice is that you only lower your Pe just barely underground, so that you're approaching the ground at a very shallow (i.e. nearly horizontal) angle before you start your burn. So, let's consider a landing, in your proposed case versus mine. In your proposed use case, you're going very fast sideways initially... ...with zero descent rate you thrust nearly horizontally, with your nose pointed up just slightly so that you can maintain altitude therefore you have a tiny cosine loss while you're burning as you slow down more, you'll have to point your nose higher and higher above horizontal, resulting in more and more cosine loss cosine loss is worst just before touchdown Whereas in my proposed use case, you're going very fast sideways initially... ...with a very low descent rate you thrust nearly horizontally, with your nose pointed perfectly therefore you have zero cosine loss, but you do have a tiny gravity loss while thrusting because you're not perfectly horizontal as you slow down more, your path will become more steeply inclined, resulting in more gravity loss. Still no cosine loss, though gravity loss is worst just before touchdown Note how very, very similar these two cases are. #1 is identical for both cases. #3 is basically identical in both cases. #4 is pretty close to identical-- a small loss in both, just of a different nature. #5 and #6 are likewise extremely similar. Now consider the fact that none of the Kerbin system's bodies are perfectly flat (except for Minmus' flats, but even those are surrounded by steep slopes that you have to clear). Which means that you're going to have to be concerned with terrain avoidance. A constant-altitude landing is generally not going to be able to slide sideways to a perfect stop on the top of a hill-- in practice, the player who wants to use this approach will pretty much always have to make that a constant-altitude that's higher than the target landing point, meaning that they're going to have to transition to a steep or vertical descent at some point in order to come in for a landing. And if they're doing that... then the shape of the curve that the ship follows is starting to look an awful lot like what a suicide-burn ship is doing, anyway.

Should it not be less efficient than a burn, because of cosine losses? Yes, there is gravity loss, but you have that regardless, no? So you can do a burn and have gravity losses, or you can do a constant-altitude burn and have both gravity losses and cosine losses. What's the rationale for the latter? It's true that sometimes you can't do a burn because you've got such a low TWR-- i.e. just barely higher than 1-- that you need to burn with your nose pointed higher than just so you don't fall down and crash while you're still trying to kill your horizontal speed. (The "landing on Tylo with nuke engines" scenario.) So, yes, sometimes that's necessary. But that's nnot the same thing as being more efficient, it's just a necessary inefficiency to deal with an extremely low TWR. And in my experience, Tylo tends to be the only place where that tends to be an issue. Other vacuum worlds tend to have fairly low gravity and therefore landers are likely to have a local TWR significantly higher than 1, so that's not an issue. If you're burning anything other than perfectly , you're incurring extra cosine losses and you're not saving gravity losses. Note that I'm not saying that a constant-altitude landing is a bad idea. There are reasons it can be appealing to people-- for example, it takes the knuckle-biting out of the landing, you don't have to worry about going splat if you misjudge timing by a fraction. You have more time to adjust, to bump your nose up a bit if you're getting uncomfortably close to terrain while accelerating, for example. There's absolutely nothing wrong with landing like that, if it works well for someone. And in very low-TWR cases, it may actually be necessary, as you point out. But it's not the most efficient. The pure suicide burn that I'm describing is riskier, that's why it's called a suicide burn. And not everyone wants that risk, and that's perfectly understandable-- it's not for everybody. But it is more efficient; that's why people do it. (Also, note that when I say "more efficient" or "less efficient", that's a relative term-- depending on the situation, the dV savings from one to the other may not be big enough for the player to care about much, in which case clearly the player should go with whatever landing technique they're comfortable with.)

Yes, correct, you should do this, for precisely this reason. If I'm understanding you correctly, I think you're saying "well, if I burn all the time, initially I'm thrusting slightly downwards in this picture, and later I'm thrusting slightly upwards, and those two things cancel each other out!", is that what you're saying? If so, then no, that's not how it works, that's not a thing, nothing is "canceling" anything. You're going "down" and then "up" (in that drawing" because the planet's gravity is curving your path, there's no loss. You add energy by thrusting , and only the component adds to your orbital energy. Any or component is wasted as cosine loss, so don't do that. Probably will want to narrow that down by quite a bit. When you're initially circular, this would mean you'd be futzing a lot with your Pe (since you should be thrusting ). Later, after you've given it a few kicks to raise your Ap by a lot, this means that burning for 30 degrees on either side of Pe would mean doing a lot of the burn at high altitude and losing Oberth benefit. So, best to keep your burns narrower-- 10 degrees on either side seems pretty reasonable. Yes, it raises the Pe. But as long as you only burn in a fairly narrow band on either side of Pe-- i.e. 10 degrees or less, not 30 degrees-- then it won't change your Pe very much, so the loss of Oberth effect should be minimal.

??? my starting orbit is circular, so i draw it as circular. i don't see how it changes the answer anyway, except for reducing the window in which i have small losses. on the other hand, for a non-istantanous burn, burning prograde all the time also raises the periapsis. and raising the periapsis loses on oberth effect. and on the other other hand, a higher periapsis means a longer time spent close to periapsis, a longer time when the ship can burn with limited cosine losses, thus less cosine losses on further orbits. so many variables... by 30 degrees i mean i am burning as long as the difference between prograde and manuever is less than 30 degrees. the cosine of 30 degrees is 0.87, so i'll be losing 13%. whether that is an acceptable loss depends entirely on what is the fuel budget, the actual thrust, and the time available before losing the launch window

I doubt it. I mean, that's the result you get by integrating the cosine over the whole orbit. it assumes that, while you burn, you stay in orbit. which is not what's going to happen. especially with the orbital approximation of this game. what actually happens is that, as you exceed escape trajectory, your ship is going to leave orbit entirely. and it's going to come out of your SoI pointing at a completely wrong angle. I'm too lazy to produce screenshots right now, but I can. I did send a spaceship with TWR 0.11 to jool. twice. unless you are talking about raising your orbit in a spiral, which is what is done with real life ion propulsion, but i'm fairly sure that's more than a 40% loss of efficiency. in my experience, the best way to deal with low twr is with tricks. first one is raising periapsis peemptively. you have to burn for 2000 m/s, but you can burn the first 900 while still remaining in kerbin orbit. so, do that first, and then you only need to burn for 1100. which is still a huge amount with twr 0.1, but still manageable. if you have to go nearby, like to eve or duna, you can eliminate any problem with this strategy (actually, you can get there with a mun gravity assist without making long burns). It works best if you make your long burn in a long orbit, perhaps returning from a moon. maybe that's what you mean with suicide oberth burn? if that's the case, i can confirm that it is fairly efficient, as you will have a long time when prograde will coincide with the direction you want to burn. another option is raising periapsis. it's something you normally want to avoid, you gain no benefit and you lose oberth effect, but it makes your orbit flatter, reducing cosine losses. can be worth doing in some cases. but the best option by far is to avoid big burns by using gravity assists and other convoluted trajectories that only require correction burns. last but not least, making manuevers in kerbol orbit is also a good way to avoid cosine losses. sure, you'll lose all oberth effect, but at least your orbit is so slow you can spend hours making your burn without any noticeable loss In my case, i found that i needed over 2500 m/s to go to jool immediately, but i could lower it to 2200 by going to duna first, entering a high orbit that would put me eventually around ike, and then from ike fall back towards duna and make the bigger burn there.

The dV cost to orbit can be broken up into four things: orbital speed, gravity losses, aerodynamic losses, and steering losses. For launching from stock Kerbin with typical TWRs (1.3 to 1.5) and a reasonably pointy rocket, orbital speed is about 65%, gravity losses are 25%-30%, aerodynamic losses are 5%-10%, and steering losses are one or two percent at most. You cannot reduce orbital speed, but you can reduce the losses. Out of the three, gravity losses are the largest by far. Gravity losses are constantly incurred whenever a rocket engine is fired not perfectly perpendicular to the gravity well. The more it is firing towards the gravity well, the worse the losses are. Directly at launch, when the vehicle is perfectly vertical, gravity eats up 9.8 m/s worth of dV for every second the engine fires. 9.8 m/s, every single second, just gone. That's why gravity losses are the biggest loss factor. So how do you reduce it? Well, if you could turn over harder and sooner, you'd be firing your engine further away from the direction of the gravity well sooner, and for longer. Also, if you could just fire your engine for a shorter time, fewer losses would accumulate. And both of these things have one thing in common: they require you to have higher acceleration. In other words: a higher TWR. This is what TWR does for you, beyond having enough of it to lift off; it makes your ascent more efficient by minimizing gravity losses. Which is what @Entropian already correctly pointed out, just with an actual explanation attached There are two takeaways from this: one, if you lose more dV to additional engine mass than you save in gravity losses with the thrust from those engines, all you did was waste money; and two, TWR largely ceases to matter once you are in orbit. (I say "largely", because stretching a burn over too large of a section of the circular orbital path starts incurring you significant cosine losses as you thrust off-prograde for minutes on end both ahead of and after passing the maneuver node. And if your thrust gets so low that you have to fly constant-thrust spiral trajectories, like ion engines require you to do IRL, then the cost of transfers can rise drastically - up to 2.4 times that of an ideal Hohmann transfer, given an infinite SoI and infinitessimally low acceleration.)

For making extremely fine-grained adjustments to orbital period, of course it's good to have the thrust as tiny as possible. However, you can also reduce your effective thrust by a factor of 10 or more just by pointing your ship in the correct direction. The idea is to leverage cosine losses, same as you've done with your angled-mount RCS thrusters here. But instead of angling the thrusters on the ship, you simply angle the whole ship. Longer explanation is below, but the TL;DR is, don't point your ship or . Instead, point it just barely on the or side of (or one of the other three cardinal directions). This will give you a massive cosine loss that allows making very fine-grained adjustments to your orbital period. Lengthy explanation in spoiler. I use this method all the time, and it works great. I don't use KER myself, but I do use BetterBurnTime, which provides a feature that shows (to the millisecond) how far off your orbital time is from another target's. My comsats usually have some little engine on them like a Terrier or Spark. I just reduce the thrust limiter down to the lowest it'll go above zero (0.5%, IIRC), then use this cosine method I describe here. Works like a charm, and I can pretty easily adjust the orbital period to within 1 millisecond.

Am I right? Is that or isn’t that the most powerful vacuum engine ever manufactured? It’s more than twice the thrust of the J-2, and even the SSME’s vacuum thrust is slightly less. The F-1 had more vacuum thrust, of course, but it wasn’t a vacuum engine. I wonder if it is dual-bell. It doesn’t look dual bell but it is hard to tell. I do not think we have a sea level compensating bell like the RS-25. As others have said, it won’t — both because the nozzle is not as thin, and because it will not gimbal. They could not use a radiatively cooled nozzle extension like the MVac because the engine is not directly exposed during the burn, due to Starship’s skirt/heat shield. The Raptor will be fixed in place and likely be in contact with the skirt. I assumed 15% gimbal range because that’s what Elon said. Cosine loss can go up to 3.41%, but that’s from the minimum throttle setting already which does not help as much. In other words, that’s 3.41%, not 3.41 percentage points. Not quite enough to get below one gee.

I'm assuming the above is with superheavy vertical, and without any thrust vectoring? There is the option of thrust vectoring which should get you a little closer to hovering, even with superheavy upright. Taking the centre diagram you should be able to tilt the 40-55% pair away from each other. 8 degrees of thrust vectoring mean the cosine loss is about 1%, which would allow the third engine to throttle lower. That gets you a little closer to hovering. There is also the possibility of hovering with superheavy canted over. Taking the centre diagram, tilt SH so its COM is offset slightly towards the bottom pair of engines. If you have the right amount of tilt, then the third engine should be able to throttle to match the bottom pair. (I'm not sure how much tilt that is, but I'm guessing it is around 5 degrees). This should also give you the full throttle range of all 3 engines, so 2640-6600kN. (A 2 engine hover should also be possible).

Perhaps that is why I said that S-turns were required to control descent rate and not something to do with stability. It was more than re-entry accuracy. If it was just a matter of landing in the right spot, the Shuttle simply could have begun re-entry earlier. The Shuttle had to maintain a strict 40-degree angle of attack to shield vulnerable portions of the airframe from direct re-entry heat. However, at this airspeed and angle of attack, the Shuttle had a tremendous amount of hypersonic compressive body lift due to its high wing plan area (necessary in order to allow a reasonable, somewhere-better-than-brick subsonic glide ratio). It had so much lift that if the 40-degree AoA was maintained through the re-entry interface, the orbiter would have actually begun to climb, trading velocity for altitude. This would have been bad, because both speed and atmospheric pressure would be decreasing, leading to less control authority on aerodynamic surfaces. The only way to maintain control authority while losing airspeed is to descend into thicker air, but the Shuttle couldn't descend with a 40-degree AoA. The way to maintain descent rate without decreasing AoA was to turn the lift vector sideways with a bank/roll maneuver. This pulled the Shuttle off-track, but induced cosine loss in the lift vector that allowed a better descent rate. The craft would then need to bank in the opposite direction to stay on track, and repeat through the re-entry interface. Indeed they do. However, a loss of roll authority (as happened in TMA-10 and TMA-11) or a steeper-than-planned entry trajectory (as with MS-10) resulting in a ballistic re-entry is still aerodynamically stable. It's just very unpleasant. TMA-10 actually re-entered nose-first, with the orbital module still attached, and it melted off and then the craft tumbled into its aerodynamically-stable re-entry orientation. The crew was banged up but the chutes deployed properly and they survived. That is what I mean by passive aerodynamic stability. Yes, Dream Chaser and the MiG-105 (as well as the X-37B to a lesser extent) have better passive aerodynamic stability. With that sort of shape, a failed control surface may result in an off-target entry but you will at least survive to an altitude where you could conceivably bail out. Yep. That's where "what if you lose tank pressure" comes in. Some things like major structural failure are never going to be recoverable. Crew Dragon can obviously save the crew if there is a major structural failure of the F9 booster, but if there is a major structural failure of Dragon itself there's simply nothing you can do.

Fission fusion antimatter ion drive The Fuel Pellet The conductor of the fuel pellet is superconducting Li6H2 This forms a solenoid, a capacitor and a switch. Dialectric filler material is decaborane. B10 10 H14 2 The fuel pellet is charged a few seconds before firing with as much current as possible. It assumes the shape of LR circuit where R is close to zero. The fuel pellet is discharged from the ship with a gas gun. Current in the fuel pellet can be terminated in a variety of ways. This is accompanied by a loss of superconductivity and a total chemical explosion. Voltages greater than 1 million volts are created between the top and bottom of the fuel pellet by magnetic quench. The Fission System One or more fission reactors are used to generate neutron beams and generate electricity using Kr78 as the primary heat exchanging fluid. The radiators also serve as gaseous diffusion isotope separators which separate Kr78 from Kr79 The Kr79 is fed to small feeder tanks for the ion engines which may operate either continuously or in relatively frequent pulses. Kr79 has a half life of 1.46 days. It emits a positron and becomes Br79. Kr-80 and Br-79 impurities arise both in the radiator and the ion drive tanks, they may continue as coolant or propellant or be removed for some other system. Ship Electric Drives Standard ion drives for Kr 79 are arranged in a radially symmetric manner pointed inward at 1 degree. This entails 1/1000 cosine losses of momentum, but greatly increases the power achievable by converging on the fuel pellet. Electron guns are paired with the ion drives, also converging near the same point, perhaps leading slightly. These may afford a greater angle of radial convergence. Lasers and electrically powered neutron sources can also be used at even greater angles of radial convergence. The Zone of Reactions The chance that Kr 79 ion will release a positron at a time and place where that positron can interact with the fuel pellet is far less than 1 in a million, perhaps far less than 1 in a trillion. But it is not unreasonable to think that trillions of ions could be made to nearly converge in a single pulse, with at least a few positrons reaching the fusion fuel pellet. This is one of possible ways to initiate magnetic quench and the destruction of the pellet. It is also possible that a neutron could initiate the quench. Or an internal switch of the pellet could initiate destruction, though this is probably unnecessary. The fusion reaction is only barely contained by the external magnetic field. Therefore it is questionable what fraction of the deuterium in the pellet will undergo fusion. What fraction of other nuclear reactions will occur? And how much useful momentum can be harnessed by the spacecraft? In the case where zero fusion occurs and zero positrons provide useful momentum we have an engine that is very expensive in terms of cost, but not bad in terms of weight. Krypton ion engines are good by themselves. Decaborane and lithium hydride in a magnetic quench will all become monatomic ions even if fusion does not occur. Somewhere between 1% - 10% fusion burnup rate could justify the weight and expense of extra complicated radiators, fission power plants, and highly processed input materials. It is not necessarily wasteful of natural resources either, because Li 7 H 1 is a good superconductor with which to make a giant solenoid hull. And various B 11 compounds are good for shielding and chemical explosives. Pulse engines of necessity demand shock absorbers for the crew and payload. If our hull is a tube and we carry gas, then our payload capsule ought to be a cylinder within a giant piston. Protection from electromagnetic radiation involves a superconducting Faraday cage around the payload. Protection from neutrons requires gadolinium film in critical areas, also gas and hull materials help a lot.

I'm slightly surprised that the vacuum Raptors won't gimbal. If everything is working properly, that isn't an issue. They can use either differential throttle and/or rcs for steering during burns, assuming all three engines are operating. But if a vacuum raptor were to fail that would only work if the vacuum Raptors are aligned through the centre of mass, and not parallel to the hull. Aligning them through the centre of mass would mean a tiny cosine loss (probably negligible overall; it might even be smaller than the dV gained from the weight savings from a lighter engine that doesn't gimbal) but would also mean that they couldn't use differential throttle to steer, and would have to rely to rcs. Source? Also were those studies for 6-8 month trips, or for 2-3 year trips?

A couple points I haven't seen mentioned on this yet. First, when setting up transfers by hand, it's often easier to set up any correction node once you're outside Kerbin's SOI, just due to how patched conics display. And, when you're still in Kerbin's SOI, any up/down adjustments you make are relative to Kerbin, when what you're ultimately needing is relative to the sun. This can sometimes be confusing, so it's generally easier to wait until you're outside Kerbin's SOI. Also, prior to the relatively recent addition of the maneuver node editor box in the lower left corner, the interface often made it very difficult to plot correction burns while you' were still close to Kerbin. You had to focus on the target planet to see your trajectory in its vicinity but the node was all the way back at Kerbin where it was hard to manipulate. So this is often why folks would do their corrections like 1/2way to the target. They were outside Kerbin's SOI and close enough to the target to manipulate the node while focused on the target. Experienced players, knowing this was how you had to work around the limitations of the interface, would bring a bit more fuel than necessary to cover any inefficiencies this method caused. Nowadays, however, with the node editor, these concerns don't matter. The other thing to keep in mind about waiting to the middle to do the mid-course inclination burn is that the further you get from Kerbin, the more vertical distance there is between Kerbin's orbital plane (where you are) and the plane of the target. Thus, your ship has to go up or down at a steeper angle the farther you are from Kerbin. Which means, when you encounter the target, you'll have more inclination relative to the target because you'll be approaching it at a steeper angle from above or below. If you're wanting to get into an equatorial orbit at the target, then yo'u'll have a bigger inclination change to do once you get there than if you'd done the en route plane change closer to home. If you're not concerned about this, then it doesn't matter. My rule is only use nukes if there's no other way to get the necessary dV. The problem with nukes is that they lack thrust and if you're leaving from LKO, you need a minimum TWR of 0.75 or so. This is to keep the transfer burn down to 5-6 minutes AT MOST, or about 1/4 of an orbit around Kerbin. If the burn takes any longer, you lose beaucoup efficiency to cosine loss and might even clip the atmosphere. If you've made some massive mothership, sometimes you have no choice but to accept a very low TWR and a stupidly long burn. In such cases, you'll want to start in a higher orbit with a bigger radius, so the cosine loss is much less. But then you lose out on the Oberth effect. You can also sometimes split a long, low-TWR burn over 2 orbits, but this has its limits. The 1st orbit can only be about 1000m/s or you'll leave Kerbin's SOI instead of coming back around to finish the burn. Also, going out to the vicinity of Minmus on the 1st part of the burn will make the 2nd half happen a week or 2 later, which throws off your carefully timed transfer window, so you'll need a bigger mid-course correction. So all in all, keep your transfer burns 5 minutes or less. That's plenty of time to debeer/rebeer without having a long wait staring at the screen

This is pretty much me. LKO rescues are always at approximately the same height, give or take a kilometer or two, which means it's pretty easy to eyeball: I launch my rescue ship to the pad, shift to map view, rotate the camera so that it's looking straight down at the south pole (so that orbits go from left to right) and zoom in a bit. When the target gets at the "right spot" (about five degrees or so above KSC's western horizon), I launch and do my usual gravity turn on ascent. As soon as my Ap gets high enough for the "target closest approach" markers to appear on the map, that tells me how well I estimated my launch timing. Did I hit it spot on, or am I slightly leading or trailing the target? If I'm leading the target, pitch slightly above as I continue to burn. If I'm trailing the target, pitch slightly below and continue to burn. (Yes, this means a bit of cosine loss, but it really is only slightly off prograde, and it's a fairly minor amount of dV, so this is fine.) Wait for the navball to auto-switch to target-relative mode (i.e. when the target gets within 60 km or so of me), and then just complete the rest of the rendezvous in the usual way by watching the relative positions of the and markers and burning appropriately. Works like a charm. The reason it's easy is that I always launch when the target is in the same spot over the western horizon, which makes it easy to eyeball. The reason why it's always the same spot is that, 1. the rescuees are always in pretty much the same orbit, and 2. I always design all of my rockets to have exactly the same launchpad TWR, which means my ascent profiles are pretty consistent. This lets me retrieve kerbals without even completing an orbit. I launch, directly rendezvous, EVA-transfer the kerbal, retro-burn, and re-enter. End up landing without even getting halfway around Kerbin from KSC (unless I deliberately delay my reentry burn so as to try to land the kerbal right next to KSC, as a pointless-but-fun bit of target practice, which I sometimes do.)

Ah, the days of tinfoil ships and iron kerbs, bucko mates and driving skippers, salt horse and hard tack, pressgangs and shanghaiing. Astronauts these days have life so easy. It's refreshing to take a nostalgic look back Even though I have to break out my magnifying glass to read them, I always enjoy your photo credits That's for the tutorial! Yeah, 10 minutes is about 1/3 of an orbit in LKO so you waste a LOT of dV in cosine loss and risk hitting the air as you have to start the burn pointed down. 5 minutes is really the most you should burn at any time in this situation. Nicely done, although I remain to be convinced that reusable rockets make any sense economically That doesn't take away from the technical prowess needed to do it, though, which is cool both in real life in KSP. If he's mad, might as well leave him there forever. What further harm can be done? Well, if you had, you'd have been right in "Aerobrake Canyon", which looks scarier than it really is. For some reason, that canyon always seems to be along the path of ships going a bit lower. You can see it in your pic. I've frequently thought my ships were below the mountaintops on either side but the last time I took a plane to Duna, I measured terrain altitudes and realized this was an optical illusion--my ships were always way above the terrain. Congrats on getting to this point. Good luck with the rest!

Somewhat, but it's not their main thing. Props (and jets and rockets) function in real life by shoving fluids to the rear so Newton's 3rd Law moves the vehicle forward. Were this not the case, there'd be no propwash. Thus, all these types of engines create actual thrust and work via Newton's 3rd Law. Planes are not pulled forward by the lift of the prop blades (or the compressor blades of a turbofan), but are pushed forward by the reaction of shoving fluid backwards. But in KSP, the atmosphere is not a fluid. No part of it moves in relation to the rest of it, so props do not shove air backwards--there is zero propwash. The atmosphere is just a volume of space within which the mere motion of parts, no matter how that's caused, magically creates lift and drag forces on those parts that don't exist in vacuum. Thus, rotor-based prop planes move forward solely due to the lift forces acting on their blades. This is a HUGE difference from real life. It's also very different from the mod prop engines, which under the hood are just rockets with different animations. Yup, as you increase blade pitch, the lift vectors have more cosine loss towards forward motion but at the same time they also get longer, so the loss is less than the cosine of a constant force, although there are diminishing returns here. But at the same time, the blades offer less frontal area drag to the motion of the plane. At some point, these curves cross, which is the max possible speed of a rotor-based prop. Or maybe increasing blade pitch increases rotational drag first. Either way, you hit a limit. As to torque, to me it's a measure of the maximum power output of the rotor. You don't necessarily use it all. The more you use, the more EC/sec the rotor consumes, just like how rover wheels don't always consume their full listed EC/sec once you're up to speed. But, the capability is always there. Thus, the amount of torque actually USED, and thus the power consumed, might decrease once the rotor is at its max RPM, same as with rover wheels, but should you increase the load on the rotor, the torque you still have available will be there to maintain the highest RPM possible. Either this is the max RPM you've set for the rotor or whatever lower value the torque can manage against the load. The wider you make the rotor diameter, the more leverage its drag has so the more torque is required to maintain any given RPM,, regardless of blade pitch. So again, you hit a limit. Rotors only have so much torque and all their max RPMs are less than infinity. And eventually you'll find an amount of rotational drag that the rotor's max torque can't overcome. Thus, there are practical limits to all aspects of rotor-based prop design: max rotor torque, max rotor RPM, and both the frontal and rotational drag forces on the blades, which increase whether you increase RPM or prop diameter. There's seemingly no getting around this.

Lander legs have the lest slippage but you need to kill their springs and max their damping or bad things happen. And even then, they're kinda wonky. As an alternative, you can increase the foot's surface area. Even relatively slippery parts get reasonably good grip if you have a big enough shoe size. My fastest walkers have used pistons straight ahead and astern in a push-pull configuration to move the body forward, then hinges to raise the feet off the ground while the pistons reset. Meanwhile, another identical set of pistons takes the next inchworm step. Very ungainly but it works. Still, even this is limited by the speed of piston extension and that's only about 5m/s. In this case, there's no "cosine loss" from pushing an otherwise unpowered leg, but there's no gain from the lateral length of the leg, either. Still, there's only a small structural panel on the end of the each piston to prevent slippage. Thus, the mass the pistons are moving is reduced to the main body of the walker, and the other set of legs resetting during the step. This is less mass than the body of the rover plus longer legs with multiple joints, so the piston motion is faster. So, at the bottom line, complexity = slow for walkers. And walkers are already slow to begin with. Thus, if you're after speed, use rover wheels. But if you're after smooth, walking motions, then knock yourself out with multi-jointed walkers.