OhioBob

Sorry for taking so long to respond, I just now saw your post. The equation that I use is the very first one under the heading Unit interval (0, 1). It is a pain in the neck to work with, so it's no surprise that you're struggling. As you can see from the article, the equations works over the interval of t=0 to t=1. The means the that for each interval, the altitude must be normalized to a number between 0 and 1. This can probably best be explained with an example. Let's take Duna and use the interval between the second and third keys, i.e. the altitude range 12000-20000 m. Here we have, po = 1.276 p1 = 0.241 The variable t represents the altitude, but we can't enter the altitude directly. It must be entered as a number between 0 and 1. Therefore, if we want the pressure at 12000 m, we enter t=0. For the pressure at 20000 m, we enter t=1. For the pressure at 15000 m, we enter t = (15000-12000)/(20000-12000) = 0.375 Because the value of t ranges from 0-1 instead of 12000-20000, we must change the slope accordingly. The in and out slopes are, mo = -0.000223*(20000-12000) = -1.784 m1 = -4.22E-05*(20000-12000) = -0.3376 We now plug these numbers into the equation and we should get our answer.

The stock Kerbin atmosphere and my modded atmosphere are both based on models of Earth, so they are very similar. For most practical purposes the two atmospheres should perform the same**, so the 23 km periapsis altitude ought to work in both stock and Realistic Atmospheres. As far as real-life is concerned, I haven't performed the same amount of investigation, so I can't say. Perhaps there is some handy-dandy perigee altitude that will work in most cases, but if there is, I haven't discovered it. ** If you were to compare the two atmospheres side by side, you would undoubtedly see some small differences in the numbers, but nothing of consequence. Of course that's true of Kerbin only; the differences between stock and RA for the other planets is significant.

Generally speaking, the greater the entry angle (i.e. the lower the periapsis), the higher the peak temperature but the lower the amount of ablator used.

Just note that the equations previously given use Vo rather than orbit altitude. If you input altitude, the value of Vo is calculated using the following: Vo = SQRT( 3.986004418E+14 / (z + 6371000) ) where z = altitude. Note that the above equation is for Earth in RSS. If anybody wants to use these equations to compute launch azimuth for stock KSC, then use the following: L = -0.096944o Veq = 174.94 m/s Vo = SQRT( 3.5316+12 / (z + 600000) )

