OhioBob

Probably the best match would be 10.6257x. That would give Gael and Earth the exact same gravitational parameter.

Yes. The next GPP release will include configs for 2.5x, 3.2x, 6.4x and 10x.

At 2.5x we're factoring the atmosphere heights by 1.3. So Gael's atmosphere becomes 91 km.

I wonder if I've experienced the same problem and just didn't realize what was happening. The last time I played GPP I was trying to set up an encounter with Thalia and just couldn't get it to work. The planet didn't seem to be where it was suppose to be. I eventually got an encounter, but it was way off from where I intended it to be and the dV was way too high. I don't really remember all the details anymore, but it sounds very similar to your problem. I ended up just giving up out of frustration.

I'm pretty sure that Transfer Window Planner does take into account the different orbital planes (otherwise it wouldn't give a normal component). That being said, I have experienced problems getting an encounter with the target planet when using the Δv numbers it provides. On the other hand, I've had other times when its been pretty much right on the money.

4500 m/s definitely sound low for a 3.2x scale, I think its more like 5000-5500 m/s with the current KSP version. Here's my rationale for suggesting a 2.5x system... My goal is to find a scale that plays a lot like real life, but using stock parts. In real life, using conventional rockets, the general rule it that it takes two stages to achieve orbit, and three stages to escape. So that's the main driver behind my decision making. At 1x scale it's possible to reach orbit on only one stage, so that's out. At 2x the Δv requirement is large enough that SSTO is pretty much off the table, but it's still possible to pack enough Δv into two stages to reach escape velocity. That then brings us to 2.5x. At this scale we've pretty much reached the point where it takes three stages to go interplanetary. So the goal has been achieved at 2.5x. 3.2x achieves the goal as well, but I'm not sure it adds anything new to the experience. 3.2x is just a more difficult version of 2.5x, and I don't see a reason to make things more difficult than they need to be. I believe that at 2.5x rockets will have a lifelike design and look to them, but because of the lower Δv requirements versus 3.2x (about 13% less), a player will be able to do more and achieve more. That's my 2₵, for what it's worth.

My guess is that you want to tinker with the @atmoVisualEffect setting in 10X.cfg. If you find a setting that you think looks better, please share it with us. Of course changing the global setting will change it for all the planets. If you only want to change Gael, you can make a planet specific change.

