• Content count

  • Joined

  • Last visited

Community Reputation

1233 Excellent

1 Follower

About OhioBob

  • Rank
    Junior Rocket Scientist

Contact Methods

  • Website URL http://www.braeunig.us/space/

Recent Profile Visitors

5043 profile views
  1. Probably the best match would be 10.6257x. That would give Gael and Earth the exact same gravitational parameter.
  2. Yes. The next GPP release will include configs for 2.5x, 3.2x, 6.4x and 10x.
  3. At 2.5x we're factoring the atmosphere heights by 1.3. So Gael's atmosphere becomes 91 km.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. Instructions KSPatmospheres.xlsx is an Excel spreadsheet used to create realistic atmospheric models for celestial bodies in Kerbal Space Program. These instructions explain only how to use the spreadsheet. If you want a detailed explanation of how to create atmospheres in KSP, then I refer you to the following: The workbook contains three worksheets: Date Input, Configuration, and Sheet3. The first, as the name implies, is where the user enters the information from which the atmospheric model is generated. The second worksheet is the resulting atmosphere node that must be copied to the Kopernicus configuration file. The last sheet is where the pressure curve computations are performed. All formulae are locked and password protected. Data Input Below is a screenshot of the Data Input screen, which is the primary user interface: At the top of the page is the spreadsheet title, version number, and author. The “Instructions and Help” hyperlink directs you to this page. The white cells are the places where values must be entered. The numbers seen above are from the example that comes with the spreadsheet. To use, you will replace these values with your own numbers. The numbers in the gray cells are computed values that are either used in other calculations, or are provided for information. Below is a cell-by-cell description of what it all means Cell E5 – The solar constant at the home world, which for Kerbin is 1360 W/m². Unless you’ve done something with your mod to change this, you should keep the default value. Cell E6 – The semimajor axis of the home world in astronomical units. Since 1 AU is typically defined as the home world’s distance from the sun, this value should be equal to 1. Cell E8 – The mean radius of the current body. This is the radius of the body at the scale given in cell E9. (“Current body” refers to the celestial body for which you are generating the atmosphere.) Cell E9 – The solar system’s scale factor. This is the size of the solar system in which you are placing the current body. A scale factor of 1 means a stock-sized solar system, and a scale factor of 10 means a life-sized system. Cell E10 – The current body’s surface gravity, measured in g. Cell E11 – The semimajor axis of the current body’s orbit around the sun, measured in AU. If the body is a moon, then the orbital elements given in cells E11 through E14 are those of the parent planet. Cell E12 – The eccentricity of the current body’s solar orbit. Cell E13 – The inclination of the current body’s solar orbit. Cell E14 – The argument of periapsis of the current body’s solar orbit. Cell E15 – The current body’s albedo. Cell E16 – The solar flux at the current body’s mean distance from the sun. Cell E17 – The current body’s effective temperature. Effective temperature takes into account only the amount of energy received (solar flux) and the amount reflected away (albedo). It’s a good starting point for determining a body’s surface temperature. An atmospheric body should be warmer than its effective temperature due to greenhouse effect. Some bodies, like gas giants, also produce internal heat, making them much warmer than their effective temperatures. Cell E20 – The current body’s atmospheric pressure at “sea level”, i.e. at an elevation of zero. For a body without oceans, the datum is usually placed at or near the lowest surface elevation. In that case, the value entered here is the maximum surface pressure. Cell E23 – The current body’s latitudinal temperature range, i.e. the difference in temperature between the body’s equator and its poles, measured at coldest time of the night. (This temperature difference is usually greater during the daytime.) Cell E24 – The diurnal temperature range measured at the equator. This is the difference between the maximum daytime temperature and the minimum nighttime temperature. Cell E25 – The diurnal temperature range measure at or near the body’s poles. Cell E26 – An estimate of the theoretical maximum range of temperature produced by axial tilt. Although KSP bodies have no axial tilt relative to the ecliptic, their equators are tilted relative to their orbits by an amount equal to the orbital inclination. (Should KSP enable axial tilt in the future, this section of the spreadsheet will have to be modified.) Cell E27 – An estimate of the theoretical maximum range of temperature produced by the eccentricity of the body’s orbit around the sun. Cell E28 – An adjustment factor applied to the values computed in cells E26 and E27. It reduces the theoretical maximum range of temperature for bodies with short orbital periods (where they have insufficient time to time to reach thermal equilibrium.) The formula is empirical and derived from the seasonal variations of Earth. Cells A33:B52 – The current body’s base temperature profile (i.e. temperatureCurve). Base temperature is that of the body without any latitudinal, diurnal or seasonal variations added. It is approximately equal to the body’s mean minimum temperature. The numbers in column A are the altitudes, and the numbers in column B are the corresponding temperatures. The values should be sorted in order of increasing altitude. The temperature profile is made up of a series of straight line segments. Up to twenty points can be entered, which will produce a maximum of 19 line segments. With that many segments, it should be easy to approximate a curve. If you use less than the maximum number of points, just leave the unused fields blank. (A segmented temperature profile is used, in lieu of a continuous curve, to simplify the computations and make the spreadsheet less buggy.) The maximum altitude of the temperature profile must equal or exceed the final computed height of the atmosphere. If this condition is not met, an error message is triggered. It is then necessary to either stretch or extend the temperature profile to increase the maximum altitude. It does no harm to have the maximum altitude exceed the height of the atmosphere. When changing the solar system scale factor, it is common to also change the height scale of the temperature curve. When going from a 1x system to a 10x system, it has become customary to factor the heights of the temperature curve by 1.25. And when going from 10x to 1x, the heights are commonly factored by 0.8. If such factoring is necessary, it must be done by the user. There is no automatic rescaling of the temperature curve when changing scale factors. What is listed in cells A32:A52 is what you get. Cells F33:G46 – The current body’s temperatureSunMultCurve. This is a multiplier that determines how the temperature variations (latitudinal, diurnal and seasonal) change with increasing altitude. The temperature variations are totaled, multiplied by temperatureSunMultCurve, and added to the base temperature. Like the temperature profile, temperatureSunMultCurve is made up of a series of straight line segments, with up to 13 segments possible. The maximum altitude must equal or exceed the height of the atmosphere. There is no automatic rescaling of temperatureSunMultCurve when changing scale factors. For planets with solid surfaces, the temperature variations are usually greatest at the surface. Gas giants, on the other hand, usually have their greatest variation in the upper atmosphere, with little or no variation at the datum. Cells J6:J25 – A list of gas constituents that may be present in the atmosphere. Included are the most common gases found in planetary atmospheres, as well as those that are usually found in only trace amounts. Cells K6:K25 – The chemical formula of the substance listed in column J. Cells L6:L25 – The percentage of each gas by volume that comprises the atmosphere. Cell L26 – The total of cells L6:L25; must equal 100%. Cells M6:M25 – The gas molecular weight, in g/mol. Cells N6:N25 – The constant pressure specific heat, computed for the temperature given in cell K29. This is used in the computation of the adiabatic index. Cells O6:O25 – The melting (freezing) point of the substance, computed at the pressure given in cell M37. If the cell displays “n/a”, then the pressure is below triple point where the substance cannot exist in liquid form. In this case, the temperature listed under B.P. is actually the sublimation point. Cells P6:P25 – The boiling (or sublimation) point of the substance, computed at the pressure given in cell M37. If the cell displays “n/a”, then the pressure is above the critical point where there is no clear phase change between liquid and gas. The substance can exist as a supercritical fluid. Melting and boiling points are provided as a guideline in determining the likely phase of a substance under the conditions found on your celestial body. If the temperature is above the boiling point, then the substance will be present as a gas. If the temperature is below the melting point, then it is likely that much or most of the gas has frozen out of the atmosphere and exists on the surface as ice. If the temperature is between the melting and boiling points, then it’s possible the substance can exist in both gas and liquid states. However, simply falling within this range of temperature doesn’t necessarily mean that liquid can survive long term on the surface. The ability of liquid to exist on a body’s surface is a more complex subject that I can elaborate on if requested. Cell M28 – The molar mass of the atmosphere, i.e. the mean molecular weight, based on the percentages given in cells L6:L25. Cell K29 – The temperature at which the adiabatic index is calculated. This cell contains a formula that computes the mean temperature of the entire air mass. The formula can be replaced by whatever temperature the user chooses to enter, but I don’t recommend doing so unless you have a good reason for changing it. Cell M29 – The adiabatic index (specific heat ratio) of the atmosphere at the temperature given in cell K29. Cell M31 – An estimate of the minimum molecular weight gas that the body is capable of retaining. Gases with molecular weights less than this value have likely escaped the planet and are no longer present in anything more than trace quantities. A body’s ability to retain a gas is a function of escape velocity and temperature. Cell K32 – The elevation at which the greenhouse effect is computed. For an ocean world, you should enter 0 for sea level. For an airless body, you should estimate the mean surface elevation. Using the body’s mean elevation provides a more realistic estimate of how much the surface is warmed by the greenhouse effect. Cell M32 – The amount the surface is warmed by the greenhouse effect. It is the difference between the body’s mean surface temperature, computed at the elevation given in cell K32, and the body’s effective temperature given in cell E17. This should be a positive number – if not, you should adjust the body’s temperatures to compensate. Greenhouse effect can vary from a few degrees (≈8 K for Mars) to hundreds of degrees (≈500 K for Venus), depending on distance from the sun and the thickness and composition of the atmosphere. Cell M35 – The spreadsheet allows you to compute the air pressure and temperature at selected latitudes and altitudes. This is where you enter the latitude. Note that the temperature at a latitude of 38° closely approximates the global mean temperature. Cell M36 – The surface elevation or altitude at which you want to know the air pressure and temperature. Cell M37 – The atmospheric pressure at the specified latitude (cell M35) and elevation (cell M36). This is the pressure used to compute the melting and boiling points. By specifying different locations, you can see how the MP and BP change, helping to identify locations where liquid or ice might appear on the surface. Cell M38 – The mean annual temperature at the specified latitude (cell M35) and elevation (cell M36). The best estimate of the body’s globally averaged surface temperature is found by entering a latitude of 38° and the mean surface elevation. Cell M39 – The mean maximum temperature at the specified latitude and elevation. This is an average of all the daily high temperatures collected over an entire year. Cell M40 – The mean minimum temperature, the average of all the daily low temperatures. Error Messages – The area in the upper-right part of the worksheet (not seen in the screenshot) is reserved for error messages. At present, there are three things that can trigger an error message: (1) the atmosphere height exceeds temperatureCurve’s altitude range, (2) the atmosphere height exceeds temperatureSunMultCurve’s altitude range, or (3) the maximum height limit of the atmosphere has been reached. When in the process of inputting new data, such as when changing from one body to another, it is likely some formulas will produce errors. This is normal and nothing to be concerned about. Once all the new data has been correctly entered, the errors should go away. If you believe all the new data has been correctly entered and you are still getting errors, then there may be a problem. Please report the issue here and I’ll look into it. Configuration The Configuration worksheet is the end result of all the computations. It is the atmosphere node that must be copied to your Kopernicus configuration file. This data can be easily copied and pasted from Excel into a simple text editor like Notepad. Simply select cells A5:E119 and press CTRL+C. Go to Notepad and select the location where you want to insert the data, then press CTRL+V. The atmosphere node will be inserted into Notepad in a tab delimited text format. Note that albedo goes under the Properties node, therefore you will have to copy and paste this separately from the Atmosphere node. After the node has been pasted into the Kopernicus file, there is some tidying up that must done: · The Configuration worksheet reserves space for the maximum number of keys that a curve can have. If your curves use less than the maximum number, then delete the unused lines. · If you are modifying an existing atmosphere node, then @ must be added to the node name, i.e. “@Atmosphere”. · If you want to change the appearance of the atmosphere, you’ll have to add an AtmosphereFromGround sub-node and modify the settings. Any of the configuration parameters and curves can be changed by the user, but I don’t recommend it unless you are sure of what you’re doing. Below is a brief description of each parameter and curve albedo – Value from ‘Data Input’ cell E15. enabled – “True” enables the atmosphere in KSP. oxygen – “True” if percentage of either atomic or molecular oxygen is > 0, else “False”. altitude – The maximum height of the atmosphere. Knowing when and where to end an atmosphere is one of the things that the spreadsheet does automatically. It therefore seems advisable to provide an explanation of how this process is accomplished. The theory is that an atmosphere’s upper boundary should be placed at such altitude that the aerodynamic effects it produces on a body entering at high velocity adheres to some standard set of values. This produces some commonality in the boundary conditions for all atmospheres of similar type. The velocity use is escape velocity, and the aerodynamics effects are measured by dynamic pressure and heating rate. An atmosphere ends when both dynamic pressure and heating rate drop below preset values. The values used differ for hydrogen-helium atmospheres, typically gas giants, versus atmospheres of heavier gases, typically terrestrial and ice bodies. For the latter group, the values were derived from the boundary conditions of a Kerbin-like atmosphere. For the former group, values were derived from past atmospheres that I’ve developed. The ending point determined above is last point in the pressureCurve that is given a computed pressure value. On top of this is added a zone in which the atmospheric pressure is made to taper off to zero at the upper edge. The height of this additional zone is equal to one scale height. The final maximum height of the atmosphere is rounded up to the next whole kilometer. Bodies with surface temperatures ≥2200 K (the approximate dividing point between brown dwarfs and red dwarfs) are assumed to be stars. The ending point of a stellar atmosphere is determined by an entirely different set of standards. Here the atmosphere ends simply when the gas density drops below 1E-09 kg/m³. Although the height of an atmosphere has no theoretical limit, here the limit is set to 2000 km (+1 scale height). The only reason for this is because that’s the number of computations performed (it had to stop somewhere). In my experience it’s unlikely you’ll reach the 2000 km limit, but if you, there are two options: (1) make changes to your input parameters to lower the top of the atmosphere, or (2) contact me. adiabaticIndex – Value from ‘Data Input’ cell M29. atmosphereMolarMass – Value from ‘Data Input’ cell M28. temperatureSeaLevel – The annual mean temperature at a latitude of 38° and an elevation of zero, which approximates the body’s mean “sea level” temperature. For an airless body whose datum is located at or near the lowest surface elevation, this temperature is likely higher than the body’s true mean surface temperature. staticPressureASL – Value from ‘Data Input’ cell E20, multiplied by 101.325 kPa/atm. temperatureCurve – This is the temperature profile entered in ‘Data Input’ cells A33:B52, with input and output slopes computed. temperatureSunMultCurve – These are the values entered in ‘Data Input’ cells F33:G46, with input and output slopes computed. temperatureLatitudeBiasCurve – This curve is computed from the latitudinal temperature range (‘Data Input’ cell E23), where, temperatureLatitudeBiasCurve = ΔT*(COS(latitude)–COS(38°)). temperatureLatitudeSunMultCurve – This curve is computed from the diurnal temperature ranges (‘Data Input’ cells E24 & E25), where, temperatureLatitudeSunMultCurve = (ΔTE–ΔTP)*COS(latitude)+ΔTP. temperatureAxialSunBiasCurve – Maximum seasonal temperature variation (at the poles) resulting from axial tilt, as a function of true anomaly. temperatureAxialSunMultCurve – A latitudinal modifier for temperatureAxialSunBiasCurve. temperatureEccentricityBiasCurve – Seasonal temperature variation resulting from orbital eccentricity. pressureCurve – The atmospheric pressure profile, where altitude is in meters and pressure is in kilopascals. This is the curve generated by all the computations on Sheet3.
  10. 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.
  11. 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.
  12. Make your own Atmospheres for KSP Version 1.0.1 A tool for mod developers who want to create their own realistic atmospheres KSPatmospheres.xlsx is 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, surface pressure and temperature, 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. An entire atmosphere can be completed in minutes. Download Change log:
  13. 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.
  14. 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.
  15. @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.