OhioBob

I'm glad to hear it's not our mod. I was going to suggest that there had to be a problem someplace else because the behavior you were describing certainly didn't sound like anything that could be caused by the atmospheric model. Gael's atmosphere is very similar to Kerbin's because both are based off models of Earth. Stock Kerbin is based off the U.S. Standard Atmosphere, while Gael is based off a set of referenced atmospheres developed by the U.S. Air Force. The Gael model is the same one used for Kerbin in the mod Realistic Atmospheres. While playing the game, I doubt you'll notice much of a difference between stock Kerbin and the modified atmosphere. That looks awesome. Very well done.

Some of us like math.

GPP use to use 9.81 m/s2, but that was changed recently (v1.2, I think). Now it uses 9.80665 m/s2. Almost certainly Kopernicus pulls the value from GPP. That's correct. I find that once the rocket pitches over, it holds pretty closely to whatever the LAN is at that point through the rest of the launch. But while ascending vertically we move that extra degree so that we're at a LAN of about 90 degrees at pitch over. At least that's the way it works for me.

That's likely to change with the next GPP update. We've changed Gael's initial rotation so that the clock hits a time of 0:00 when it is local midnight at the KSC site. We've also tweaked the length of Gael's year to be exactly 426 days. This assures that sunrise and sunset occurs at precisely the same time every day (about 1:30 and 4:30 respectively at KSC). Your method is probably sound, but you're going to have to re-compute the launch times with the next update. Below are the methods that I described for getting to Iota and Ceti. I was basing the launch time for Ceti off the longitude of ascending node. My method doesn't require any math, but it does require a plugin (such as KER) to provide a LAN indicator. Your method doesn't require any plugins, but it does require some math.

You can't blame me for that one. I didn't make any heightmap changes to bodies with oceans for the specific reason that I didn't want to mess up any shoreline locations. I haven't touched Gael.

I agree with showing a range, but I think you should do that only for Iota, Ceti, and the planets. The Δv for going from an elliptical orbit around a planet to an intercept with a moon is really a bunch of BS. It's impossible to compute the Δv required to reach a moon without knowing the initial orbit around the planet, and that initial orbit can be darn near anything. For the Δv map I had to assume something or else it would have been impossible to compute a number to put on the map. I assumed the initial planetary orbit had an inclination of zero (i.e. equatorial orbit), but in practice that is almost certainly not going to be the case. The number on the Δv map is just there to fill in a spot, but it is only valid for a very specific set of circumstances. The actual Δv will vary wildly with almost infinite possibilities.

I've done only minimal testing with it, but below are the settings that we're using for GPP. The other suggestions you've received might work just as well, or maybe even better. Just try them out an see what you like best. Resize = 3.2 Rescale = 3.2 Atmosphere = 1.12 atmoTopLayer = 1.25 atmoVisualEffect = 1.12 Resize = 6.4 Rescale = 6.4 Atmosphere = 1.2 atmoTopLayer = 1.333333333 atmoVisualEffect = 1.2 Resize = 10 Rescale = 10 Atmosphere = 1.25 atmoTopLayer = 1.44 atmoVisualEffect = 1.25 These changes result in the overall atmosphere height being changed by factors of 1.4, 1.6 and 1.8 respectively.

I wasn't talking about Kerbin-Mun, I was talking about GPP. In the stock game, Mun is too close to Kerbin. If two bodies that size were that close to each other in real life, both bodies would be tidally locked to the other. The fact that Kerbin is not tidally locked makes it an unrealistic system. There are other things in the stock system that are also unrealistic. I tried to avoid as many of those things as possible in GPP, though there are still a few unrealistic things that got into GPP for visual effect or storytelling purposes (like Nero's rapid precession). For the most part, the distance between planets and their moons in GPP were computed by taking into account tidal forces, conservation of angular momentum, and about 4.5 billion years.

Everything in the versions we released are proportionally correct. The stock-sized version is a 1/10th scale model of a realistic life-sized solar system. When you use rescale and resize factors that are different from each other, that is going to mess with those proportions. The realistic proportions are preserved only when rescale = resized. Correct about Gratian. Only Gael and Tellumo have abundant oxygen in their atmospheres.

