OhioBob

I don't recall any.

The ScaledVersion fades are the range over which the ScaledVersion texture fades in, the the PQS fades are the range over which the PQS fades out. Since the PQS renders over the top of the ScaledVersion, the idea is that we want the ScaledVersion to be fully fading in before we start to fade out the PQS. The fades for the stock planets are inconsistent, but many do it just as I described. For instance, Laythe uses: ScaledVersion/fadeStart = 55000 ScaledVersion/fadeEnd = 60000 PQS/fadeStart = 60000 PQS/fadeEnd = 120000 PQS/deactivateAltitude = 160000 As for Parallax, JNSQ wasn't designed for it, so no consideration was made for Parallax when setting the fade altitudes. I don't know anything about Parallax, but it seems like a poor design if it looks bad when used with a planet pack that sets its fades in the way that virtually everyone that makes planet packs is taught to do it.

That may be what the Kopernicus wiki says, but I know of no one that does that. In fact, that goes against the recommendation that is used universally throughout the planet modding community. The rule that is followed by pretty much everybody is, ScaledVersion/fadeStart < ScaledVersion/fadeEnd <= PQS/fadeStart < PQS/fadeEnd < PQS/deactivateAltitude

You can get all that information from here: kittopia-dumps/Configs at master · Kopernicus/kittopia-dumps · GitHub The actual geeASL numbers should be the geeASL numbers from your table times 9.81/9.80665. From the Kittopis dumps, this works out to be exact for Kerbin (geeASL = 1.00034160493135). But for the other bodies there's a slight error and I don't know why. For instance, for Moho the Kittopia dump gives the value, geeASL = 0.275093947318621 But the computed value is, geeASL = 0.275 * 9.81/9.80665 = 0.275093941356121 I can't explain the difference, but being off only only 6 parts in a billion I think is close enough.

There are a couple reasons for the small differences. First, those aren't the correct geeASL values. The actual values are weird fractions. For example, Moho's geeASL is actually 0.27509394... not 0.275. The reason for this is because years ago Squad changed the value of 1 standard gee from 9.81 (which was used in the beta versions) to 9.80665 m/s2. Because of this they mulitplied all the original geeASL values by 9.81/9.80665. You're using the original pre-converted geeASL values, so to account for this you either have to change all those to the current numbers, or (much easier) just mulitple the values you have by 9.81 instead of 9.80665. The second thing is the value of the gravitational constant used in KSP is 6.67408E-11 (looks like you're using 6.67384E-11). If you make these two changes you should be exact.

Yes, but not exactly. For that formula to work, gravity must be in m/s2, not gees. So you have to multiply geeASL by 9.80665 to convert.

displayName does work for biomes.

You can probably delete the scatterer sunflare by doing this: @Scatterer_sunflare { !Sun{} } Or whatever the name of the star is if not Sun.

As I recall, you just have to make the sunflare color black. For instance, I think the following would do it for the Sun. @Kopernicus { @Body[Sun] { @ScaledVersion { %Light { %sunLensFlareColor = 0,0,0,0 } } } }

We never did custom science definitions beyond Gael. The other celestial bodies should just have the stock ones. Deleting the comment tags won't help you. The items in the science defs file are being directed to a localization file, but there's nothing in the localization file for items with comment tags. That's why they have comment tags.

UPDATE Version 1.2.7 Changelog Updated internal names for SpaceY-Lifters. See opening post for download link and instructions. Thanks to xlmt4567 for bringing this to my attention.

JNSQ is designed to be able to run with GPP and GEP, but nothing else. Running it with anything else voids the warranty.

I can't understand how that could be happening unless there is some other mod or config messing with it.

@R-T-B, @CashnipLeaf I recall that problem rather vividly, though I'm not familar with the fixes to the code. I don't really remember changes being made to Sigma Dimensions, but I do recall discussions regarding Kopernicus. I was more concerned with Kopernicus at the time and brought these issues to Sigma88, who promptly implemented fixes. Just to provide a little more history, the following describes the situation as it existed several years ago when the changes where made. I can't guarantee things are today as they were then. As I recall, KSP defines 1 atmosphere as being equal to Kerbin's staticPressureASL, which is a setting in Kerbin's config and is normally equal to 101.325 kPa. This comes into play in couple of places, (1) when determining engine ISP and (2) when displaying a planet's atmospheric pressure in the Tracking Station. The first of these is an issue because the curves that look up engine ISP do so using pressure in atmospheres, but those curves are calibrated such that 1 atmosphere = 101.325 kPa. Let's say we change the atmospheric pressure of the home world to 202.65 kPa (i.e. staticPressureASL = 202.65). As far as KSP is concerned, 1 atmosphere now equals 202.65 kPa, but the ISP curves are not recalibrated accordingly. So if a rocket engine is operating in a condition where the ambient pressure is 101.325 kPa, KSP is going to compute this as 101.325/202.65 = 0.5 atm and look up the ISP for that pressure. But the ISP curves are calibrated so that 101.325 kPa is 1 atm, not 0.5 atm, therefore we'll get an ISP that's too high for the condition. The second issue is as Sigma has already described. Without any fix, the Tracking Station will always display Kerbin's atmospheric pressure as 1 atmosphere regardless of what the value is in kPa, and other planets' pressure will be relative to this. In stock KSP Kerbin's pressure is displayed as 1 atm and Eve's pressure is 5 atm. But if we change Kerbin's staticPressureASL to 202.65, then Kerbin's pressure would be displayed as 1 atm and Eve's as 2.5 atm, which is confusing. The fixes implemented where intended to always define 1 atmosphere as 101.325 kPa. This would fix the engine ISP problem and assure that the Tracking Station always displays atmospheric pressures in the familiar "earth standard atmospheres", rather than having the definition change from planet pack to planet pack.

You can certainly give it clouds if you want to, but I want to explain why the JNSQ design team didn't give it clouds. It's just too cold to have clouds. Anything that would form clouds has frozen out of the atmosphere. The only thing left is hydrogen and helium.