OhioBob

@MaxL_1023 covered the atmosphere stuff pretty well. The settings of Atmosphere = 1.25 and atmoTopLayer = 1.6 are probably about right for a 10x resize. For a 6.4x resize you might be able to go a little less, maybe Atmosphere = 1.2 and atmoTopLayer = 1.5 (or maybe even as low as 1.25). It's really just a matter of what feels right to you when you play the game. If during a high speed entry the transition between vacuum and atmosphere seems to occur too abruptly, then try increasing atmoTopLayer. On the other hand, if the atmosphere seems too extended, then decrease atmoTopLayer. The only real rule that I try to keep is to never go over 1.25 for the Atmosphere parameter.

I believe it disappears only if it passes below some minimum, but I don't recall if the minimum is an altitude or a pressure level. As long as its orbit is above the minimum, it will continue to orbit on rails even if inside an atmosphere. But as soon as it passes below the minimum, it disappears.

Yes, the drag would be exceedingly small, but not zero. Eventually it would still cause the orbit to decay. At least that's the real life case. I'm not sure how the game would handle it, perhaps there's some minimum value below which it just goes to zero. I don't know. In KSP, however, I would never recommend setting the atmosphere so high. The problem is that high speed time warp in disabled inside an atmosphere. It would make for a very slow game if you had to orbit while still inside an atmosphere. Also, when the station is not the active vehicle, it's on rails. So in that case it will orbit indefinitely without any drag effect. Drag is simulated only when it is the active vehicle.

For those of you playing upsized versions of GPP, please note that a new release of Sigma Dimensions is available. The new version includes a better way of resizing atmospheres.

Yes, I think settings of 1.14 and 1.17 should improve things - with those settings the transition from space to atmosphere should less abrupt than you got by setting Atmosphere = 1.33. Of course users can experiment with the settings until they find what ever makes them happy. There's no one right way to play KSP, if bizarre and unnatural is what you want, then by all means go for it. However, if you want to resize an atmosphere so that it behaves as realistically as possible, my recommendations are: If you are upsizing a celestial body, then for Resize = 1 to 10, you should set Atmosphere = 1 to 1.25, and atomTopLayer > 1. If you are downsizing a celestial body, then for Resize = 1 to 0.1, you should set Atmosphere = 1 to 0.8, and atomTopLayer < 1. How much greater than or less than 1 you make atmoTopLayer is entirely up to you. It should be based on what feels right to you in the game. For example, let's say you're resizing Kerbin to 10x its stock size. If you just want to soften the edge of the atmosphere a little bit so it doesn't seem quite so abrupt, then you might try Atmosphere = 1.25 and atmoTopLayer = 1.2, for a final height of 105 km. On the other hand, perhaps the goal is to force your spacecraft into higher more lifelike orbits, then you might try Atmosphere = 1.25 and atmoTopLayer = 2, for a final height of 175 km. In either case, the extended upper part of the atmosphere will have lifelike pressures and densities.

With a 3.2x system it might not be too bad just rescaling the atmosphere using the Atmosphere parameter. However the problem with doing that becomes more pronounced as the scale goes up. The issue is that velocities are much greater in a larger solar system. Escape velocity goes up as the square root of the resize factor, so for a 10x system the escape velocity is 10^0.5 = 3.16 times greater than what it is in 1x system. The upper atmospheres of most stock-sized planets are not designed for those types of speeds. Returning from Mun in stock KSP will have us hitting the atmosphere at about 3.2 km/s. In a 10x system we'll be traveling over 10 km/s. The stock atmosphere is too dense to simulate that in a realistic way. It may not be catastrophic to our vessel, but the drag and heating effects will spike up almost immediately after crossing the atmosphere boundary. It will be like hitting a wall of air, going from vacuum to a fireball almost instantly. Simply rescaling with Atmosphere does nothing to decrease the density of the upper atmosphere. If we want a less abrupt edge to the atmosphere so that its aerodynamics effects on an incoming vessel build up more gradually and realistically, then we need to extend the atmosphere beyond the original 1x atmosphere. We don't want to just stretch the atmosphere to a greater height, we want to extrapolate it out to a greater height. By extrapolating the curve we allow the atmospheric pressure to continue to drop as it would naturally. We get a thinner upper atmosphere that behaves more realistically and eliminates the "wall of air" effect. I recommend against ever setting Atmosphere to greater than 1.25. If somebody wants a taller atmosphere, then I recommend using atmoTopLayer to increase the height beyond what is gotten with a 1.25 rescaling. For resize factors between 1x and 10x, the Atmosphere parameter should probably be set to something between 1 and 1.25.

