OhioBob

The equations used by that model can be found here (see Table 4): http://www.braeunig.us/space/atmmodel.htm#USSA1976 However, you must convert Kerbin geometric altitude (z) to Earth geopotential altitude (h) using the following equation: h = 7963.75·z / (6371 + 1.25·z) For example, if you want to know the pressure at 10 km on Kerbin, plug z = 10 into the above equation and you get h = 12.4755 km'. Now following the above link and plug h = 12.4755 into the equations in Table 4 to compute temperature, pressure and density. This method won't match Kerbin pressure exactly, but it will be very close. Kerbin air pressure is based on the US Standard Atmosphere, but the float curve method can't replicate the values exactly.

Thanks for summarizing, that's most helpful. I've purposely not read any other posts because I don't want to be influenced by anybody else's solution. We know that Kerbin's orbital velocity is (subscript p for "planet"), Vp = 9284.5x For an orbit as you describe, the speed at apoapsis is 7580.8 m/s, but this is inclined 45 degrees, so the spacecraft’s velocity at apogee must be (subscript s of “spacecraft”), Vs = 5360.4x + 5360.4y Therefore the velocity the spacecraft must achieve relative to Kerbin is, Vs/p = (5360.4x + 5360.4y) – 9284.5x = -3924.1x + 5360.4y The magnitude of which is, Vs/p = (-3924.12 + 5360.42)1/2 = 6643.2 m/s In this case, the relative velocity represents the hyperbolic excess velocity that the spacecraft must achieve, thus V∞ = Vs/p = 6643.2 m/s We know that V∞2 = Vbo2 – Vesc2 where Vbo is burnout velocity and Vesc is escape velocity. For a 90 km LKO, Vesc = 3199.5 m/s, therefore Vbo = (6643.22 + 3199.52)1/2 = 7373.5 m/s The Δv is simply Vbo less the initial orbital velocity, where Vorb = 2262.4 m/s. Therefore, Δv = Vbo – Vorb = 7373.5 – 2262.4 = 5111.1 m/s

I ran a bunch of tests up to about 5 km/s. In addition to making sure the heat shield covers the whole ship, we need to make sure we don't overload the heat shield with too much mass behind it. I tested a 2.5m heat shield loaded up with anywhere from 6 to 38 tonnes of mass behind it. With a small loading (below about 20t), aerocapture was easy, even at 5 km/s. At the highest loadings, aerocapture was still possible, but it was also likely I'd overheat and explode if I came in too deep. At 38t the safe entry corridor was very narrow. I wouldn't recommend it.

Ah, okay. Now I see what the question was. As Nathan explained, it's the first derivative, or slope. The 3rd field is slope in, and the 4th field is slope out. In your case, slope in and slope out are the same.

Is there something I can help with? I'm not sure I understand your problem, @jsimmons, but if you explain it to me I might be able to help.

I don't know what it's called, but I still do it that way even though I know its not the most efficient. Actually I do something of a hybrid between this method and a suicide burn. I'll inject myself into a decent orbit with the periapsis low over my intended landing site. Then as I approach periapsis, I select my final landing site, perform a burn to kill my horizontal velocity, then drop to the surface and kill what ever vertical velocity I gained on the way down just before landing. I find that this gives me more control over my landing site and makes the landing much less white knuckled. It's less efficient than the other methods, but still not too bad if your vertical drop isn't too outrageous. For example, on Mun if you drop from a dead stop at 20 km, you'll gain about 240 m/s during the fall. However, if you drop from 2 km you'll gain only about 80 m/s. The lower you make your periapsis, the more efficient, but the descent to the surface will happen more quickly and with greater stress. When dropped from the same height, impact velocity on Minmus is about half what it is on Mun.

I just performed several experiments and here is what I've found. When Kopernicus and Realistic Atmospheres are both installed, the atmospheres of the stock planets (Eve, Kerbin, Duna, Jool and Laythe) will be as defined in Realistic Atmospheres. This is true even if Kopernicus attempts to make atmosphere changes; that is, Realistic Atmospheres will overwrite Kopernicus. It appears that all other changes made by Kopernicus are unaffected by having Realistic Atmospheres installed. If you want to have Kopernicus make changes to one of the stock planets while having Realistic Atmospheres modify the others, what you can do is this: edit the RealisticAtmospheres.cfg file to completely remove the configuration data for the planet that you want Kopernicus to modify. Realistic Atmospheres will ignore any bodies not listed in the configuration file.

Yes, it appears so. I'm not a FAR user, but I did temporarily install it just to test the compatibility of the two mods. From what I could tell, they worked together without any problems. If you discover otherwise, please let me know.

The mod is now available... http://forum.kerbalspaceprogram.com/index.php?/topic/128858-105-realistic-atmospheres/

Realistic Atmospheres Version 1.3.2 Realistic Atmospheres modifies the atmospheres of all planets and moons to conform to a more lifelike model. Temperature-height profiles are based on real life celestial bodies of similar type. Pressure-height models have been developed consistent with each celestial body's physical characteristics, and using real life gas laws. Models have been developed at real scale, and then scaled down to better fit the smaller size of the KSP universe. While some properties of the original atmospheres have been preserved, Realistic Atmosphere is a complete makeover. Don’t expect what you know about the stock game to exist in Realistic Atmospheres. You may encounter a planet's atmosphere much sooner or later than you are accustomed to, and with different behavior, so beware. Downloads Realistic Atmospheres, from GitHub Realistic Atmospheres, from CurseForge Installation Instructions Download the latest release of the mod Kopernicus. Install by copying/merging the GameData folder from the Kopernicus download to your KSP install Download Realistic Atmospheres v1.3.2 Install by copying/merging the GameData folder from the Realistic Atmospheres download to your KSP install. License This mod is licensed by Creative Commons Attribution-NonCommercial-NoDerivs CC BY-NC-ND

I recently performed a bunch of entry and aerocapture tests to study vehicle temperature and ablator loss. The tests were performed at Eve, Duna, and Jool. At Duna and Jool I found no overheating problems as long as entry occurred at normally expected velocities and entry angles. I suppose the peak temperature could exceed that of a heat shield if you came in at an excessive velocity or at a suicidal angle, but then I would expect the vehicle to overheat and be destroyed. I didn't find any behavior that I thought was out of balance. Eve was more of a challenge and was the only planet where I found that destructive overheating could be a likely problem. With a low ballistic coefficient I found little problem, though temperature could get up to 2500-3000 K. It was only with very high ballistic coefficients that that I had to be really careful. If I had a combination of high BC and high entry velocity, then things started to get iffy. Under those conditions the safe entry corridor gets pretty narrow, and may even close all together. You really have to think about what you're doing and design appropriately, but that's a good thing. We don't want to take the danger and difficulty completely out of the game.

To add to this, weight is actually a force and is measured in different units than mass. Mass is measured in kilograms (or metric tons) while weight is measured in Newtons (or kilonewtons). Newtons is also the unit used to measure thrust (another force). This is why thrust-to-weight ratio is dimensionless - the units cancel and we are left with a dimensionless ratio.

I think it's pretty arbitrary how one defines the pitch and yaw axes. For launch, I just redefine them so that, in my mind, the A-D keys control pitch and the W-S keys control yaw. I could also launch entirely by instruments if I wanted to, but staring at a NavBall is boring. I'd rather enjoy the animation.

The problem with this is that the rocket is pitching away from the camera view, causing the player to lose his visual cues as to the rocket's angle of tilt. It's much easier to eyeball it and quickly estimate the angle of tilt with a side view. With an eastward view I'd mostly lose this ability and would be forced to fly almost entirely by the NavBall. I wouldn't like this. Even though I do rely heavily on the NavBall, I prefer the visual of a side (northward) view. I think that most people's brain can make more sense of it that way. Also, to me, it is mostly irrelevant whether I'm pitching or yawing. When I'm looking at my rocket on the launch pad while facing north, I know I want to tilt to the right for an eastward launch. To do this I want to press the right control key. i.e. "D". It just seem very counter intuitive to me that you would want to press the top key, i.e. "W", to tilt right. This is why I suggest that players not rotate the pod/probe core. However, if it works for you, then it's not up to me to say you're doing wrong. Each player has to figure out for themselves what they prefer.

Just to add to the above.. If you are going to rotate the rocket in the VAB, disconnect the launcher from the payload, rotate the launcher 90 degrees, and then reattach to the payload. Don't rotate the pod or probe core because this will change the orientation of the pitch and yaw axes on the launch pad. For example, suppose you rotate the pod 90o clockwise in the VAB. Now to perform an eastward gravity turn you have to pitch down using the W key rather than yaw right using the D key, as is customary. There is nothing wrong with this per se, but it can be disorienting if you're not familiar with it. Also note that the default line of sight in the VAB is different than on the launch pad. When you are in the VAB and looking out the door toward the launch pad, you are looking east. When you click the launch button and move your rocket out to the launch pad, the default line of sight is now looking north. So if you want your SRBs on the north and south sides of the rocket, they need to be on the left and right sides of the rocket when in the VAB and looking out toward the launch pad. This is a quarter-turn different then the way they will appear on the launch pad.

I haven't blown anything up.

I suppose the ideal time to switch to the Terrier is when it's ISP exceeds the ISP of the engines on your earlier stages. The altitude on Eve at which the Terrier and Vector have the same ISP is about 27.4 km. And the altitude at which the Terrier and Aerospike have the same ISP is about 36.8 km. Below is a graph that compares the performances.

I haven't launched from Eve since version 0.90, but, from what I've heard, I believe the new number is somewhere around 7000-8000 m/s. Engine selection is very important now because ISP drops significantly at atmospheric pressures above 1 atm (pre-1.0, ISP never dropped below its sea level value). The best engines for use at low altitudes on Eve are the Aerospike and the Vector.

You can try editing your persistent.sfs file. For my "normal" game the settings are: CAREER { TechTreeUrl = GameData/Squad/Resources/TechTree.cfg StartingFunds = 25000 StartingScience = 0 StartingReputation = 0 FundsGainMultiplier = 1 RepGainMultiplier = 1 ScienceGainMultiplier = 1 FundsLossMultiplier = 1 RepLossMultiplier = 1 RepLossDeclined = 1 } There are a bunch of others settings as well, but I don't know what it all means. Surely there is somewhere in there where you can change the cost to level up facilities, perhaps you can find it.

Perhaps, but the original question was "can anyone explain why?" To that I think a factually correct answer should be given. Perhaps the initial poster doesn't really care about the details, but if he does, then implying that it's the atmosphere that has changed is not factually correct.

Yes, the costs that I listed are for a "normal" game. Those costs are probably factored up at greater difficulties. I really like upgrading the Astronaut Complex first for several reasons. First, it's a cheap upgrade. Second, it allows EVAs (the only EVAs allowed prior to the upgrade are on the surface of Kerbin). EVAs are by biome for "surface", "flying low", and "in space low," which gives ample opportunities to collect science. And third, the upgrade to 12 kerbonauts makes it possible to conduct a large number of "rescue" contracts, allowing expansion of the kerobonaut corps while collecting all-important funds. We can also perform "plant flag" contracts. All things considered, I think the Astronaut Complex gives the biggest bang for the buck as a first building upgrade.

I like the following order: 1) Astronaut complex (75,000 funds) - Allows EVAs (i.e. more science), up to 12 kerbonauts, and flag planting. 2) Tracking Station (150,000) - Enables patched conics. 3) Mission Control (75,000) - Enables maneuver nodes (with Tracking Station upgrade); allows up to 12 contracts. 4) Launch Pad (75,000) - Allows taller and heavier vessels (I do this before VAB only because it's cheaper). 5) Vehicle Assembly building (150,000) - Allows 225-part vessels and enables basic action groups. 6) Research and Development (451,000) - 500 research limit, surface samples, resource transfer. I don't bother with the Runway or SPH because I don't do planes. For the second round of upgrades, I usually don't follow any particular order.

This is a common misconception. Although the atmospheric model did change with the introduction of 1.0, the density of the old atmosphere was only slightly greater than it is now. The main reason that drag was so much higher in the pre-1.0 days was because KSP used a place-holder formula to compute the cross-sectional area of a rocket that was wildly unrealistic. Area was a function of mass, so the shape of a rocket was irrelevant. The place-holder formula turned everything into a flying pancake, with a drag area far greater than it actually had, resulting in a huge drag force.

KSP doesn't figure ISP correctly. In the game, ISP follows a curve that is defined in engine configuration files. In real life it is a simple straight line function. If the ISP drops 20s from vacuum to 1atm, it should drop another 20s for each additional 1atm pressure. This is one of the few places where real life is easier than the game.