I use direct entry at Kerbin all the time. I've never found a need to mess around with aerocapture or any other means to slow down. Just come straight on in. I'm always more concerned about where I'll land rather than whether or not I'll burn up (don't want to come down on a steep mountain side). I ran a bunch of simulations and I found that, for a Mk1-2 command pod, a periapsis altitude of about 23,000 m was a good general purpose number. The g-load is survivable and neither the peak temperature nor the total heat load are excessive. Furthermore, a periapsis of 23,000 m works over a very wide range of entry velocities, anywhere from a LKO reentry to 5000+ m/s. If you are ever uncertain, just pick 23 km and you'll probably be safe (unless you didn't provide enough ablator). Of course this altitude will likely change for vehicles with different ballistic coefficients.

Depends on which installation, but currently about 20.

It would be pretty easy to put the formulae into a spreadsheet so that all you have is a couple input variables. Provided you're using only one launch site, you could input orbit altitude and inclination and it would spit out the launch azimuth.

To attain a particular orbit inclination from a particular launch site, what we want is a method to compute the required launch azimuth. For instance, if we are launching from a latitude of 28.6o and we want to insert into an orbit with an inclination of 33o, then in what direction do we want to fly when coming off the launch pad? The equations used to compute this are, β = βI – γ where, sin βI = cos i / cos L tan γ = (Veq cos L cos βI) / (Vo – Veq cos i) β is the launch azimuth (measured clockwise from north), i is the orbit inclination, L is the launch site latitude, Veq is the velocity of the planet’s rotation at the equator, Vo is the velocity of the space vehicle immediately after launch, βI is the inertial launch azimuth, and γ is a small correction to account for the velocity contribution due to the rotation of the planet. When using RSS, Veq = 464.58 m/s and, for the Florida launch site, L = 28.608333o. For example, let's say i = 33o and Vo = 7810 m/s. Therefore, we have βI = arcsin[ cos(33) / cos(28.608333) ] = 72.80418o γ = atan[ (464.58*cos(28.608333)*cos(72.80418)) / (7810–464.58*cos(33)) ] = 0.93096o β = 72.80418 – 0.93096 = 71.87322o Note that we can't insert into an orbit that has an inclination lower than the latitude of the launch site. For instance, we can't insert into an orbit with an inclination of 20o from the Cape Canaveral. If a lower inclination is required, a plane change must be executed after orbit insertion. Also note that if we are trying to match the orbit of a particular target, we must not only match the inclination of the target, but also its longitude of ascending node. This means that we must carefully time the launch so that we end up in the correct plane.

I use to use standardized boosters, but I've gone away from that. Now I usually custom build for each payload. However, I use a standardized design method. This means I can build them quickly and they all end up performing similarly.

Eve Optimized Engines, version 1.0.4 I just recently noticed that between KSP version 1.0.5 and 1.1.0, Squad swapped the positions of the Swivel and Reliant engines in the tech tree. To match this change, I've swapped the positions of the Abel and Adam engines in the tech tree.

Although I use several mods, the three that I find most indispensable are, Kerbal Engineer Redux Kerbal Alarm Clock Precise Node

Fundamentals of Astrodynamics Roger R. Bate, Donald D. Mueller, Jerry E. White © 1971, Dover Publications, Inc. ISBN 0-486-60061-0 Only $16.29 US for new on Amazon.com.

If real high accuracy isn't needed, then what you suggest will work. However, if we want an equation to give pressure as a function of altitude, it is be best to plot LN(pressure) vs. altitude. This will give a relatively straight distribution of points through which it is easy to plot a good trendline and obtain an equation. Therefore, to get the pressure we would plug altitude into the equation to obtain LN(pressure), and then we take EXP() of that value to get the pressure.

rho = ρ

There is a display is stock KSP that gives dynamic pressure along with a bunch of other aerodynamic data (no mod required). Just do the following: Press ALT+F12 to open Debug Toolbar Click "Physics" button Check "Display Aero Data GUI" Press ALT+F12 to close Debug Toolbar

It might help to supplement Geschosskopf's explanation with some pictures.

In real life we would put a transponder on the spacecraft track it via radar. After taking several position and distance measurements, the spacecraft's movement in 3-dimensional space versus time in known. From this the orbit can be derived.

I get the same as you for the 0-1200 m range, but I get slightly different numbers for the 1300-2000 m range. I think one of us has probably made a typo somewhere. I've double and triple checked my numbers and I don't see an error on my end. Here are my numbers: 1300 83.271 1400 81.999 1500 80.742 1600 79.501 1700 78.276 1800 77.066 1900 75.871 2000 74.692 The fact that Kerbin's sea level pressure is 101.325 kPa is obviously no coincidence. Kerbin's atmosphere is based on the U.S. Standard Atmosphere of Earth. However, the height of that model was more than was wanted in the game, so it was squashed down to 80% its original height. Therefore, for example, the pressure found at an altitude of 10 km on Earth is found at an altitude of 8 km on Kerbin.

There is actually a contract in the game for placing a spacecraft on a solar escape trajectory.

If the current velocity and radius are known, and the gravitational parameter of the primary body is known, then the semimajor axis can be computed using the vis-viva equation. No need to complete half an orbit.

That equation no longer works in KSP. Back in the beta version the scale height, H, was a constant for each planet. However, starting with v1.0 the atmospheres were changed to a more complex and realistic model. Since H now varies, you can no longer use a simple equation. Pressure is now computed using a float curve. Each float curve is made up of a series cubic Hermite splines. At the bottom of this post you will find the pressure curve data from each atmosphere. Each set of four numbers are (1) altitude in meters, (2) pressure in kPa, (3) slope in, and (4) slope out. If you really want to know the math, then study the links provided in this paragraph. I've already figured all this out and created an Excel spreadsheet in which we can plug in the curve data and it converts everything to simple polynomials. For me, I find this much easier to use. We can just use the polynomial equations to compute the pressure at any given altitude. Below is a link to my spreadsheet: http://www.braeunig.us/KSP/FloatCurve.xlsx Enter into the gray fields the curve data as listed below. Given In the blue fields are the polynomial equations and the range over which each equation is applicable. (The default example is the base temperature curve for Kerbin.) Eve atmospherePressureCurve { key = 0 506.625 -0.08693577 -0.08693577 key = 9723.525 113.4918 -0.0149408 -0.0149408 key = 20000 29.0968 -0.003046887 -0.003046887 key = 45000 0.82 -6.321458E-05 -6.321458E-05 key = 80000 0.0035 -9.886503E-07 -9.886503E-07 key = 90000 0 0 0 } Kerbin atmospherePressureCurve { key = 0 101.325 0 -0.01501631 key = 1241.025 84.02916 -0.01289846 -0.01289826 key = 2439.593 69.68138 -0.01107876 -0.01107859 key = 3597.11 57.78001 -0.009515483 -0.009515338 key = 4714.942 47.90862 -0.00817254 -0.008172415 key = 5794.409 39.72148 -0.00701892 -0.007018813 key = 6836.791 32.93169 -0.006027969 -0.006027877 key = 7843.328 27.30109 -0.005176778 -0.0051767 key = 8815.22 22.63206 -0.004445662 -0.004445578 key = 10786.42 15.3684 -0.003016528 -0.00301646 key = 12101.4 11.87313 -0.002329273 -0.00232922 key = 13417.05 9.172798 -0.001798594 -0.001798554 key = 16678.47 4.842261 -0.0009448537 -0.0009448319 key = 21143.1 2.050097 -0.0003894095 -0.0003894005 key = 26977.92 0.6905929 -0.0001252565 -0.0001252534 key = 33593.82 0.2201734 -3.626878E-05 -3.626788E-05 key = 42081.87 0.05768469 -9.063159E-06 -9.062975E-06 key = 49312.13 0.01753794 -3.029397E-06 -3.029335E-06 key = 56669.95 0.004591824 -8.827175E-07 -8.826996E-07 key = 62300.84 0.001497072 -3.077091E-07 -3.077031E-07 key = 70000 0 0 0 } Duna atmospherePressureCurve { key = 0 6.755 0 -0.0007 key = 12000 1.276 -0.000223 -0.000223 key = 20000 0.241 -4.22E-05 -4.22E-05 key = 35000 0.015 -2.787075E-06 -2.787075E-06 key = 50000 0 0 0 } Jool atmospherePressureCurve { key = 0 1519.875 0 -0.05753474 key = 29000 628.0436 -0.01449255 -0.01449255 key = 123450 22.26 -0.001562163 -0.001562163 key = 150000 2 -0.0001361465 -0.0001361465 key = 170000 0.1 -1.001277E-05 -1.001277E-05 key = 200000 0 0 0 } Laythe atmospherePressureCurve { key = 0 60.795 0 -0.005216384 key = 5250 33.40898 -0.004252711 -0.004252711 key = 10000 17.78605 -0.002407767 -0.002407767 key = 17000 7.100577 -0.001092064 -0.001092064 key = 22000 3.812421 -0.0004677011 -0.0004677011 key = 31000 1.312482 -0.0001961767 -0.0001961767 key = 38000 0.5104055 -7.855808E-05 -7.855808E-05 key = 50000 0 0 0 }

Computing flight path angle is relatively easy. From the Pe and Ap distances you get semimajor axis and eccentricity, and from your current altitude you get the magnitude of your position vector. Having the values of a, e and r, you can compute the true anomaly, from which you compute the flight path angle. You can also get the orbital elements and the position vector of a vessel from the persistent.sfs file. Of course those would be the values at the time of the last autosave. If you want take a snapshot of the values at some particular time, you could probably do a quick save and then read the values from quicksave.sfs.

The orbital elements are what you use to compute the values you want.

I believe you can find all the orbital elements in the KSP Wiki. I was also able to find quite a bit of data using a mod called Hyperedit. Hyperedit allows you to change orbital data, so when to bring up the edit screen it displays many of the default settings.

If all else fails, what I would recommend doing is to not install RSSE, but rather merge the RSSE files into the SSRSS folders. That is, install SSRSS by itself and then do the following: Merge the contents of RSSExpansion into GameData/SSRSS/RSSKopernicus/ Merge the contents of RSSEx-Textures into GameData/RSS-Textures/