OhioBob

Yes, if you download the master branch you should be using the same up-to-date version that I am. You'll also need to download the textures from the GPP_Textures branch. BTW, I've also have been running GPP dev version in KSP 1.2.2 using Kopernicus 1.2.2-9 and SCANsat 16.11. I haven't had any problems with that setup at all.

@DMagic, I'm still having a problem between SCANsat 18.0 and GPP with being able to select moons from the celestial bodies menu in the big map view. We discussed this problem earlier in the 17.X dev thread. I put a scanner in orbit starting with the innermost planet and just starting working my way outward. For all the inner planets and moons, everything seems to work fine. I can scan bodies and select them from the dropdown menu in the big map view. However, as soon as I get to the moons of the gas giant planets, the names of the these moons will not appear in the menu and I cannot select them. Once I get beyond the gas giants to the solid outer planets, the names of both planets and moons again appear in the menu. For some reason the names of the moons of the gas giants do not appear in the big map dropdown menu. When switching to the Color Management screen, all the names are present. The problem appears to be just with the big map. Furthermore, when I'm in orbit around and scanning one of the gas giant moons, I can see it in the small map view. But when I open the big map, the name of the moon is not there in the menu. If there is anything else that you need from me, logs etc., just ask.

FYI, drawing the nozzles to the correct scale, they'd look something like this:

@linuxgurugamer, I just took a look at the particular example that you provided. I'm very concerned about the added length of the engines. I think doubling the length of the engines would cause serious design and construction problems. First, the added length will raise the vehicle's center of gravity, and stability can already be a problem for a lander of the size needed for Eve. It might also make it more difficult to figure out how to provide mounting points for landing gear and ladders that must reach the surface. I just don't think that doing something strictly for aesthetics is worth introducing these other problems. For now I'm going to decline your suggestion, but trying to do something to change the looks of the nozzles is something that I would eventually like to find a solution to.

@linuxgurugamer, thanks for the suggestion. I will certainly consider it. At the moment I'm deeply involved in another project, so it my be a while before I can spend any time on it. If I like the way it looks, and if it doesn't cause any other issues, I'll implement it.

Note that it is possible to alter a planet's temperature to give it seasons by using the curves temperatureAxialSunBiasCurve and temperatureAxialSunMultCurve. However, neither of these curves are used by the stock planets. Simply inclining the orbit by itself won't do anything. You would have to generate the temperature curves to produce the amount of seasonal variation you want, and add the curves to the Kopernicus config. If you want to know what these curves do and how to use them, I recommend the following:

You would have to do something like this: @Kopernicus:AFTER[Koperniucs] { @Body[Kerbin] { @Orbit { inclination = 0 //enter amount of inclination in degrees, where inclination = axial tilt } } } Of course you'll have to adjust the orbits of the other planets as well, or else Kerbin will be out of plane with all of them. You will likely also have to adjust the longitudeOfAscendingNode (LAN) of many of the planets. For instance, suppose you incline Kerbin's orbit 20 degrees. Let's say you want Duna to have a similar inclination of somewhere around 19-21 degrees. If you change Duna's inclination without changing its LAN, Duna's orbit will be tilted by the correct amount, but in an entirely wrong direction. This is because Kerbin LAN equals 0 degrees, and Duna's LAN equals 135.5 degrees. You will have to change Duna's LAN to something close to 0 degrees so that the orbital planes end up relatively close to one another. Also note that inclining Kerbin's axis won't do anything to give it seasons. Kerbin's ambient air temperatures are controlled by the temperature curves in it's atmosphere node. So it doesn't matter how much tilt you give it, you will read the same air temperatures regardless.

All bodies in KSP have axes that are normal to a fixed reference plane. It's possible to incline a body's axis relative to its orbital plane by inclining the orbit (see illustration below). This is how the mod RSS simulates Earth's axial tilt. RSS inclines Earth's orbit 23.5 degrees, thus giving it an apparent axial tilt of 23.5 degrees. However, this technique is very limited. All bodies still have their axes pointed in the same direction. So if all the orbits are inclined similarly, all bodies will have similar axial tilts relative to their orbits. It's impossible to vary the tilts from one body to another. I've heard that KSP may eventually add axial tilt, but I have no idea what the status of that is, or how it will be implemented.

Yes, 30 km is the intended value. The low/high space boundary should always be 1/2 the planet radius. We'll need to fix the KSPedia.

@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.

@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.

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.

That didn't work. I'm still getting the same effect along the planet's limb. Nevermind.

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

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?

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?

Good one, @Snark. Here's my discovery...

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.

@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:

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?

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.

@Mrcarrot, I also recommend using finalizeOrbit = False (unless you are adding to a mod that already uses finalizeOrbit = True, like RSS).

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

@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.

Not as part of GPP directly. However, there may be something coming as on add-on.