As I recall, the dial hand just keeps rotating past zero. Of course the gauge doesn't show negative numbers, so it was either pointing to nothing, or it was reading nonsense.

Yep, all the planets in a solar system have their axes pointing in the exact same direction, normal to the reference plane. RSS was able to produce Earth's axial tilt by inclining it's orbit 23.44 degrees. That worked for Earth, but all the other planets have their axes pointed the same direction. I hope that when Squad does implement axial tilt, they do it right. We just can't just specify the amount of tilt, we have to be able to specific the direction. One way to do it would be to specific the ecliptic latitude and longitude toward which the north pole points.

I developed this problem today with one of my three KSP installations. My Stock and Development installations are unaffected, but the problem occurred in my GPP installation. After trying several possible fixes, and failing each time, I just deleted it and started over with a fresh installation. For me that wasn't too bad because I only had about 20 mods installed. After getting everything reinstalled, it's working correctly again. I just hope the problem doesn't reoccur. I didn't take a screenshot of that, but I did take one of this...

The curves are pretty straightforward, but I still have a hard time remembering which curve does what. I frequently have to return to the tutorial for a refresher. One of my main objectives in writing this tutorial was just to explain what the curves do, which is something that I believe is largely misunderstood. I agree that ending the atmosphere is the part I probably overcomplicated. I just haven't been able to devised any other computational method that I'm happy with. And even the method I propose is far from perfect. The most important thing is to just get an atmosphere that feels right when playing the game. As I mentioned early, the math to compute the pressure curve is simplified quite a bit when the temperature curve is made up of a series of connected line segments rather than a continuous curve. I'm still strongly considering revising my techniques accordingly to produce something that would be easier for mod developers to understand and use.

