arkie87

The graph is supposed to show that (a) < ( when deltaV < ~600 m/s, such that this maneuver is not automatically the most efficient for all cases... I wasn't trying to claim that i discovered this maneuver; I was merely asking if there are practical cases where this maneuver isn't the most efficient? I also re-watched that Scott Manley video just in case, and he does not touch upon when this maneuver is not the most efficient.

So let's say you are in Kerbin's SOI around Minmus's apoapsis/periapsis, and you want to escape Kerbin's SOI. Do you: (a) Burn prograde (little Oberth effect) ( Burn retrograde to drop periapsis down to LKO, then burn prograde at periapsis at LKO (lot's of oberth effect) I've done some calculations, and plotted V_inf (velocity after escaping Kerbin's SOI) vs. total deltaV budget: It seems that for deltaV's less than ~600 m/s, option (a) is more efficient, whereas option ( becomes more efficient for higher deltaV's, so it seems that it might not always make sense to choose option ( i.e. Oberth. Now, realizing that all interplanetary transfers in the game would require more than this 600 m/s deltaV budget, I was wondering if there are any practical situations in KSP where choosing option (a) is more efficient?

I guess the answer boils down to the fact that there are two ways to gain altitude (1) by burning upwards (2) by going so fast horizontally that you get centripetal "lift". Since the latter approach involves burning pro-grade the entire time, it therefore utilizes the oberth effect more effectively.

So the results are in. For a Kerbin-like planet with mu = 3.532e12 m3/s2, R=600 km and A = 100 km: (a) Burning straight up requires 1297 m/s deltaV and circularizing requires 2246 m/s deltaV, thus totaling 3543 m/s. ( Burning sideways into orbit at sea level requires 2426 m/s deltaV, raising apoapsis to altitude A by burning at periapsis requires only 91.59 m/s deltaV, and then raising periapsis to altitude A by burning at apoapsis requires only 88.12 m/s deltaV, thus totaling 2606 m/s. The Equations used and solved in EES (Engineering Equation Solver): {!Constants & Givens} R=600e3 [m] A=100e3 [m] mu=3.532E+12 [m^3/s^2] {!Approach (a)} {Orbital Velocity at Altitude A} V_orb^2= mu/(R+A) {Launched Velocity Required to Reach Altitude A} 1/2*V_up^2 = - mu/(R+A) - (-mu/R) {Sum Total dV from Approach (a)} dV_total = V_up + V_orb {!Approach (} {Circular Orbit at Sea Level} dV[0] = V[0] V[0]^2 = mu/R {Thrust at Periapsis to Raise Apoapsis to Altitude A} V[1] = V[0] + dV[1] V[2]*(R+A) = V[1]*R 1/2*V[2]^2 - mu/(R+A) = 1/2*V[1]^2 - mu/R {Thrust at Apoapsis to Raise Periapsis to Altitude A} V[3] = V[2] + dV[2] V[3] = V_orb {Sum Total dV} dV_tot2 = dV[0]+dV[1]+dV[2]

I was wondering whether there is a difference in terms of deltaV between getting into circular orbit at altitude, A, above a perfectly spherical, atmosphere-less body by: (a) shooting straight up until apoapsis reaches altitude A, and then shooting straight sideways upon arriving at apoapsis with an instantaneous impulse burn ( blasting off and immediately turning straight sideways, until you end up in circular orbit at altitude A (angle will slowly decrease) I imagine they should be the same (assuming impulse burns). If they are the same, why is a "gravity turn" in atmosphere more optimal than say a burn straight up to altitude, A, and then a sideways burn into orbit (assuming sideways burn is an instantaneous impulse burn)?

Jebifer Kermin Bobbett Kermin Billyjean Kermin

So i think you've proved my point about SSTO's taking a while to get into orbit with shallow climb rates etc... That's why ive switched to solid boosters to blast off into space (with mach effects and re-entry heat on exiting atmosphere) so i dont have to spend so much time slow-climbing. Plus, solid boosters are quite cheap in terms of kerbucks:cool:

Cant tell if trolling or...

If you want to utilize air-breathing ISP as much as possible they do... unless im doing something wrong, getting as close as possible to orbital velocity requires climbing slowly so you dont starve the air-breathing engine of air and yeah, i suppose. but i meant space planes that are launched into space by one booster stage, the idea being to use cheap (in terms of kerbucks) booster rockets to quickly send spaceplanes into space without a slow climb

Does anyone else build Two-Stage-to-Orbit vehicles? I've done a lot of SSTO's, but i tend to get bored during the slow climbs and limited cargo capacity, so ive started to prefer building TSTO's where i just use cheap solid rockets to boost some kind of vehicle into space, drop them like they are hot, and then circularize orbit with the spaceplane stage. Spaceplane usually looks like so: http://imgur.com/aM5QdWs

That... and the fact that the first KSP screen says "Mun or Bust" The only reason Mun requires more deltaV is because its gravity well is deeper; otherwise, if Mun's and minmus's gravity wells were equal, minmus would require more deltaV. So perhaps, make minmus bigger/denser so that Mun is easier to get to since players will go for it first anyway (especially since earth doesnt have a second moon so new players wont suspect it even exists...)

I think OP suggested inclination should match Minmus' not the Mun's. Though what you said gave me an idea: that the Mun should be inclined and minmus should be equatorial (while Kerbin remains un-tilted); this way, it will be easier for new players to get to minmus (because it requires less deltaV and it's equatorial), but wouldnt make interplanetary missions more difficult by adding an axial tilt.

Default, the game should not let you time warp past a maneuver node. It should either stop a set amount of time before (1 min) or an amount of time equal to the "burn time"

Are you trying to add procedural wings to a craft that existed from before you installed procedural dynamics? Was the saved game created before you installed procedural dynamics? Try starting a new game and placing the procedural wings on a new craft and see if it crashes? I remember having issues when trying to place procedural wings on a pre-existing craft.

Thats a cool video. And yeah, i think we've all been there that we read something quickly, ended up misinterpreting it or reading it wrong, and then writing a long rant about it, be corrected immediately after by 5 people, then admit we are wrong, only to have people 100 pages later continue to correct us

OP does not talk about "going really fast", but rather accelerating at 1g....

Is is possible to change the craft that FAR/NEAR/stock lift/drag functions use i.e. do these functions always use the current craft or is the craft an input into the functions. If the former, than i doubt this can be implemented unless NEAR/FAR/Stock lift/drag functions are improved such that the input craft needs to be specified... The only possible workaround for now is to put some monopropollent and RCS thrusters to get some deltaV on your command pod... Alternatively, plan to enter atmosphere with the extra weight of your tank and motor and ditch it at the last second before deploying your parachute...

Thanks for prompt reply. Verlet algorithm is second order, so there is room for improvement, which could theoretically result in faster prediction updates for the same level of accuracy (though 4th Order Runge-Kutta is a pain to implement). What do you mean you are more concerned about correctness of aerodynamic force computations-- you think you are using these forces incorrectly (unsure if you implemented it right) or that accuracy of prediction is much better than ability of user/pilot to maintain required AoA anyway (so why bother improving accuracy/speed of prediction)?

Wow, this mod is amazing-- i hope squad absorbs it (and compensates you accordingly). What do you think about making the functionality slightly different to increase its number of features: (1) When nothing is targeted, everything functions as described except when targeting the landing location, the navball uses the blue maneuver node indicator to show where you should be pointing (rather than new indicators) i.e. always point towards blue indicator (not sure why two indicators are needed)... on second thought, you mentioned the second indicator was for direction only, rather than magnitude so perhaps, a better idea is to use the blue arrow (like the new navball in 0.25 uses to show where your maneuver node is on navball when its off screen) to show which direction corrections should be made. The magnitude of the correction could also make this arrow bigger or smaller (or darker/lighter). (2) When a target is set (on the surface only), the plugin backward calculates the orientation/AoA necessary to arrive there, and if no atmosphere is present, calculates the maneuver node necessary to arrive there (to me, it seems the backward calculation functionality is already there, since for option 1, the indicators on the navball will tell you how far from ideal you are). Also, out of curiosity, what integration scheme and order do you use in your calculations (4th Order Runge-Kutta?), and do you use the known variation of density with height to allow for very accurate results with large timesteps and few calculations (thus faster updates)?

oh my god how am i just finding this????

Maybe thinking of it like that will make me less angry (at myself) and more willing to try it again...

yeah. That definitely was the problem. But the question is why and can it be fixed. I ve never had problems deploying parachute even under 4x time acceleration when parachute was connected to only a small pod with no extra weight, until I installed deadly reentry...

You do this long mission, gather a bunch of science and data, return home, and then screw something up at the last minute and lose everything (i was playing on hard so quicksaving was disabled)???? Would this be fixed if deadly re-entry scaled its damage factors by the time-warp factor so that all critical g forces were multiplied by 4 under 4x time acceleration?

http://imgur.com/LAWGFb2