OhioBob

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.

I'm aware that that can happen but I have no idea how to fix it. I just ignore those contracts.

It's been a long time since I last used this mod, but yes, they should. According to the configs, they should appear in the tech tree under "Large Probes".

That's almost certainly because JNSQ uses the same internal planet names as the stock planets. So if Blackrack has a config for stock Eve, for instance, then JNSQ's Eve is going to receive that same treatment. But Blackrack's configs are not designed specifically for the JNSQ versions of those planets, so they may not look right in some cases. And the bodies added by JNSQ probably aren't going to have any scatterer effects at all. The two mods really aren't made to work together, so if you run into problems there is likely no fix and you are unlikely to get any support. Officially, JNSQ is made for scatterer 0.0772.

It appears that the color assigned to Voronoi Craters in the config doesn't match the color that's on the biome map. Eventually I'll get around to releasing an update. But in the meantime you can fix it yourself but opening the file Moho.cfg and changing the color to that shown below: Biome { name = VoronoiCraters displayName = #LOC_JNSQ_Biome_VoronoiCraters value = 1 color = #604363 } JNSQ has not been updated to use any of the v0.08x versions of scatterer. If you are using an unpatched version of JNSQ, you should use Scatterer 0.0772. However, I believe there are some third-party patches out there that update JNSQ to work with newer versions.

AVP is made to work with stock KSP, not GPP. If you want to use GPP, don't install AVP.

That's typically only an issue if you press the ESC key. If you close it properly you can reopen it without having to restart the game.

If it is for your own personal use, then you can pretty much do what ever you want. If you plan to share or distribute your changes in any way, then what you did would violate the license. The license prohibits you from editing any part of JNSQ and then redistributing it.

Yeah, that's a common bug whenever a star's atmosphere is edited. For some reason I decided to leave Grannus' atmosphere in there despite the bug. Don't know why I did that. You did the right thing to get rid of it. Or you could just delete the atmosphere entirely. I commented it out in GPP so I could at least see what the atmosphere was intended to be even though I couldn't actually implement it. Grannus actually has two asteroid belts - an inner and an outer. I haven't verified but, by looking at the configs, I see nothing that should stop them from spawing if GPP_Secondary is installed.

The current version works with 1.12.1 through 1.12.5.

When launching you can select from any of the alternate launch sites, but there's no built in ability (that I know of) to change the location of KSC. If you really want to change the KSC location, you'll have to do it yourself by selecting a new location and writing a patch that relocates KSC and its map decal.

I don't think GPP is configured to use KSCSwitcher.