Just to elaborate a little bit on the new feature, there are now two parameters that when used together provide a powerful new way to modify atmospheres. These include the old parameter Atmosphere and the new parameter atmoTopLayer. The best way to explain how they work is to provide an example. Let’s say we have the following, Atmosphere = 1.25 atmoTopLayer = 1.6 Atmosphere rescales the original atmospheres curves. For example, Kerbin’s pressure and temperature curves go to a height of 70 km. By setting Atmosphere equal to 1.25, these curves are going to be stretched 25% to 70*1.25 = 87.5 km. This value is then multiplied by atmoTopLayer to determine the top of the atmosphere, which in this example is 87.5*1.6 = 140 km. What happens now is that the gap between where the atmosphere curves left off, 87.5 km, and the new atmosphere height, 140 km, is filled in by extending the curves. For a normal atmosphere this means that the pressure and density will continue to decrease with increasing altitude beyond where the original atmosphere ended. We can also go the other direction. Let’s say we're downsizing a full-sized body to stock-sized dimensions. We might use the following settings, Atmosphere = 0.8 atmoTopLayer = 0.625 If the original temperature and pressure curves go to 140 km, they are now rescaled to 140*0.8 = 112 km, and the top of the atmosphere is set to 112*0.625 = 70 km. Since the final atmosphere height is less than the height of the curves, the top of the curves are trimmed off. This feature allows for a much better and more realistic resizing of atmospheres. For example, extending a pressure curve to produce a lower density upper atmosphere can better accommodate the higher entry speeds that result from upsizing a celestial body. Altering the upper atmosphere density was impossible under the old method of resizing. Generally speaking, the rule of thumb for upsizing a celestial body from 1x stock-sized to 10x life-sized is to set the Atmosphere parameter to 1.25. This is because Kerbin’s stock atmosphere, as well as the custom atmospheres used by many of the popular planet packs, are based on life-sized models scaled down to 80% normal height. Therefore the 1.25 factor simply reverses the model back to its life-size equivalent.

We're planning to factor all dimensions by 10x, so it will be 6000 km.

Funny you happen to mention this because I've been meaning to start a conversation with you about the possibility of having SD handle atmospheres differently. I have some ideas I want to run by you, but I have no idea what can or cannot be done with code. Expect to receive a PM in the next day or so.

There was a time very early in GPP's development when we wanted to place Gael farther away from Ciro, being that Gael is the fourth planet in the system. This would have made Ciro a bigger and brighter star. It also would have given Gael a longer orbital period. But unfortunately we were handcuffed by the fact that the built-in calendar is hardcoded to 426 days of 6-hours duration (2556 hours total). This meant that, in order to preserve realism, we had to place Gael in its current orbit and make Ciro its current size and brightness. We ended up squeezing the inner four planets a little closer together to make it work. Since then, Kopernicus has added a custom calendar that links the lengths of the day and year to the rotational and orbital periods of the homeworld (possibly as a result of my urging). Had that feature been around three months ago, the GPP solar system would probably be a little different today.

