OhioBob

It loads using release 4.

Something is very wrong. My planet pack (GEP) won't load with 1.9.1-6. Loads fine with 1.9.1-5. Apparently some issue with the gas giant planet Sirona...

UPDATE Galileo's Planet Pack v1.6.4.2 Requires GPP_TEXTURES 4.2.1 KSP 1.8.1 or newer Changelog Reverted some PQS changes that weren't suppose to be in 1.6.4.* This reverts the terrain of Icarus and Thalia to what it was in v1.6.3.1 to match the v4.2.1 textures.

Perhaps in a future update, but I currently have no plans for that. I might consider it once Kopernicus is out of beta, but certainly not before then.

Yes, Sigma TweakChutes was written specifically to fix this issue. Of course TweakChutes didn't exist at the time I wrote that. TweakChutes is bundled with GPP starting with version 1.6.4.0 (also with GEP and JNSQ).

@R-T-B, I just tested GEP with release 3 and the temperatures are now working correctly.

UPDATE Galileo's Planet Pack v1.6.4.1 Requires GPP_TEXTURES 4.2.1 KSP 1.8.1 or newer Changelog Updated bundled KSC++ assets. Fixed PQS color map name in Icarus.cfg. Added support for Minor Planets Expansion.

That's not really a Kopernicus issue. It's a problem with one of the planet packs using Kopernicus. You should figure out which one of the planet mods is causing the problem and then report the issue to that mod author. It looks like there's a problem with the celestial body Cellus. I'd start there, though I don't know which planet pack adds that body.

I wouldn't uninstall Kopernicus. I'd uninstall everything else. If that fixes it, reinstall the other mods incrementally until you figure out which one is causing the problem.

You're right, it is a Kopernicus issue. I removed HeatShifter and the planet temperatures are still aligned with the Sun (though with the 45 degree offset that stock KSP adds, and that HeatShifter removes). We'll have to make a Kopernicus bug report.

HeatShifter is bundled with GEP. It's in the GEP_Plugins folder.

Yep, you're right. I don't think the problem is Kopernicus, however. I believe it's Sigma HeatShifter. Apparently I only ever tested HeatShifter in GEP_Primary mode, in which case it works correctly. When GEP is secondary, the temperatures align to the Sun. It's this way in 1.8.1 as well. The problem has likely always existed and I just never noticed it. Thanks for bringing it to my attention. I'll ask @Sigma88 to look into it. (edit) The problem is apparently in Kopernicus, not HeatShifter. Please read ahead.

I've never experienced the bug in latitude, but I definitely have in longitude.

Using -1 to 2 is just to provide some overlap to assure there aren't any seams. -1 to 2 is effectively the same as 0 to 1. (Same thing with starting altitudeRange at -1 instead of 0.) When the full range of longitude is used like that, the bug doesn't occur. For instance, you'll find icebergs at all longitudes all the way around the planet. If you want an example from JNSQ that produces the bug, look at the Desert land class. Here longitudeRange starts at 0.59 and ends at 1. If you were to explore this area, you'd see cacti from longitudes of 0.59 to 0.75 (122.4 W to 180 W), but then they abruptly stop and there are none from 0.75 to 1 (180 E to 90 E). At least that's the way it was when I last tested it, which was probably a year ago. I haven't tested it recently, but based on my conversations with Sigma88, I doubt anything has changed. Sigma indicated to me that he observed the same bug and wasn't able to fix it. (Edit) I just tested it in KSP 1.9.1 and the bug definitely still exists. In the image below we're looking due north along the 180-degree line of longitude (0.75). I've turned on createColors to show the land classes, and I increased the scatter density. The pink is the Desert land class. According to the settings in the config, the Desert land class should extend from longitude 0.59 to 1, so the pink should extend all the way across the screenshot. But we can see that it ends at 0.75. We can also see many cacti to the right in the pink area (<0.75 longitude). There are a few cacti to the left, but that's probably just due to randomness in their placement (they disappear completely as we move farther to the left).

@R-T-B, while you're looking into it, there's also a bug in the longitude range when placing scatters. @Sigma88 struggled with it and said he thought it was a stock bug, so maybe there's nothing that can be done about it. Perhaps he can explain more about it. But if it can be fixed, it would be welcomed. Here's the bug, as I remember it... The longitude range is from 0 to 1, with 0 being the left edge of the texture maps, and 1 being the right edge of the texture maps. When we use the entire range of longitude (0 to 1), scatters place OK. But when we limit the range to some less than the full range of longitude, nothing places in the fourth quadrant of the map, i.e. from 0.75 to 1. For example, let's say I define a land class that has a longitude range of 0.6 to 0.9. Scatters will place OK between 0.6 and 0.75, but no scatters will place between 0.75 and 0.9.

@R-T-B, if you want something to put on your todo list, here's an idea that I'm sure would be very welcomed by the planet modding community... allow the placement of terrain scatters by biome. At present terrain scatters are placed using LandControl, in which landClasses are created for the placement of specific types of scatters. LandClasses are defined by latitude, longtitude and altitude ranges. While it would be good to keep those ranges, an additional biome parameter would be awesome. I've seen many inquiries about this, so I'm sure modders would be thrilled to have that optional available.

I had the same problem, Windows Explorer wouldn't open it. I had to download the master to get it to work. Click on "Source code (zip)" and it will download the master with all seven rescale configs.

Sigma Dimensions. To play JNSQ at real scale will require a 4x resize/rescale. As far as I know, no one has published a 4x config, so you'll have to make your own.

It ought to work. I'm not expecting that we'll need to release an update. If you find any issues, please report them.

I think that's an issue that Kopernicus is working on.

Yep, Kerbin's shallow flat bottom oceans seem a bit unnatural. If we wanted Kerbin's tallest peak to be equal to Mt. Everest, then we'd need a landscape multiplier of about 0.13. Mars is also a bit of an outlier with its large deformity. This is of course due to the enormity of Olympus Mons, which is quite an unusual feature. There may be exceptions, but overall it looks to me that a landscape multiplier of 0.25 seems about right for a 10+ resize. That makes the deformity of the stock bodies in the range of that of real life bodies. But just going by hard numbers may not necessarily be the best answer. It may be better to go with something that looks and feels right regardless of what the numbers say.

Yes, it's in the GPP download.

The topographic range of the Earth, Moon and Mars are about 19.8 km, 20 km, and 29.4 km respectively. For comparison, stock Kerbin, Mun and Duna have topographic ranges of 8162 m, 7313 m, and 8145 m respectively. So if we wanted these stock bodies to have deformities comparable to their real-life analogs when scaled up to 10.618x, then we would have to give them landscape multipliers of about 0.23, 0.26 and 0.34. Or an average of about 0.275.

If you have any interest in providing compatibility with Realistic Atmospheres, I can give you some recommendations.

@Profiremu23, I have a suggestion. For atmosphere rescaling, use atmoTopLayer instead of Atmosphere. For instance, for 2.5x Kerbin, change your settings to, Atmosphere = 1 atmoTopLayer = 1.214285714285714 The exception would be for the 10x and 10.618x, in which case I recommend the following for Kerbin, Atmosphere = 1.25 atmoTopLayer = 1.6 Note that the product of those two numbers is, 1.25*1.6 = 2, which is the same multiplier that you're currently using. Below is the detailed explanation for this: