BlazeFallow

Done. I took the question about "basics" to mean general spacecraft assembly, getting to orbit the first time, etc. I would say that things such as Docking, dV management, aero/litho braking generally fall under the "advanced" category, and took me much longer to get my head wrapped around. I completely agree with XKCD's little graph about understanding orbital mechanics. I have learend so much more in my time playing KSP than I ever did in my physics classes (sorry professor.) At the same time, I'm able to do more advanced things in KSP because those physics classes gave me the basic tools needed to comprehend the reasons behind why stuff happens the way it does in orbital mechanics and energy transfers. Huzzah.

I completely agree Jim. My equation is just meant to give a rough estimate of what it would require. So those individuals trying to launch a 2KT payload to orbit can just do the maths quickly and realize "Holy Kerb! I will need an 10KT rocket to do that!" Of course, it gets even more difficult when you are doing horizontal staging rather than vertical, as the engines from the first stage continue to fire throughout the rest of the stages as well, so their weight would be added as the payload weight at the beginning of your iteration, but should not be accounted for (only the new stages as you grow outward). But that's just their mass, their thrust would still be present. The math gets pretty fuzzy and I admire and respect the folks who made MechJeb and Engineering Redux for implementing a bunch of crazy maths my brain has a hard time wrapping itself around. I do try though, as I'm sure is evident by my attempts shown in this thread.

Hey Guys, So I have my final Equation and the method for solving it. Y = ((Y - P - (S * TWR * Y * 9.82)/T)*Q + P + (S * TWR * Y * 9.82)/T) * edV/Isp To solve we then re-label the function to match the standard algebraic function y = f(x) y = ((x - P - (S * TWR * x * 9.82)/T)*Q + P + (S * TWR * x * 9.82)/T) * edV/Isp At this point we will find our solution where y=x. So we can plot out both of these functions in a graphing calculator and find the intersect. You could also find the intersect by hand if you hate yourself or are just a huge fan of simplifying complex algebraic functions in your head. The sounds about as fun as Seppuku to me though. Either way, as AmpsterMan stated this is just for a single stage structure. You can take the equation and turn it iterative though. Meaning run it once for your last stage for whatever amount of dV you want it to have, and then take the resulting Y value and plug it into the equation again as the X value and whatever dV value you want that stage to have. Do this as many times as you want stages and your end Y value will be the full weight of your whole vehicle as each stage treats the stage above it as its payload. Then with the Y values you plug that into the Z TWR formula to get the number of engines you need to get the TWR you desired. Note also that this equation is set up for linear staging, not asparagus or boosters, as it is not set up to use the thrust of the next stage in the calculations. That would require a slight modification which I may mull over and put up as a follow up post. Cheers! BlazeFallow

I think that the last equation I came up with which relates everything to Y is valid. I just put it in to Wolfram and let it do all the complex math I am incapable of (yeah, lazy way out, but I did the hard leg work of deriving the equations from my understanding of KSP's implimentation of orbital mechanics... so there's that) It came up with a value that was pretty much what I was expecting. Which is that with a dV of 5000 and an Isp of 420 and a payload mass of 2000T I would need lifter of roughly 11000T And now that Y is given, I can then derive from it X, and Z, giving me the number of engines, and the total quantity of fuel. Huzzah! Granted, that 11000 could likely be a lot lower with multiple stages, as the number given is for effectively a SSTO design. Splitting it into smaller DV chunks and then using the Y value given as the new P for the next roung could possibly result in an overall lower Y value.... MATH

Alright... I think I have come up with a monstrous equation the relates all things to Y. With Y = X * edV/Isp And X = (Y - P - SZ)*Q + P + SZ But Z is still in the mix. Let's solve that problem TWR = Z*T/Y*9.82 TWR*Y*9.82 = Z*T Z = (TWR * Y * 9.82)/T So then we have: Y = ((Y - P - (S * TWR * Y * 9.82)/T)*Q + P + (S * TWR * Y * 9.82)/T) * edV/Isp

You are actually making the exact same error I was originally making when I first develope dthe formula. It originally looked like: X = P + Q*Y +S*Z Then I realized that Y included P and S*Z in it, so applying Q to the full Y can't happen, as Q only applies to the fuel tanks. The same is said about X. X is the full mass of the dry craft, so X includes P, S*Z and the dry mass of the tanks. Thus you cannot apply Q to X itself, but first need to remove P and S*Z from X so that you are only applying Q to the tanks. Does that make sense?

Absolutely. Also i completely forgot to include the reason for my doing this. I want to end up with a way in which to omptomize the following problem: Given the following static values: dV Isp TWR = some number > 1 P = Payload tonnage Q = tank dry/wet ratio (ussually around 0.11) S = Engine Weight T = Engine Thrust Calculate the following: X = Mdry Y = Mwet Z = # of Engines On to your question: X = (Y - P - SZ)*Q + P + SZ (Y - P - SZ) represents the full mass of the fuel tanks. Multipliying by Q (the dry/wet tank ratio) results in the dry mass of the tanks (as derived from Y wet mass) then adding back in the payload mass and engine mass you get the dry weight of the entire craft, here represent by X = Mdry.

Hello Folks, I have been kind of obsessed with Optimizations as of late. So today I sat down and started making some formulas. Now I wish to validate my formulas by submitting them to you good people. Please assume the following values: X = Mdry Y = Mwet Z = # of Engines P = Payload tonnage Q = tank dry/wet ratio (ussually around 0.11) S = Engine Weight T = Engine Thrust So that given the following static values: dV, Isp, P, Q, S, T, TWR = some number > 1 Calculate the following: X = Mdry Y = Mwet Z = # of Engines With the above we can apply it to the dV equation, yielding: dV = Isp * Ln(Y/X) Keeping in mind that the values that KSP gives us for Isp of engines are in seconds so we must multiply them by 9.82 to get the Isp for this equation Deriving this yields: dV/Isp = Ln (Y/X) edV/Isp = Y/X Which then yields: Y = X * edV/Isp The thing is that X and Y are dependant on one another. As tanks are not massless when empty, X=P simply isn't true unless X=Y in which case dV will = 0 For this I came up with the formula (please validate my maths below, as I'm not 100% sure on it) X = (Y - P - SZ)*Q + P + SZ I then algebra'd the equation to relate it to Y X = QY - QP - QSZ + P + SZ X - QY = -QP - QSZ + P + SZ -QY = -QP - QSZ - X + P + SZ QY = QP + QSZ + X - P - SZ Y = P + SZ + (X - P - SZ)/Q That's great and all, but how do we optimize for a good enough TWR to get off Kerbin. For this we have the TWR equation: TWR = Z*T/Y*9.82 Related to Y this becomes: Y = (1/TWR)*Z*T/9.82 So here we have three equations for optimizing: Y = X * edV/Isp Y = P + SZ + (X - P - SZ)/Q Y = (1/TWR)*Z*T/9.82 This is where my brain starts to hurt. Can someone let me know if I'm actually on to something here, or if my brain is broken?

Somehow I visualize a skip maneuver to be such: Say you have an Ap of 80km, you dip your Pe to 30km and are gliding towards it. As you approach you craft begins to aerobrake, causing your Ap to dip down tot he point where your Ap and Pe swap places on your orbital track. Generally in aerobraking such as this, your new AP stays behind you as you continue in a suborbital/ballistic trajectory down to the surface. In a Skip maneauver however, do to aerodynamic forces or inertia or whatever really, your Ap moves from behind your craft to in front of it again so that you are indeed flying back in an upward direction, but still on a parabolic flight path down to the surface. That last part is the important one to me at least. Because if you just pass through the upper atmosphere and reduce your Ap, but your Ap and Pe never swap places, then that (again to me) just means it's an aerobrake, and not skipping along the atmosphere. Maybe what I say makes sense to the others here as well?

I have read through about 4 different threads discussing the issue of ideal velocities and gravity turn heights, and I would like to share my findings and assumptions here. First K^2 offered mathematical proof that terminal velocity is the optimal ascent velocity, something that many kerbonauts have assumed for a while now. The added complexity comes from adding in the gravity turn. The complexity comes from the following list of assertions: - In KSP gravity as an effect on your craft is not a constant, and thus cannot be treated as a constant, but rather a formula based on the distance of your craft from the surface as compared to surface gravity. Thanks to Capi for this one. - You get a greater benefit from the Oberth effect from starting your gravity turn earlier. - You have to contend with more atmospheric drag for a longer time, thus eating away some of your dV by fighting atmo, by starting a gravity turn earlier. - Your engines will also have a (generally) much higher ISP at higher altitude, thus you will get more dV from your rockets the sooner you can get to that higher altitude. The last item is much more pronounced at 0-10km at which point your engines are already well above low end ISP and are quickly reaching peak ISP. The rate at which the ISP changes is almost parabolic in nature from what I have noticed. So the problem that I suppose someone who is MUCH better at math than I am (not saying much as I can barely do any calculus) should try to tackle is this: Given that a craft will be traveling at terminal velocity v for a given altitude h, what is the dV tradeoff between counteracting drag but gaining more from the Oberth effect, when also accounting for an ISP that is dependent on altitude h Can someone please tell me if any of my assertions are incorrect or if my maths are being way too fuzzy. Also please comment on whether or not my ending pseudo equation makes sense.

I voted for Giggle's R-2. After flying the finalist planes once again, I just have to give it to the R-2 for having such amazingly smooth controls. Landing the thing is crazy easy, mainly due to its great lift ratio and pitch control.

Thanks! And yes, the craft ended up being more advanced than originally intended, but I'm glad that you enjoyed my favorite design feature (the the Emergency Escape Jet - EEJ) as much as I did. 6th place on someones list makes me really happy . And you are absolutely right, there was a fair amount of clipping used in my design. The forward wings, two RCS tanks clipped inside the forward Y sections, the two batteries and RTG clipped into the EEJ. My main thing though is that I definitely did not ever use the debug menu to clip things (still haven't in any craft I've ever built actually) and none of the items that were clipped were the sort where you had to get the mouse just right in order to place them. You could pick up the RCS's, wings, batteries, RTG's, etc. and move them around and replace them without issue. The one difficult one would be the RCS tanks in betwen the two fuel tanks. You just need to have zoomed the camera in so that your view point was effectively inside one of the tanks, but the RCS tank stays green the entire time I'm glad you enjoyed my EEJ too. I feel that it was my one main thing that made my Y Wing different from the other SSTOs. Not just an escape pod or escape system, but an entire self contained spaceplane (by which I mean that it has oxidizer and RCS so it could operate in space, not that it by itself could make orbit from the KSP runway) Yes, the Y shaped fuselage was unlike anything I had ever previously built. At first I wasn't even sure it would work as I wanted, but it ended up functioning great! And I agree, the Y Wing is not really a contender for Stock Craft status, but none of my other SSTOs were as good as this one (I'm not terribly great at designing them) so this is what I had for the competition. I'm stilll glad that I could bring this one to the table and get people thinking about different design techniques, and not just another SR-71-like plane. (No offense intended Giggle, your R-2 looks awesome and I look forward to my test flight with it this afternoon.)

I'll take the 50th position and be happy about it. I honestly did not expect my plane to win this round of BSC (especially with 53 contenders). I just hope that the folks who flew my Y Wing enjoyed the abort sequence as much as I did. Congrats to the finalists, I'll be flying your planes once more and submitting a vote later on.

May I present to you the Y Wing: The Y Wing SSTO class Space Plane gets its name from the Y shape of its hull, a design characteristic that Jebediah claims he discovered "in a dream involving a poodle, 3 orange tanks, and a suspiciously generous elderly kerman..." Noteable Design Aspects: - Y-Shape helps resolve the pesky CoM/CoL issues many space planes experience. - Abort sequence cuts free the center fuselage which is a self contained space plane. - Surface controls are balanced for smooth flight movements. Y Wing Craft File Action Groups: 1: Toggles side Turbojets 2: Toggles central RAPIER 3: Toggles all air intakes 4: Toggles 48-7S Rocket Engines 5: Toggles RAPIER Mode 7: Raises/Lowers center landing gear. 8: Toggles ladder 9: Toggles Antennae 10: Toggles Clam-O-Tron Shielded Docking Port Abort: - Lowers center gear bay. - Decouples center docking port. - Shutdown RAPIER engine for smooth separation. - NOTE: After separation, lower throttle to 1/3 and reactivate RAPIER using AG2. SSTO Flight Path Guidance: - Enable SAS, Start 1st stage, and immediately kill 48-7S engines using AG4 - Throttle up and pull up on the flight stick the whole way down the runway. You'll lift off near the end, at about 115m/s. - Pitch up to ~45 degrees and make for the sky - At 12km lower pitch to 30 degress and maintain full throttle - At 18km lower pitch to 20 degrees - At 22km start throttling back slowly as the air thins. The Turbojets may flame out if you don't manage the throttle perfectly, but don't worry, just throttle back more and they'll kick in again without worry. The yaw control on the plane is more than enough to counteract flameouts. - At 28km toggle AG1 to kill the Turbojets and increase throttle to max. Toggle AG4 to start the 42-7S engines and pitch up to 40 degrees. The RAPIER will continue to operate on air breathing cycle until about 35km - At 35km toggle AG3 to close all air ducts and continue full throttle until Apoapsis is at 75km then prepare to circularize. - To circularize I recommend toggling AG4 to kill the 42-7S engines as they have slightly worse ISP than the RAPIER and are really not needed for the circularization burn, the average burn on the RAPIER alone is about 55 seconds. For re-entry: While not necessary, I recommend shifting fuel back into the forward tanks. The craft is more than capable of re-entry without the shift, but it will fly and land more smoothly if the shift is made. - Shift fuel (optional) - Open Air ducts with AG3 - Turn on Turbjets with AG1 - Switch RAPIER back to air breathing with AG5 - Glide smoothly back to the surface using engines if necessary. The plan glides incredibly well coming back to KSP and can make a fully unpowered landing without great effort.

