GoSlash27

noahtech, No, the engines will both respond to your throttling and controls simultaneously. The problem is that they can't simultaneously flame- out. The instant one engine flames out, all of the intakes will feed oxygen to the running engine. This is due to how the game engine works; it deals with each component of your ship in the exact order it was assembled. Left intake, add o2. Left intake, add o2. Left intake, add o2. Left engine, but it's flamed-out, so no air drawn. Right intake, add o2.Right intake, add o2. Right intake, add o2. Right engine and it's running, so give all the air to it. So the left engine stays flamed out while the right engine keeps chugging away. I'll get you the craft file shortly... http://wikisend.com/download/124238/laythe-probe-launch 2.craft You're welcome, and happy flying! Best, -Slashy

Well, he *did* mention non-spaceplane SSTOs. I have a crazy- efficient vertical lift SSTO that I use for lifting large, bulky assemblies (station sections, ship subassemblies and the like). Never used it for interplanetary travel, but no reason why it *couldn't* be used for that. Only downside to a vertical lifter is that it needs more engines to do it's work and doesn't get you 100% recovery. Best, -Slashy

Know how I know you didn't read the actual OP? The man asked for a step-by-step process and variable names to use in his utility and this is what I gave him. More reading, less being snotty please and thank you. -Slashy

If you're looking to calculate the DV for one stage, you would only include the wet mass of stages that are being treated as payload. So here's the process for doing it: Mp is your payload Me is your engine mass Mt is the mass of your empty fuel tanks Mf is the mass of your fuel Mp+Me+Mt+Mf= Mw; your wet mass Mw-Mf= Md; your dry mass Mw/Md= Rm; your mass ratio LN(Rm)= Cdv; your delta v coefficient. Isp= the specific impulse of your engine. Cdv*9.82*Isp= DV; the total delta v for that stage. Best, -Slashy

Sorry, but I'm afraid not. The math cannot predict (and you cannot mathematically define) how imperfectly you will follow the ideal path. Your best bet is to pad the budget a certain percent based on how much more you need by your experience, which is what you're doing. You should also look at your technique and figure out *why* you're not matching the expected figures. In your case, I'm guessing you're not gravity turning as early or aggressively as you could. You need to be going horizontal as fast as you can as low as you can (without smacking into the terrain) to get the best results. Best, -Slashy

^ What he said. And I'm not sure what you mean by "huge time waster". The alternative would've been assembling and disassembling boosters in the VAB with various combinations and taking notes until I'd decided I'd confirmed that I had the best option. *That* is my opinion of a huge time waster. IAC, that's not how it works (at least not on mine). All of my engines are on the same sheet and the results of the calculations are next to every engine assuming I'm using that engine, so the problem is solved for every engine simultaneously, allowing me to tell at a glance which engine I should use. Plugging the fuel required into the tank section will have it instantly tell me how many tanks of what type to use. The various rocket models require that I manually transfer specs into the stages for the engines and tanks I want. I have models for various rocket stack types, such as a layer cake stack, 1-2-4 layer cake, several types of asparagus, twisted candle, and 3 stage drop tanks. They will keep track of the minimum acceleration of each stage, DV for that stage, and cumulative DV for the entire vehicle. Best, -Slashy

Yeah, I was afraid I was gonna see that. The test using the gravity turn is flawed. You're accelerating far too rapidly, which grossly inflates the drag losses. This makes the vertical ascent appear more competitive than it otherwise would be because it spends less time accruing ridiculously wasteful drag losses.. You should try turning down the heat to where you don't have a vertical meteor and compare them that way. IAC, the original question has been officially and definitively answered: The most efficient profile to the Mun is a prograde gravity turn direct injection. Best, -Slashy

Sorry I took this long. I was doing other things... My DV figures from my test using the Pathfinder: 1) Prograde gravity turn with direct injection: 5230 m/sec 2) Prograde orbit followed by injection: 5,260 m/sec (+30 m/sec) 3) Vertical direct injection: 5,570 m/sec (+340 m/sec) Now to see the video... Best, -Slashy

This is exactly what I'd set out to get across (badly) If the newbie is asking how to use the formula, don't say "it's really tricky, use a mod" Likewise, if the newbie is asking how to use a mod, don't say "suck it up and learn the maths". Thanks, -Slashy

Okay, I'm back. Thinking about this on my way to work, I have to add another disclaimer: 120 tonnes is a huge payload! I don't normally design rockets that big, so my lack of experience may cause me to wind up designing a sucky rocket. I'm just doing it to illustrate the process itself. /disclaimer So... 120t and 1200 m/sec. Don't care about the acceleration. My spreadsheet says that the LV-N is best for that job and I need 23.2 tonnes of loaded tanks. That's an x200-32 and an x200-8. 24.8 tonnes for the stage, 145 tonnes for the preceding stage to lift. I plug the numbers in and it says a mainsail will be ideal for this. 38.3 tonnes for the loaded fuel tanks, which is a Jumbo 64 and an x200-8. Total stage mass 46.5 tonnes, total vehicle mass 192 tonnes. Now we need 1G minimum acceleration, 192 tonnes of payload, and 2000 m/sec DV. Plug them in, and... This one's very close, but 6 skippers can do the same job a few tonnes cheaper than 3 mainsails, so we're going asparagus. I move into my asparagus model I can asparagus these around my mainsail. Each radial booster is a single skipper with 1 jumbo 64. Total mass is up to 473 tonnes. This leaves our boost phase. payload 473 tonnes, DV 1500 m/sec, atmospheric Isp, and at least 1.5G acceleration. Plugging in the numbers, it says 7 mainsails is the way to go. So another round of asparagus staging (or something similar). Without the asparagus staging, I'm looking at a stage mass of 426 tonnes and a total vehicle mass of 899 tonnes, but I can improve that with staging. Plugging the requirements in my asparagus model... Each radial booster is an S3-7200 with a mainsail. Total vehicle mass 755 tonnes. That's pretty much how the process works using a spreadsheet. From there, I could juggle my requirements, design for different objectives and schemes, etc. Not saying this is a great rocket design (I just did it off the cuff), but illustrating how it's done with a spreadsheet as opposed to building in the VAB with a DV readout. Best, -Slashy

Sure... but just a reminder, -->my goal isn't to convince anyone to slog through the math who doesn't want to. It's to convince people to not discourage newbies who want to try it.<--/disclaimer So the process of designing a lifter to lift a 120 tonne payload with a total DV of 5500 m/sec would go like this: 1: break the launch down into phases. Since the total DV is more than 4300, that last 1200 must be an orbital transfer stage That leaves boost (1500), transstage (2000) and insertion (700) I start with the payload on the insertion stage. I plug into the spreadsheet the: *local gravity (9.81 for Kerbin), *required acceleration (don't care, but I'll set it at .5G) *payload (120) *DV (1200) *number of engines I intend to use (1) It now displays next to every engine how much mass of fuel and O2 I need for that stage, How much mass in loaded tanks I need, Total mass of the stage + payload, and acceleration I will get. It also displays a recommended number of engines for 1.5G/1G in atmosphere and 1G/.75G/.5G in vacuum. Aaand that's my alarm. I'll have to pick this back up later. -Slashy

10 units out of 45. This is a very minimalist craft, and 10 units accounts for an awful lot of DV. TWR for all cases was a maximum of 2G. I held the TWR to the standard for typical prograde profiles* and left it running hot for the vertical ascent at 2G for a reverse terminal velocity fall into space for the vertical. * Prograde profile was gravity kick at 7KM, 68* pitch at 15KM, 45* pitch at 25KM, and 23* pitch at 35KM with a constant, linear reduction throughout. 1 -> 2G acceleration in the vertical boost phase, .75G acceleration in the transstage phase, and .5G in the injection phase. I'll get you exact DV numbers (+/- .1%) tomorrow, but trust me... it's a lot. I usually arrive on station outside Kerbin's SOI after correction burns with more than 6 units remaining, so we're looking at at least 500 M/sec DV above the usual 4,900 for a munar mission. Best, -Slashy

Absolutely it can be done. Most of the folks participating in this thread have done it. But how is your interplanetay SSTO spaceplane coming along? Anything we can help with? Best, -Slashy

We haven't heard from the OP for a while. How's it going, diegzumillo?

FWIW, I tested out this proposition using one of my "pathfinder" probes to get some empirical data. Using the prograde "gravity turn" direct injection (yeah, I know. save the hate mail), I was able to hit a munar apoapsis with 10.01 units of fuel remaining. Using the direct vertical ascent, I had 4.46 units remaining. Ironically, this actually got me a rendezvous due to the timing, though I wasn't shooting for one. Just blind luck. As a check, I ran the prograde to LKO, then transfer prograde burn to Munar apoapsis. 9.66 units remaining. Result: The direct prograde injection was the most efficient. The prograde LKO/ TMI burn was next. The vertical TMI was by far the least efficient of the 3 approaches. I can run the numbers and get you DV figures tomorrow if you'd like them. Best, -Slashy

Another goodie: The "Pathfinder" probe http://wikisend.com/download/791958/pathfinder.craft This simple little probe sits in Kerbin's orbit around Kerbol just barely ahead of the planet outside it's SOI. It's job is to allow me to figure out my transfer windows. When I want to go somewhere, I "fly" this craft in the tracking station. Set up a maneuver node for planet I want, then drag it around until I have an intercept. The burn timer will tell me how long until my transfer window opens up. It's like a poor man's "alarm clock" without installing a mod. It's a cheap little vehicle (less than 3,000 rooties) and is pretty simple to get into position. Just launch prograde at dusk, set your apoapsis to escape Kerbin's SOI, and burn radial to circularize.

