OhioBob

Members
  • Content count

    1501
  • Joined

  • Last visited

Community Reputation

1435 Excellent

4 Followers

About OhioBob

  • Rank
    Junior Rocket Scientist

Contact Methods

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

Recent Profile Visitors

5807 profile views
  1. @KerbMav, the stock temperatureLatitudeBiasCurve for Kerbin has a broader latitudinal range of temperature than RA. From +17 at the equator to -50 at the poles. So the poles should be frostier in stock than in RA. For temperatureLatitudeSunMultCurve, there not a large difference between stock vs. RA. Through the RA range is based on a scientific paper that I found studying diurnal temperature range on Earth, so I think it may be more lifelike. The RA latitudinal range is also based on real life models of Earth.
  2. @Sigma88, it looks like your suggestion to delete the .bin files worked after all. Like an idiot I deleted the wrong file when I said it didn't work. When I realized my mistake and deleted the correct file, the problem went away. Thanks for your help. That's good to know that when I make changes like this I should delete the .bin file.
  3. I believe the Kerbalism solar panel bug is fixed by deleting the following file: GameData\GPP\GPP_Configs\SolarPanelChargeRate.cfg You need that file if you play without Kerbalism, but with Kerbalism installed, there's some sort of unintended interaction that messes up solar panel energy output. I'm not entirely sure what the problem is, but deleting the file seems to fix it (according to another user who complained of the same issue). Deleting the file might cause problems with solar panels around Grannus, but that may be unavoidable.
  4. That didn't work. I'm still getting the same effect along the planet's limb. Nevermind.
  5. Realitstic Atmospheres is completely compatible with Sigma Dimensions. Just install both RA and SD and write your SD config as you normally would. If you're getting too much reentry heat shortly after entry, it sounds like you might not be using the atmoTopLayer multiplier. atmoTopLayer is used to extrapolate the atmosphere beyond where the original curves left off so that you get a thinner upper atmosphere. The formula that I use for the atmosphere factors is, Resize^LOG(X) where X = height at 10x / height at 1x. So for atmosphere, the height at 10x is 1.25, and the height at 1x is 1. And the total height of the atmosphere at 10x is 1.25*1.6 = 2, and at 1x it is 1. Therefore, for a 2x resize I'd use the following: Atmosphere = 2^LOG(1.25) = 1.07 Total height = 2^LOG(2) = 1.23 atmoTopLayer = 1.23 / 1.07 = 1.15 I generally use the computed value of Atmosphere without modification. There's more flexibility with atmoTopLayer. For instance, in this case we might want the final height of the atmosphere to be 1.2 times the original height so we don't get a bunch of weird numbers. In that case, atmoTopLayer = 1.2 / 1.07 = 1.121495327
  6. I think I did at one time, but I've been making so many changes that I really don't remember now. Let me give that a try and see what happens. Are you talking about the MM cache?
  7. I've got a problem I'm hoping somebody has a solution to. This has likely come up before, because it seems to be rather common problem, but I haven't been able to find any discussion about it. I have a situation were the size of the planet as rendered in scaled scale versus PQS doesn't match up. The PQS rendering has a larger radius, so when I'm at the range of distance where both are rendered, I have two superimposed images that don't quite match up. I can fix it by changing either the planet's deformity, or its offset, but neither is a good solution. When I set (deformity + offset) = 5000, there's a near perfect match between the two renderings. However, if I set the deformity too low, the planet is too flat a featureless. For aesthetics, I need a large deformity. But if I set the deformity larger than 5000, then I must use a negative offset. A negative offset means that I have large portions of the surface lying at negative elevation. This causes the radar altimeter (i.e. 'height above terrain') to not function correctly (plus I understand there is other bugginess associated with negative elevations). So, for example, either of the following fixes the mismatched images, deformity = 5000, offset = 0 deformity = 8000, offset = -3000 But both solutions are bad for the other reasons already described. Does anybody know a way to get the scaled space and PQS images to coincide without having to change the deformity and/or offset to values that I don't want to use?
  8. Good one, @Snark. Here's my discovery...
  9. Standard GPP is 1/10th scale compared to real life, just like stock KSP. But GPP comes with several configs that, when used with Sigma Dimensions, will scale the system up to larger dimensions. 2.5X - Intended to give the game a more lifelike feel to it in terms of rocket and spacecraft design, while using unmodified parts. 3.2X - Same as 2.5X but a little more difficult. 6.4X - Gives parts a lifelike scale in relation to the planets. This difficulty level generally requires the use of SMURFF to modify parts closer to their real life mass ratios. 10X - Scales all celestial bodies up to real life dimensions. Modifying parts to match real life mass ratios and performance is essential. 10.625X - Turns Gael into an Earth clone in terms of size and mass.
  10. @Mrcarrot, the following works: It took two things to make it work. First, I tidied up the formatting. I'm not sure what was wrong specifically, but I went and changed all the indentation to tabs rather than spaces. Second, I deleted the atmosphere node. One of those changes alone won't work, but the combination makes your planet appear. I don't know what's wrong with the atmosphere node. At first I thought it was a formatting problem - your curves have a lot of extra spaces between numbers. I tried to fix the formatting but it still doesn't work. I'll take a second look and see if I can figure it out. (edit) I copied into your config an atmosphere node from another planet that I know works. The above config with the alternate atmosphere node works fine. When I copied your pressure curve back, it failed. There definitely seems to be something in your pressure curve that Kopernicus doesn't like. Why don't you try making your atmosphere using this:
  11. Sorry, I don't see anything else obviously wrong. Are you sure the path to your color map is correct and that the texture is there? Planet's won't show up when there's a missing texture file. I also normally use .dds files for my color maps, though I don't know if that's a problem, .png might work as well. When you say it doesn't work, what do you mean? What's not working about it?
  12. I only mentioned it because @Mrcarrot's config has specifically set it equal to true. So he can either set it to false, or just delete the line entirely and let is default to false.
  13. @Mrcarrot, I also recommend using finalizeOrbit = False (unless you are adding to a mod that already uses finalizeOrbit = True, like RSS).
  14. You have one too many time warp limits specified. There should only be 8 values, while you have 9. timewarpAltitudeLimits = 0 200000 430000 650000 87000000 290042000 30000000 300000500 300000500
  15. @Mrcarrot, I don't know what's up with the following, but I'd delete those lines, or maybe just give them a value of zero (can't land or splash on a gas giant). Those crazy large numbers might be causing a problem. landedDataValue = 374495378249826572647863862786578678973486790275986574865787897598763745876374 splashedDataValue = 8394751987592759837573659714865725627847368243659827464836523746146756327564537 It also looks like your atmosphere is composed of americium. atmosphereMolarMass = 0.24300000146 That's 243 kg/mol, or a molecular weight of 243 g/mol. I think you probably want it to be 0.00243, i.e. a hydrogen-helium atmosphere. It's also my understanding that the following are redundant. When both are specified, I believe lightColor governs. lightColor 0.034,0.0,0.255,0.3 AtmosphereFromGround { waveLength = 0.6801278, 0.6741574, 0.6262613, 0.5 } This number also looks funny, meanAnomalyAtEpoch = 24300.238600 The mean anomaly is measured in radians, thus it has a value between 0 and 2pi. A value of 0 means the planet is a pariapsis at the specified epoch, and a value of 3.14 means the planet is at apoapsis at the specified epoch.