The best mission I ever undertook was directed by the great Death Engineering: Duna Apollo Style A massive Saturn V style rocket, launching an equally massive payload to Duna and back. I had to take a break from KSP for a bit after that mission. It took a lot out of me The Payload: The full album/mission report.

Hey guys, I actually developed a fix that worked flawlessly. I added two RTG's to the mix, and also added 4 SAS units. one ILRW up front, one ASAS unit in the middle at the main docking port, and two ILRW's at the tail bases. This seems to have completely fixed my problems on re-entry as the plane is completely stable and controllable now. I can even keep it at 25km with the engines going 1500m/s for the inevitable undershooting the runway (which I did on my test run) Once the fuel runs out of her, she touches down on the runway really gentle

Hey Guys, here's my plane

Yes, that is very similar to what I had imagined. That's about the only way I can think that you could do this and still have the descent stage remain intact upon decoupling, since multiple parts attached to multiple radial decouplers would break any struts that attach them all together.

I'll have to post some pictures once I have the opportunity, but oddly enough, one of my plane designs looks eerily similar to Greywind's. My though, i'm sure, was very similar to his. That being, put your cargo in the back so when you drop it in orbit, your COM shifts back to balanced, even with the fuel shift. My plane still tumbles horribly even so... :'( The part that doesn't make a whole lot of sense to me is that I've got stabalization fins WAY back to the rear of the plane, but they don't seem to do anything. I'd have though they'd have more of a dart effect, but they do not...

One idea: On your ascent module: put a standard decoupler in the center on a hardpoint, radially attach to the hardpoint two descent/ascent engines. then on the decoupler just attach whatever your descent/lander stage would be. That way, when you decouple, you leave the decoupler behind, with all that is attached to it. The bottom of the design would look something like this: \ E / [==D==] / E \ Since you'd be attaching things to the side of the decoupler and nothing beneath it, it leave the engines free to fire on both the descent and the ascent. You could even set it up so that the descent stage had fuel tanks with fuel lines that fed into the ascent stage, so as per normal fuel consumption rules, the descent tanks would be used up first.

As for the dislike of my post, I understand, it gives the precise values... But in fairness, you're asking how to "eyeball the transfer windows" which without knowing roughly where the ideal window is, isn't going to happen. The sense will not come out of just looking at the picture, because each planet moves at different speeds and orbits, so comparing one launch vector to another just doesn't work. So again, I say that unless you want to do the full maths (as i agve in the latter half of my post) then simply knowing roughly the phase angles of each planet's prime transfer windows will let you eyeball it. You don't HAVE to print it out, if you still want the guess work of "I guess Duna looks like it's 45 degrees ahead of Kerbin...."

Hello All, As is the case with so many of our Kerbal sisters and brethren, I can build rockets for days. Impressive Whackjobian behemoths that can conquer the intire Kerbol system to little probe jumpers to get to the moon and back with just enough fuel. Spaceplanes however... haunt me... I have reached a point where I can successfully fly a SSTO spaceplane to orbit and deorbit. That's where my trouble begins. My problem is, and it happens without fail, that when I come back into ATMO, my plane tumbles without any ability to regain control, powered or unpowered. I've still got electricity for days, so that's not the problem of my loss of control, and I'm coming into atmo straight on in my prograde (I've also tried edging it maybe 5 or so degrees above prograde to mimic what the Shuttle entry does) however without fail my ship just starts spinning wildly on all 3 axis with no ability to regain control. Please help give me some tips and clues on how to build a simple SSTO space plane that can re-enter atmo without crashing and burning. I've rained death and fire down upon the poor KSP airfield for too long.

Fromt the Cheat Sheet in the wiki, you will find this handy chart which displays all of the ideal Delta V requirements for interplanetary travel, coupled with the ideal phase angles to launch from. Print that sucker out on a piece of thin paper (the 100% recycled stuff works great!), set Kerbol as the center of your map view, and you can hold it up to the screen and eyeball to your hearts content. Note: this is only for Kerbin departures and returns. Between other planets... well you'll have to do some maths to figure that one out. But here is a lovely tutorial piece to figure out the other planets.

No that's about spot on, and was mentioned earlier in the thread. This challenge is different enough that it stands on its own. However it does feel like you could just take half the BSC Aeris 4 entries and tweak the parts slightly and resubmit them for this challenge...

Why exactly would you choose to land on a slope anyways? It's not the most difficult thing to find level ground on the moon, generally the center of the smaller craters will be (mostly) flat from what I've noticed in my many moon landings.