This thread is a place to share helpful contraptions that you've made that help you conduct your ops, but don't directly participate in missions. As an example, I'll post my Mobile Beacon. http://wikisend.com/download/872880/beacon1.craft This is a simple, cheap little aircraft. It doesn't explore, collect science, carry payloads or anything like that. The entire point of this drone is to fly to a point on the surface and sit there in order to highlight that point as a marker. As an example, these points are highlighted so that I can clearly see them, day or night. I have a marker to designate where a station should be when I launch a spaceplane to intercept it. I have another pair of markers to mark the point where I should be when I start my retroburn and where my flightpath should intersect the surface when I end it. I also have a trail of markers lined up from the runway out to the mountains so I can see my lineup before I can see the runway. Pretty useful little buggers, even though they don't actually "do anything". So post the handy little devices that you've come up with to make your life easier! Best, -Slashy

Ah, but the hole in your reasoning is that you *think* it *should* be faster. You haven't actually tried it, whereas I do it all the time. I know which approach is quicker. Thinking about it.... I suspect that the disconnect is in how you imagine the spreadsheets are used. I think you're imagining them as being used in a similar role as the mods, but they're not. I think that you picture them as being far more constrained than they actually are. It's hard to picture the implementation of math in a context other than how you use it, but the natural progression is to *not* apply the math simultaneously as you build, but rather apply the math before you build. It's just plain more convenient, just as using a mod as you build is the most convenient way to use a mod. Someone who's experimenting to come up with a good design (even if doing the math by hand) would *never* build random combinations of parts in the VAB and then figure out what the DV is after they've built it. They would try different combinations on paper, figure out which works best, and *then* build the ship. Building the ship is a complete waste of time in the process of figuring out the best ship, so we just plain don't do that. Eventually, we get sick of doing the math the hard way and set up a spreadsheet to do it the easy way. Eventually, it occurs to us that we've been doing the whole thing wrong and start working the equation backwards instead of forwards. In the process of designing, "DV" makes a much better question than an answer, right? So we start applying the math that way... and get sick of it and build a new spreadsheet. And now suddenly we're theoretically building the same stage with all possible different engines at the same time with just enough fuel tanks to do the DV we need. and simultaneously finding the total mass and price tag for each one. A few clicks, and we're accomplishing what would take weeks to trial-and error in the VAB. And the process continues to feed on itself, but what doesn't change is *how* the math is used: Not during construction, but rather before. We actually have no need for a display of things like cost, mass, DV and the like when we're building (except, perhaps, as a sanity check). We already knew all that before we started building. Best, -Slashy

Sorry, I should've been more specific. I know what the theoretical answer is for the difference between the two states. I mean the expenditure required to make it happen. I look forward to seeing the results. Best, -Slashy

Absolutely not. I have no idea how I'd approach modeling a vertical ascent to the mun. The most definitive result would be to build a ship that has the absolute minimum DV to get you there on a prograde direct ascent, then try it with the vertical ascent. If it runs out of steam before achieving a munar apoapsis, then you have your answer. Even better... what is the minimum DV required to achieve a 12 Mm apoapsis? Best, -Slashy

The term "gravity turn" has a different meaning in the KSP community than it does in the real world. 1) "Gravity turn" when you hear it on this forum, refers to a gradual reduction in pitch over the duration of the flight from vertical to horizontal, thus yielding the most efficient balance between gravity losses and drag losses. 2) You may also see the term "gravity turn" or "gravity kick" used to describe the point at which a rocket transitions from the vertical boost phase into the gradual prograde curve. 3) Occasionally, somebody will use the term "gravity turn" as it's actually used in the real world; a rocket that slowly "falls over" during launch at a rate sufficient to generate an efficient profile without needing active vectoring. A true "gravity turn" launch will continue to rotate beyond horizontal to generate a radial-in burn to circularize all in one shot without throttling or restarting the engine. These are very rare in KSP, so when you hear this term, it's almost always in the first or second context. Best, -Slashy

I got invited into this discussion, and Wanderfound has already said what I would. Vertical ascent is just plain inefficient due to gravity losses. Far more efficient to do an insertion burn to orbit and then transfer to the mun. But directly injecting into a munar transfer without stopping to circularize is the most efficient way to do it in terms of DV. best, -Slashy

^ This is an awesome idea! -Slashy

The atmosphere wins on Eve. It's very easy to land on Eve and very difficult to get back off. Best, -Slashy

I have a crazy suggestion that I think would make the game awesome: Have a very simplified version of KSP inside KSP for use as a mission simulator. It wouldn't perfectly replicate the physics of the "real" KSP univers, but would allow players to test their vehicles and practice their missions/ procedures within the framework of the career game. Users can do this now to their hearts content simply by using the sandbox mode, but how cool would it be to have a "simulator facility" that looks and acts like a sim, where users can adjust the date, place their craft on the munar surface (or in orbit), etc. It could cost a certain amount of funds per hour to operate. Best, -Slashy