From what I've been able to figure out, the following is what the various sun configuration settings do. The color of the sun's disc, such as when viewed up close in the Tracking Station, is given by: Material { emitColor0 = emitColor1 = sunspotColor = rimColor = } The color of the halo of light around the sun when viewed from a distance is given by: Light { sunLensFlareColor = } In GPP the above is set to 0,0,0,0 because Ciro's color is controlled by Scatterer. That's why we have an alternate Ciro.cfg for users who don't want to use Scatterer. The color of the sun's light, i.e. the light that illuminates objects, is given by: Light { sunlightColor = scaledSunlightColor = IVASunColor = ambientLightColor = } I'm glad you corrected yourself because I was about to. Going by this page - https://en.wikipedia.org/wiki/G-type_main-sequence_star - Ciro lies between G5 and G6 based on mass, and between G6 and G7 based on temperature. So that's why I listed it as a type G6 main sequence star.

@Galileo, this looks interesting. I like collecting science more than I like performing contracts, but I don't like that science mode completely removes funding from the game. This might be the solution. I'll have to give it a try the next time I start up a new game.

If we assume a 5-atm specific impulse of 215 s (about what I got for the Abel and Adam engines), then the Spark would produce about 13.5 kN and the Terrier would produce about 37 kN. I would have to do some more detailed calculations to determine what the exact numbers would be.

I'm not sure if any of the smaller engines would really have much use on Eve. The delta-v requirements are so high that by the time we build a launch vehicle big enough the provide it, we're going to need the larger engines to lift it. We'll need the lower thrust engines for later in the ascent, but by then we're high enough that we don't need them adapted for 5-atm (just use one of the stock engines). I'm just having trouble visualizing a scenario were one would need a low thrust engine adapted for 5-atm pressure. The only time we need a 5-atm engine is when we're lifting off the surface, and that's when we need high thrust. I agree that stock should include a smaller 1-atm engine, something about half the size of the Swivel and Reliant. In fact, I created for my own personal use a sea level adapted engine having a thrust of 120 kN. I know that the parts overhaul released with KSP 1.2 includes the 100-kN LV-T15 Valiant engine, so somebody else realized the need as well. I'm hoping the parts overhaul become stock in the future.

Exactly. The Sun is a little atypical. It seems a little dim to me too. Based on the config settings, I would have excepted the illumination to resemble the stock game. I think we're planning to make some adjustments for the next release.

I didn't use anything about Kerbol in my computations. Ciro properties were derived from two known pieces of information about Gael: solar constant = 1360 W/m2, sidereal orbital period = 426 days (6-hour days). From those given values and the equations previously referenced, Ciro's mass, luminosity and radius, and Gael's semimajor axis where derived. Ciro's temperature was computed from radius and luminosity.

The Sun doesn't lie on the centerline of the HR diagram. It's actually hotter than a typical star of its mass. Ciro's mass, luminosity and radius where derived from the equations found in the following paper: http://faculty.buffalostate.edu/sabatojs/courses/GES639/S10/reading/mass_luminosity.pdf

From Ciro's radius and temperature, it's luminosity is, (4 * π * 709800002) * 0.000000056704 * 55244 = 3.343E+24 W At Gael's distance, the solar constant is, 3.343E+24 / (4 * π * 139843567192) = 1360 W/m2 As I said, Gael's numbers are internally consistent. You can't determine anything from Kerbol's numbers because they are not internally consistent. Ciro has 0.96 solar masses and 0.87 solar luminosities. Where did you get that it is brighter than the Sun? Gael's AU is 0.935 times Earth's AU (scaled), which is why it has approximately the same solar constant as Earth. An Earth AU is 149,600,000 km.

