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.

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.

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.

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.

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.

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.

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!

if they cannot put 60t of weight on top than you have to put an asterisks by the claim of 62t to orbit, otherwise DAL59 or someone of that thinking is going to twist that into a belief that they actually can push a PL (say H2/O2 . . .or .. .unobtainium) into LEO. This is actually a double asterisks because it likely a claim based on B5 performance, a rocket that has not flown. As I said if the increased the performance of the engines, including M1D vacuum engine, then (see below at worst case scenario a 13% increase in engine performance converts no gain in horizontal velocity into a 50% gain of velocity relative to a flat trajectory along an isoquant). Remember, I made the claim in the beginning that there were fuzzy stats . . fuzzy factoids. That claim of 62t to orbit is clearly a fuzzy fact even by your own statements. Secondarily, if you are pushing S1 trajectory to 2.5Mm above the earth simply to give S2 long enough time to circularize then its no longer 62t to LEO, its something else to something else. Lets go backward with the facts. If you are 99/100% to orbit (tangential component of velocity) you only need what. 0.02TWR on mostly a flat trajectory (just to hold isoquant, 100% cosine loss). With a cosine loss of 0.5 you need 0.023TWR (adjust TWR to reflect gravity at altitude) 98/100% 0.0396TWR, 0.045TWR 50% loss 90/100% 0.19%TWR, 0.219 80/100% 0.36%TWR, 0.414 (this is what 62t to orbit w 60/100% 0.64%TWR <------ 5000 m/s, 0.736TWR for 50% cosine loss (This is approximately what M1D on last FH launch delivered at its start up burn. The craft was losing some but not a horrific amount of vertical velocity. 40/100% 0.84%TWR <------ 3120 m/s, 0.966TWR for 50% cosine loss Just going by this the S1/S2 separation would have had to occur going 2000 m/s faster than FH#1 S1/S2 sep. Cosine losses mean that thrust is given to gravity and not into kinetic energy (whether it be height or hoovering). If you are significantly giving thrust to gravity then you have inadequate thrust to make it to desired orbit, If you devote sufficient enough S1 thrust to generation of apoapsis, the it translates to a loss of horizontal velocity in the S2 which means a greater amount of cosine losses. If you are playing with TWR significantly below the tabulated values then your rocket engine will have significant cosine loses. Centaur used hydrolox, which has ISP in the 460 range, they can afford some cosine losses. But what we are talking about is a strict 200 km LEO orbit, not some elliptoid shaped thing. While this may seem trivial, the ability to convert thrust into energy is dependent on speed. (Why I keep reposting the physics basics over and over again). E = F * d. The faster you travel they greater distance that is covered when force is applied. Ideally if you want to go interplanetary with a massive amount of weight, the best place to make that push is from as low an orbit as possible in which the loss of energy due to drag is less than the loss of energy due to loss of orbital velocity of a higher orbit. You can of course kick out of an elliptical orbit, but our metric here is not that, the metric is what mass was delivered to that ideal LEO. The logic for this is this; lets assume that orbital boost is based on a ~325 ISP system. Your payload is a 460 ISP system, it makes less sense to put the PL into an elliptoid orbit rather than handing more PL mass to so that the more efficient PL can kick to higher orbit. The Centaur _HAS_ ISP of 460, so that its ellipsoid is only a partial loss of energy if it pushes out from the ellipsoid . . and its still better off than M1D because it had higher ISP during the circularization part of its burn. M1D to achieve its claim needs to efficiently place that 62t in an LEO orbit so that the vehicles unobtainium based fuel system can send it to its interplanetary destination. Why would anyone want a 62t payload . . . . one particular reason is to used that PLs propulsion system to drive out an interplanetary orbit. Conserving the fuel for one earth orbit and a burn outward (assuming that the launch occurred from an optimal launch to inclination) then a powerful enough second stage to push to LEO and hold at LEO just long enough to intercept the outbound burn point, followed by a transfer burn (as part of the PL 62t).

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.)

??? 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.

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.

That is correct. The phenomenon is referred to as "cosine loss" (try searching for that phrase on the forums, you'll find a lot of talk about it). An engine that's thrusting perfectly prograde contributes 100% of its thrust in the prograde direction (since the cosine of zero is 1). If the engine is pointed any other direction than prograde, then the component of its thrust in the prograde direction is the full thrust times the cosine of the angle. It's basic trigonometry. The component of a force along an axis is proportional to the cosine of the angle it makes with respect to the axis. It works with any force, not just rockets. Ropes, for example. If you've got a 100-pound weight, and you attach a rope to it, and pull straight up on the rope... what tension do you have to put on the rope to lift the weight off the ground? 100 pounds. But suppose you have a *horizontal* rope held taut (clothesline-style), with you at one end and a friend at the other, and the weight is hanging from the middle, so that there's only a few degrees of "sag" from the weight. How hard do you both have to be pulling now in order to lift the weight off the ground? A whole lot more than 100 pounds! That's because the vertical component of the rope's force goes with the cosine, which will be small if the rope is mostly horizontal with only a little bit of "sag". Or, another way of experiencing this: Try hanging from your hands, with your arms straight overhead, for thirty seconds. Not so hard, right? Now try to do the same thing but you're supporting your weight by holding your arms straight out to your sides. That, my friend, is cosine loss. You are correct, that is wrong understanding. They only put a slight amount of thrust forward, since most of their thrust is directed sideways (fighting each other) rather than forward. Be careful not to conflate "energy" with "force". A rocket expends its energy the same place no matter what its situation: out the exhaust nozzle. Imagine that you have two rockets that are pointing perfectly equal and opposite each other, so they cancel out. Where does their "energy" go now, hmm? Simple: Out the exhaust nozzle. Their force completely cancels out, which is why they don't go anywhere. And if you nudge them slightly, so they're not quite perfectly opposed... then there will be a slight drift to one side because they don't perfectly cancel each other out. In other words, the cosine is non-zero. The main source of confusion is that you've focused on "energy" as the concept here-- it's not super relevant. Rockets are poor choices for talking about conservation of energy, because they expend such huge quantities of it and it's very much not a closed system (that's the whole point!) and the vast majority of the energy goes out with the exhaust rather than moving the rocket itself. Focus on the force instead, and you'll have a much better picture of what's going on. Yes, and the force that the soap moves upwards with is much less than the force you're pushing your hands together. Again, because of cosine loss. You could squeeze your hands together really hard to try to make the soap squirt upwards... but I could put one little finger on the soap pressing it down, and you wouldn't be able to budge it. Not because I'm a whole bunch stronger than you, but because you're fighting cosine loss and I'm not. I've got a better mechanical advantage.

The amount of efficiency lost by a long burn is a function of altitude. The lower your altitude, the tighter the turn radius of your orbit and the faster you're moving around it. Thus, when doing a long burn at low altitude, your ship swings through a greater arc centered on either side of the node. The bigger this angle, the greater the cosine loss due to off-angle thrust. When orbiting Kerbin at about 100km, your orbital period is about 28 minutes. Thus, during a 4-minute burn, your ship will travel 1/7 of a circle, with 1/14 on either side of the node. 1/14 of 360^ is 25.7^. The cosine of 25.7^ is 0.9010. This means that AT WORST, at the very beginning and very end of a 4-minute burn, you're only 90% as efficient as you are when passing through the node. Between the end points and the node, the efficiency is better than 90%. So that's perfectly acceptable. Even a 5-minute burn is fine. But that's where I draw the line, FOR BURNS IN LKO, for the several different reasons: First and foremost, that's all the time I want to sit twiddling my thumbs in real time while nothing happens but the engine running. Second, burns any longer than that can push your Pe down into the atmosphere if you start at less than 100km orbit. Third, the cosine loss starts getting bigger than I like. So, if the burn time is going to exceed 5 minutes, I either break it up into 2 parts or I add more TWR to the design. To get an ejection burn from LKO <= 5 minutes, you need a TWR >= 1.75 for that stage. NOTE, however, that the efficiency loss only really matters for chemical rockets, not nukes and ions. They've got dV to spare. So for them, the 1st 2 reasons above are more important than the 3rd. Besides, Oberth effect is proportional to reaction mass, so chemical rockets benefit from it the most, nukes get only meh, and ions essentially zero benefit. Which means, you for them, don't need to be in LKO (see the below). Also note that the longer your orbital period (so the higher your altitude), the less cosine loss you have for the same amount of time. This is why I only care about burn time for ejection burns. When in interplanetary space, or when doing capture burns, you've got a huge turn radius so there's much less cosine loss.

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.

@Sans Solo: Most likely, you are seeing a difference between your results and predictions because of a combination of cosine losses (very minor, unless you accidentally started by thrusting in the wrong direction) and gravity losses, that simply indicate in this case that you've changed orbits with a non-instantaneous burn ... which you already knew and others here have said. There are three major sources of loss that I know of: drag, gravity, and cosine. Drag is atmospheric loss--a problem on launch but not on the Mun. There's no easy way to figure it because it depends very much on both the design of the rocket and on the skill of the pilot. Gravity loss is the effort you need to put into preventing falling down to the surface--inasmuch as orbit consists of going sideways relative to the direction of gravity such that you miss the ground, you encounter gravity losses during the parts of the burn when your rocket is not burning at a ninety degree pitch. That's easier to figure out, but not on the fly. It would be possible, for example, to take off from the Mun's surface, pitch over to horizontal immediately, and attempt to make orbit that way. Assuming no terrain obstacles (we can call hitting a mountain a special case of drag losses), only the most insanely powerful of rockets would be able to add horizontal speed quickly enough to make orbit before the vertical component (gravity) pulled it back to the ground. Therefore, the rocket needs to devote some thrust to countering that vertical component. The key to it is that the most efficient ascent is the one that only devotes exactly the required thrust to keeping your vessel--well, aloft seems entirely the wrong word for airless bodies--but without unnecessary thrust additions (wasting fuel) or subtractions (causing you to lose altitude that you have to make up again ... wasting fuel). For an easier example, imagine a hypothetical craft that always has a TWR of exactly 1. It can float, but it cannot make orbit, because all of its thrust goes to keeping it off the ground and none goes to adding orbital energy. Contrariwise, such a craft already in orbit is much more capable, because it comes loaded with the orbital energy; there's no risk of falling into the ground, so you can afford to take your time with less powerful-but-more-efficient rockets. This one is mostly dependent on pilot skill; to minimise the loss, look up constant-altitude approaches and landings. Cosine loss is the part of the thrust vector not directed through the rocket's centre of mass. This component may be utterly necessary to your survival (using gimballed engines to avoid a special case of drag losses, for example), or it may be a convenience. A common source of cosine loss is in unbalanced or asymmetric rockets. The stock shuttles (and the real Space Shuttle) have high cosine losses because the engines have to point in an odd direction to compensate for the big, engineless fuel tank's effect on the centre of mass. You can encounter it also in situations where you have an oddly-oriented part as a control point (such as a surface-mounted docking port) such that when you point it prograde, your engines point elsewhere. You can throw away an entire tank of fuel and go nowhere; for an exaggerated example, imagine a booster attached sideways to a pod on the pad. You can point prograde, thrust all day, and never go up; that's cosine loss. This one is dependent mostly on rocket design, though it's completely unavoidable unless you design your rocket with no gimbals, asymmetric thrusters, unbalanced payloads, control surfaces, or RCS jets. Reaction wheels are okay.

The authors of about 6 scientific papers that I've read on this topic tend disagree with you You can't "just take the Integration", because sometimes the Integration doesn't even have a closed form (one that can be written as a formula). It matters in which direction, because ... That's cool and all, but what about the cosine losses in between horizontal and vertical? The optimal path is not a) a straight line or b) a quarter-circle or a cosine or any simple form. The optimal path is a strange curve that looks approximately like SQRT but isn't. That's what it looks like: Along this path, the cosine loss depends on your radial velocity around the body (because of the centrifugal force) and your current velocity angle. Your current velocity and angle depends on how much you have slowed down on the path before, and on the previous cosine loss. Your previous cosine loss depends on the previous radial velocity around the body and the previous velocity angle. And those depend on the cosine loss before that... This kind of recursive relationship can be expressed mathematically as a system of coupled differential equations. In its simplest form, these are: dv/dt == g * (TWR - cos(beta)) v * d beta/dt == g* sin(beta) This already is hard to solve, but possible (only for angle and velocity - not for altitude/downrange distance!), but mind you: this assumes Flat Earth Constant g Constant TWR No Rotation Which obviously breaks in multiple ways in KSP. Now any attempt to expand the model a bit to account for a spherical body, changing g, changing TWR, and rotation, you end up with shenanigans like this one: Containing mathematical functions that I haven't even heard of. Mind you, even these monstrosities come with a huge list of assumptions like "but only if the velocity is much lower than orbital velocity and rotation is low and it's a monday evening and it's full moon". Believe me guys, I *wish* it were as simple as "just add the second dimension". And I have read a lot of comments and a lot of threads that say "oh that should be trivial". But if you look at the physics, and if you try it out in practise you realize that it's not at all simple. edit: Click here for more fun stuff

Yep, this is called a "cosine loss." The amount of wasted thrust is proportional to the cosine of the inclination (0% wasted if the engine is pointing exactly where you want to go, 100% wasted at 90% inclination). The effect on delta-v would be the same, since cosine losses decrease the amount of usable thrust generated per unit of fuel consumed. It's akin to lowering the ISP of your thrusters. The above should hold true for one-direction thrusters or regular engines. I've never really delved into it with the multi-direction thruster blocks, but I think it would work the same way, since using the additional thrust directions (which are pointed even more in the wrong direction) would not be expected to improve efficiency. I'm not a MechJeb user, but I believe it provides some data on cosine losses. Don't know if this includes info from RCS, though. (My very first post on this forum was on the same topic, so you're in good company!)

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)?

You're conflating "gravity loss" with "cosine loss" (added emphasis in quote above for clarity). Those are different things. Cosine loss happens when you're burning off prograde (regardless of what direction you're traveling). Gravity loss happens when you're burning off horizontal. Ideally, you'd like to avoid both. The only way to do that is to burn prograde while traveling perfectly horizontally. If you're not traveling horizontally, it's possible to avoid cosine loss (by pointing prograde) or gravity loss (by pointing horizontally), but not both at the same time. Yes, prograde is good, to avoid cosine loss. But even when you're firing perfectly prograde: any time you are thrusting when you are not traveling perfectly horizontally, there is a gravity loss. The amount of gravity loss is proportional to the sine of your thrust angle above horizontal.

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

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.

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.

Long burns have two inefficiencys: cosine lossess and lower average burn velocity (oberth). Separating the two is impactical (impossible?). While there is little utility to do so, you can approximate your cosine thrust losses by taking the integral of cosine over your burn angle and time. A more complicated fuction can determine dV losses. The loss of work (by engines) is beyond what I care to derive.