Each row of blue cells forms is a single equation. The values in columns K, M, O and Q are the coefficients for the t3, t2, t1 and t0 terms respectively. The range over which each equation is valid is given by the values in columns F and H. So the first equation, p(t) = 1.630154519E-11 * t3 - 1.805200667E-07 * t2 - 1.029338000E-02 * t + 4.200000000E+2 is valid over the range of t = 0 to 15000. The variables t and p can mean anything, there are just the input and output variables. p(t) just means that p is a function of t. When you have a float curve, each key has four numbers. The first is the t value, and the second is the p value. When you have a temperature curve, t is altitude and p is the temperature. If you are writing a temperature formula to enter into cell D5 of AtmoModel.xlsx, the equation would look like the following. However, the variables shown in red italics get there values from FloatCurve.xlsx. Here you wouldn't type the variable name, but rather its numerical value. For instance, you wouldn't type "H4", you would type the numerical value that is in cell H4 of FloatCurve.xlsx, i.e. 15000. =IF(B5<H4,K4*B5^3+M4*B5^2+O4*B5+Q4,IF(B5<H5,K5*B5^3+M5*B5^2+O5*B5+Q5,IF(B5<H6,K6*B5^3+M6*B5^2+O6*B5+Q6,IF(B5<H7,K7*B5^3+M7*B5^2+O7*B5+Q7,K8*B5^3+M8*B5^2+O8*B5+Q8) The above tells you were the numbers come from, but the actual formula that you enter into cell D5 of AtmoModel.xlsx would be: =IF(B5<15000,1.630154519E-11*B5^3-1.805200667E-07*B5^2-1.029338E-02*B5+4.2E+02,IF(B5<50000,8.235483382E-13*B5^3-1.307540583E-08*B5^2-4.869071953E-03*B5+3.5319857E+02,IF(B5<60000,-2E-11*B5^3+3.3E-06*B5^2-1.8E-01*B5+3.43E+03,IF(B5<70000,6E-11*B5^3-1.17E-05*B5^2+7.56E-01*B5-1.601E+4,-7.7635275E-12*B5^3+2.010611325E-6*B5^2-1.673617313E-01*B5+4.686215628E+03) Of course the values above are from the sample that comes with FloatCurve.xlsx. Obviously you'd use that values from your actual temperature curve. You may also have to increase or decrease the number of IF() statements depending on how many keys are in your temperature curve.

Yep, its proximity to Ciro along with the fact that Thalia just isn't very big. Have you checked out Icarus' SOI? It makes Thalia SOI look enormous.

It's a big deal if you have a craft in orbit around Eta. Eta will continue to orbit Thalia even if it moves outside the SOI, but as soon as it moves outside the SOI, any craft that you have orbiting Eta will drift away into a solar orbit. We actually had this situation with the original design. I hadn't been thorough enough with my math to notice that Eta's apoapsis was beyond the Thalia's SOI. I ended up having to decrease Eta's semimajor axis and eccentricity to keep it inside Thalia's SOI.

True, but I don't want to have to do that. I want the option to place the datum at a median elevation. What I've done in the past, and what I suspect most developers do, is set the lowest point on the planet equal to an elevation of 0 (or at least close to it). What I don't like about this is going to the Tracking Station and seeing the planet's atmospheric pressure and temperature given for "sea level", i.e. the datum. What we are really seeing is the pressure and temperature for the lowest point on the planet, which is not at all representative of the conditions across the vast majority of the planet's surface. There may be no more than one tiny spot on the entire planet (or maybe no spot if the whole surface is >0) where those conditions actually exist. I would prefer to set the datum at an elevation were roughly half the surface area is below, and half is above. That way the "sea level" atmospheric conditions actually represents median conditions on the surface, with some areas greater and some less. That just makes more sense to me, plus it's the way it is in real life.

@Thomas P. and @Sigma88, you guys are the main Kopernicus developers. What do you think? Is this altimeter issue something that can fixed in Kopernicus? @cybutek, I've also observed that the "Altitude (Terrain)" readout in Kerbal Engineer Redux does the same thing as the stock radar altimeter. What's your opinion on this issue?

I've heard that axial tilt is coming in a future update, but at present it is still not implemented. You probably saw a parameter for it in RSS, but it is commented out and not working. This from the Earth config: // does nothing - axialTilt = 23.44

As I understand it, Transfer Window Planner should work with the rescaled/resized system. So, yes, that will give you the interplanetary transfer delta-v. Transfers within a body's SOI will stay the same, or change, depending on how you want to think about. For instance, it takes about 905 m/s to get from LGO to Iota, where Iota's orbit is 28,000 km. In your modified system, it will still take 905 m/s to go from LGO to 28,000 km, however, Iota's orbit is no longer 28,000 km. If you factor everything by, say, 3.2x, then Iota's orbit is now 89,600 km, therefore it will take more delta-v to get there. So transferring from one orbit altitude to another orbit altitude within a body's SOI stays the same as 1x size. But transferring from one body to another body within the same SOI will increase because the distance between the bodies has increased.

I don't use life support mods either. However, I'd still be worried about the time warp factor. With just a 3.2x rescale factor, all the orbital periods and transfer times get increased by about 5.7 times. That's a lot of just sitting around and waiting. I think it could make the game agonizingly slow to play.

I think that's the case for the whole process. There is nothing about it that is particularly difficult in terms of the mathematics, I mean we're not deriving general relativity here, but there is definitely a lot to learn. And no matter how well you learn it, it is still a time-consuming process with a lot of steps (that part never gets easier).

You have to be a little careful there because you could get some unintended consequences. For instance, if you scaled up the orbital radii without making any change to the Ciro, all the planets' orbital periods are increased by (rescale)^1.5. This would produce very long transfer times and wait times between transfer windows. Even if you don't resize the planets, I think you would have to modify Ciro to make the game playable. You could either resize Ciro or just increase it's gravity. For Ciro only, I would recommend doing one of the following: (1) resize = rescale, or (2) geeASLmultiplier = rescale^2. If you don't change the size of the bodies, then getting to orbit and transferring from orbit to orbit within a body's sphere of influence would be the same as 1x stock sized. However, if you increase Ciro's size or gravity, then the delta-v for interplanetary transfers would increase. However, the amount of increase is probably not very predictable. The delta-v needed for an interplanetary transfer is in part the amount needed to escape the planet, and in part the amount needed to modify the solar orbit to intercept the target planet. The first part is a function of the planet's resize factor, and the second part is a function of Ciro's gravity and the rescale factor. When you start mixing and matching factors as you suggest, then all the currently available delta-v data gets tossed aside. You'd have to reinvent it from scratch.

I’ve discovered a flaw in KSP that requires a fix. I hesitate to call it a bug because I think it is working as designed, but the design needs to change. When a world is created using VertexHeightMap, it is possible to define a negative offset to lower a portion of the terrain below the datum. This is done typically when a body has oceans. When oceans are present, the datum becomes sea level and all land at negative elevations is under water. However, it is also possible to define a negative offset when there are no oceans. A mod developer might choose to do this if he wants to place the datum at an elevation that is somewhere between the body’s minimum and maximum elevations. This is the method typically used in real life, where a body’s datum is placed somewhere close to the mean surface elevation. This creates a problem in KSP, however. The normal altimeter reads altitude in relation to the datum, as it should. When above the datum it reads positive (black numbers), and when below the datum it reads negative (red numbers). When we switch to IVA view, however, the radar altimeter is supposed to read height above the ground. The radar altimeter does so when the ground elevation is positive, but when the ground elevation is negative, the altimeter reads the height above the datum. The altimeter behaves as if it is coded to interpret any ground below the datum to be under water, therefore it reads altitude above an imagined “sea level”. This should be changed. The radar altimeter should perform a check to see if oceans are present or not. If oceans are present, then the altimeter’s current mode of operation is correct. However, if there are no oceans, then the radar altimeter should read the height above the ground below it, even if that ground lies at a negative elevation.

Each set of numbers in the temperature curve is connected to the next with a "spline". The first line of blue cells contains the formula for the spline that connects to first two keys of the temperature curve. t is the input variable and p is the output variable (those variables come from the web page that I linked to, I could have just as easily used x and y). For a temperature curve, t = altitude, and p = temperature. Let's say we want to take the first formula in FloatCurve and write a temperature formula in cell D5 of AtmoModel. This formula would be, =1.630154549E-11*B5^3-1.805200667E-07*B5^2-1.029338E-02*B5+4.2E+02 where cell B5 contains the altitude. What complicates things is that each spline of the temperature curve has a different formula. The first formula (the one we just wrote) is the one that connects the first two keys of the temperature curve; therefore, it is valid only for the range of altitudes from 0 to 15000 meters. For the next range of altitude, 15000-50000 meters, we need to use the formula contained in the second line of blue cells. We have to use an IF() statement to define when each formula is used. If we have only two formulas, then we can amend the formula in cell D5 to read, =IF(B5<15000,1.630154549E-11*B5^3-1.805200667E-07*B5^2-1.029338E-02*B5+4.2E+02,8.235483382E-13*B5^3-1.307540583E-08*B5^2-4.869071953E-03*B5+3.5319857E+02) Here the first formula is used when B5<15000, and second is used when B5=>15000. When we require additional formulas, we have to start nesting multiple IF() statements together. For example, =IF(B5<15000,...,IF(B5<50000,...,IF(B5<60000,...,IF(B5<70000,...,...)))) Unfortunately Excel allows no more than seven IF() statements to be nested together. If we require more than that, then we have to add groups of nested IF() statements together. For example, the previous statement can also be written as follows: =IF(B5<15000,...,IF(B5<50000,...,IF(B5<60000,...,0)))+IF(B5<60000,0,IF(B5<70000,...,...)) In this case, if B5<60000, the first group of IF's returns a computed value while the second group returns 0. But if B5=>60000, the first group of IF's returns 0 while the second group returns a computed value. Note that the last formula is provided only to show how groups of nested IF() statement can be added together. It is not necessary to do so in this particular example because we do not exceed the nested IF() limitation. The limitation of seven IF() statements applies only when they are nested one inside of the other. I know of no limitation when adding IF() statements together. There is nothing here that is especially difficult as far as the math is concerned (we're just using simple polynomials), but making sure the formulas are written correctly can be a chore. The strings can get rather long and confusing.