I believe the "luminosity" setting is the solar flux at the AU distance. In stock, the solar flux is 1360 W/m2 at an AU of 13,599,840,256 meters. In GPP, the solar flux is 1360 W/m2 at an AU of 13,984,359,719 meters. I don't think that has anything whatsoever to do with the appearance of the sun or the color and intensity of the light it casts. I believe the luminosity is used for computing things like solar heating of parts, solar panel energy output, etc. In think the appearance of the sun and its light is completely independent of its effects. The appearance is controlled by sunlightColor, sunlightIntensity, scaledSunlightColor, scaledSunlightIntensity, and IVASunIntesnity. At least that's what I think. I did do some limited experimentation on this at one time, but not enough to say with 100% certainty that the above is correct. What I find somewhat baffling is that the intensity settings we're using in GPP are the same ones used in stock KSP. I don't know why things look so much dimmer.

I agree that it looks dimmer, and possibly yellower, in the game. But it shouldn't. We need to play around with the settings to correct that. For all intents and purposes, Gael and Ciro should mimic Earth and Sun in their appearance.

There seems to be some confusion here. Ciro is not a cooler and dimmer star than Kerbol. The sunlight intensity in the game may be less, but if that's the case, it should be adjusted. The most important thing is that the solar constant at Gael is exactly the same as it is at Kerbin (1360 W/m2), which is by design. And since Gael is slightly farther away than Kerbin, Ciro's luminosity is actually about 6% greater than Kerbol. Ciro is also about 9% more massive than Kerbol. Ciro does have a much smaller radius, but that's because Kerbol's physical properties are all messed up. Kerbol's radius, temperature, and luminosity (based on solar constant at Kerbin) are mathematically inconsistent. Based on its temperature and luminosity, Kerbol's radius should be less than Ciro's. I took special care to make certain that Ciro's properties are internally consistent. Ciro's computed temperature is 5524 K*. Kerbol's given temperature is 5840 K, but there's really no justification for that. Kerbol should be cooler than Ciro because it's a less massive star. Ciro should be slightly more orange than our real life sun, but probably not enough to be even noticeable. The light cast by Ciro should be white. * The tracking station information panel shows a temperature of 5840 K (the stock value) because there a glitch that prevents us from changing it.

I hadn't considered the Spark just because I thought it too small to be much use on Eve, but I'll take a look at it. It might be worth adding. Yes, theoretically the engines should be a little lighter, but I studied it and decided the difference is so small that it isn't worth altering the engines masses. The bells are pretty lightweight in comparison to the machinery. At looked at CKAN at one time and quite honestly it confused me. I didn't understand what was needed from me to get a mod added to it, so I didn't bother.

You can also try the following mod engines. They're designed for Eve's 5 atm pressure, but they'll still out perform anything out there at 10 atm. Also note that Tellumo's atmospheric pressure drops very rapidly with increasing altitude. If you can find some high terrain that you can land on (say 2+ km), taking off again should be doable with stock parts.

The energy output of solar panels should be the same as in the stock game. Although Ciro is much smaller in diameter than the stock sun, it has the same luminosity (or at least it should have). It's smaller only because the stock sun is way bigger than it should be in relation to the other bodies. Ciro's proportions are much more lifelike.

@MaxxQ, Gravity Turn definitely works because that's what I used when determining the launch Δv for the Δv map. However, I can't say for sure how good its guesses will be when trying to improve the trajectory. I really didn't use that feature, I made my own adjustments when seeking out the optimum settings/trajectory. Gravity Turn should do very well with Gael, and I suspect it will do as well for most other bodies as it does for the stock bodies. However, I've got my doubts about a body like Catullus. Catullus atmosphere is unlike anything in the stock game and I'm not sure Gravity Turn's decisions on how to improve the trajectory are going to be correct. Many of the settings I had to use for Catullus went in the opposite direction of what Gravity Turn customarily does. I certainly recommend that you give Gravity Turn a try. The autopilot feature most definitely works, and I think the self-learn feature will probably work in most cases. And if the self-learn feature isn't getting you where you need to be fast enough, override it and try out your own settings. I'm afraid I can't offer any advice about the other mods you mention, I'm not familiar with them.