Changing the orbit wouldn't do anything to the weather. For planets with atmospheres, all the temperatures are controlled by the atmosphere temperature curves. That is, orbit and temperature are controlled completely independent of each other. If I really wanted to mess with things, I could turn Niven into a frozen ice world, and make Hox a sweltering desert. Of course, what the developer really should do, and what I did for GPP, is write temperature curves that are consistent with the planet's location and orbit. Some of the planet's in GPP do have seasons of a sort, but the temperature variations are pretty small (generally +/- only a few degrees). @Galileo, this just got me wondering about something. Is there any way that you know of that can link visual effects to seasons? For instance, could you produce snowfall effects only during a winter season? Ah, good to know. Apparently Sigma Dimensions must change the space altitude threshold by the resize factor. It's probably the flying altitude threshold that's changed by the atmosphere factor. @Sigma88, if you're out there, please refresh my memory (I asked you once before but I've forgotten the answer). How are flyingAltitudeThreshold, spaceAltitudeThreshold, and timewarpAltitudeLimits changed when a planet and its atmosphere are resized?

Post deleted - instructions previously posted here are no longer applicable.

Sigma Dimensions factors that, but I don't know what the current formula is. I think it use to factor the flying and space limits by the same factor as the atmosphere. But Sigma now has two atmosphere factors, Atmosphere and atmoTopLayer, so I don't know what it does. You might want to ask that question in the Sigma Dimensions thread.

To any one interested in creating their own atmospheres, I've just completed and released an Excel spreadsheet that automates the process (or at least much of it). It follows the methods described in this thread, though with a few changes to simplify things and make the calculations less buggy.

Make your own Atmospheres for KSP Excel spreadsheet for mod developers who want to create their own realistic atmospheres Primary Download Site - KSPatmoCalculator, v2.0.6 Alternate Download Site - KSPatmoCalculator, v2.0.6 An Excel spreadsheet used to create atmospheric models for celestial bodies in Kerbal Space Program. It takes input from the user and automatically generates an entire Atmosphere node that can be copied and pasted into your Kopernicus configuration files. It implements the full array of atmosphere curves available to KSP modders. The user still has creative control over many aspects of the atmosphere, such as composition and surface pressure, but the complex number crunching is all done behind the scenes. There is no math required on the part of the user. Real life gas laws are used to create realistic pressure curves. Temperature curves are approximations based on atmosphere type, solar irradiance, and other factors. An entire atmosphere can be completed in minutes. For those familiar with the old calculator, this is completely new. Everything is now combined into a single spreadsheet that should be much easier to use and understand. The input sheets are arranged in simple step by step question and answer formats. The new spreadsheet is also much more stable than the pervious version and less prone to errors and failures.

I tried 10x RSS for a little while and I had the same experience. I just didn't find it fun. For now we're keeping 3.2, 6.4 and 10x verisons, but we're also adding a 2.5x for the next release. There's not a huge difference between 3.2x and 2.5x, but it should be enough to make 2.5x noticeably easier. Delta-v requirements in 2.5x should be about 12% less than in 3.2x. The goal it to allow people to play entirely with unmodded stock parts, but still be able to go interplanetary. We want to make interplanetary difficult, but not impossible. At this point there is really no experience with a 2.5x system. We'll just have to have people try it out and give us their feedback. If 2.5x is well received, we'll stick with it. If more tweaking is required, I suppose we can try a 2x system. There's no reason we have to limit ourselves to what people have done in the past (3.2, 6.4 and 10x). There has to be a sweet spot out there somewhere that most people will be happy with, we just have to find it.

As explained in the link provide by eberkain... "This number was chosen as scaling the world 6.4 times larger would then match the scale of the parts in comparison of real world equipment." This is the same reason why some players of 10x systems scale up the their parts by 1.6. That is, 1.6 to 10 is approximately the same ratio as 1 to 6.4. I've never heard anyone give a good reason for 3.2x. I assume it's used just because it's half of 6.4x. Personally, I have serious doubts about 3.2x. At the larger sizes (6.4x and 10x) it is really essential that the parts be modded to improve their mass ratios. At 3.2x I think we're on the line between having to mod the parts, versus really struggling to get by with stock parts. Straddling that line doesn't make sense to me. What makes sense is to either go with a larger scale where we have to definitively mod the parts, or use a scale that increases the difficulty but can still be played with unmodded stock parts. I think 2x or 2.5x would be a lot better than a 3.2x. At those sizes the Δv requirements would definitely go up and add a challenge to the game, but I don't think it would be out of the reach of stock parts. In fact, in terms of multiples, 2.5x is very close to halfway between 1x and 6.4x. That is, 1*2.5*2.5 = 6.25. (Another reason why 2.5x makes more sense than 3.2x.) (edit) We chose to use 3.2x and 6.4x scales for GPP simply because those scales were already in use by other mods.

@The White Guardian, the lower areas of an atmosphere are pretty thoroughly mixed and can be considered a homogeneous mixture of gases. In fact, this region of an atmosphere is called the homosphere. Higher up the gases begin to stratify, with each gas having its own scale height. This part of the atmosphere is called the heterosphere. The transition point between homosphere and heterosphere is called the homopause. On Earth the homopause lies at about 80 km. My own study of the atmospheres of Venus and Mars has found that the homopause lies at about 120 km for both planets. For stock sized planets, the atmospheric model will generally terminate at or before we reach the homopause. Therefore I've never found any reason to consider changes in the molar mass of the gas. I think that the KSP method of assuming constant molar mass works fine in that circumstance. However, when producing atmospheric models for life-sized planets, I have investigated this phenomenon and worked up some models and spreadsheets that take it into consideration. Although KSP doesn't not allow us to change the molar mass, I did devise a method that allows us to fake it out. My method was to have my spreadsheet develop the atmospheric model as it would be in real life, with the molar mass changing once we get above the homopause. However, when it came time to compute pressueCurve, instead of using the actual pressure, I added another column for effective pressure. The important parameter in determining how the atmosphere will effect a body aerodynamically is the density, not the pressure. Effective pressure was computed from the actual density assuming a constant molar mass at all altitudes of the atmosphere (like KSP does). By having pressureCurve switch from actual pressure to effective pressure at the homopause, KSP would compute the correct density everywhere. When I applied this technique to some sample models, I found something interesting. Once we get into the heterosphere, the molar mass of the gas decreases with increasing height. However, this also means that the scale height is greater, so the pressure rate of change is less. In other words, as we go higher, the molar mass decreases but the atmospheric pressure is higher than it would be had the molar mass not decreased. These two effects almost exactly cancel each other out to where the density of the atmosphere follows the same curve regardless of whether we take the changing molar mass into account or not. My final conclusion was that it's just not worth the trouble to consider the changing molar mass. As far as atmospheric density is concerned, it is just as accurate to assume the molar mass is constant throughout the atmosphere as it is to assume otherwise. The pressureCurve may not be entirely realistic in this circumstance, but that's not what's important when considering the aerodynamic effects. I think getting the density correct is more important, and that we can do without having to mess around with changing molar mass.

Thanks for the thorough answer, @Snark. (I've learned to expect nothing less from you.) Something interesting about ideal gases is that at a given temperature and pressure, a given volume will always contain the same number of gas molecules regardless of the molecular weight of the gas. If we have a one liter container at standard temperature and pressure, it will contain the same number of oxygen molecules as it would methane molecules. And since oxygen is twice as heavy as methane (mmolar = 32 vs. 16), a container holding oxygen will have twice the mass of gas and twice the density as a container holding methane. You can see this from Snark's equation, ρ = mmolar * (P/RT) If P and T are constant, then ρ is directly proportional to mmolar. From this we can also see that if we have a vessel containing a mixture of gases, then the number of molecules of each gas is directly proportional to its volumetric fraction. Say we have a vessel containing 2 liters of oxygen and 1 liter of methane, then we have twice as many oxygen molecules as we have methane molecules. That's is why it's possible to easily compute the average molecular weight as Snark described. In this example, 32*2/3+16*1/3 = 26.667.

Average density is total mass divided by total volume. So you simply do what you have to do to add up the mass and volume.

That's hilarious. I'll have to steal that one from you.

I've mentioned this several times in this thread (and elsewhere), so I figured I ought to explain. The formula to compute gravitational acceleration is as follows (for a derivation, see here): g = μ / r² where μ is the gravitational parameter (gravitational constant * mass), and r is the radius. In KSP, when we rescale a body, we generally keep it's surface gravity the same. Therefore the value of g in the above equation is a constant, which means that μ is proportional to r², μ r² The equation used to calculate orbital velocity is as follows (for a derivation, see here): v = ( μ / r )1/2 Substituting r² for μ, we see that v is proportional to the square root of r, v ( r² / r )1/2 r1/2 This proportionality is true not only for orbital velocity, but also escape velocity, velocity changes, etc.

I'm certainly no expert on winds, but my gut feeling tells me that winds on Tellumo wouldn't be that bad. The planet doesn't have a very large range of temperature. Aren't temperature differences (i.e. density differences) the main driver of winds (warm air rising and cool air sweeping in to replace it)? The planet that has the largest range of temperature (with rapid changes over the daily cycle) is Niven. My guess is that Niven probably has some pretty serious convection cells. Of course its air is thin, so its winds wouldn't have the force of those on planets with thicker atmospheres.

When a solar system is scaled up, velocities goes up by the square root of the rescale factor. So you must travel 3.2 times farther, but your speed only SQRT(3.2) = 1.79 times faster. Therefore, your flight time also increases by the square root of the rescale factor. That is, 3.2x distance / 1.79x speed = 1.79x time. Regarding travel times to the RL Moon, the Apollo missions didn't fly Hohmann transfers. They flew something called a one-tangent burn to decrease the flight time from about 5 days for a Hohmann transfer to about 3 days. Don't forget also that those are 24-hour days. A Hohmann transfer to Iota in 3.2x scale should take about 45 hours, while a Hohmann transfer to the RL Moon would take about 120 hours. (edit) Also note that in 3.2x, Gael's day is increased from 6 to 12 hours, therefore your travel time to Iota should be about the same as 1x when measured in days.

The only thing I can add to what @Snark said is that the units in his calculation are g/mol or kg/kmol. KSP and Kopernicus uses units of kg/mol, so you have to divide by 1000. So for Snark's example the molar mass is 0.0288 kg/mol.

Don't copy "GPP Kerbal Konstructs" into your GameDate folder. You have to drill deeper and copy the contents of the GameDate folder of the .zip to the GameDate folder of your KSP installation. In the .zip file your will find, OptionMods/GPP Kerbal Konstructs/Gamedata/ which contains the folders, KerbalKonstructs KSCFloodlight LackMisc It is the above three folders that get copied to the GameDate folder of your KSP installation. You always want to drill down until you find the GameData folder, then copy the contents of GameData to GameData. I don't know what the problem is with Tellumo, but Hadrian's atmosphere is not breathable. The only atmospheres that are suppose to be breathable are Gael and Tellumo.

I generally try to avoid flying through rings, but I make only a modest effort to do so. If I mess up, or if it's unavoidable, I don't worry about it too much.

I've seen three of them. Bolivia in 1994, Aruba in 1998, and on the Black Sea in 1999. (My avatar is a photo of the Bolivian eclipse.) Hopefully I'll see my fourth this summer. For those of us living in the United States, we have one coming right to our backyard. On 21-August of this year a total solar eclipse will be cutting a path right across the middle of the country, from Oregon to South Carolina. I definitely recommend to everyone living nearby that they make an effort to see it. A total solar eclipse is one of nature's truly unique experiences. Total eclipse of the sun: August 21, 2017