OhioBob

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.

I believe that's true. I haven't tested it with volumetric clouds or Parallax specifically, but I don't see why things couldn't co-exist and work perfectly fine.

As long as it's your own original work and doesn't violate the JNSQ license, then you really don't need permission.

I don't know what the latest versions of scatterer looks like, I've never played past 0.772. When I say I don't want to change JNSQ in any appreciable way, I mean I don't want to do stuff like change sky color. If the new scatterer can make the atmospheres look more realistic while retaining the same basic characteristics of the old atmospheres, then that's certainly something I'd like to do.

@zakkpaz, @MOPC You guys are certainly free to make your own configs to change JNSQ anyway you want to. You're obviously trying to bring your own vision to life, and I can appreciate that. However, for anything that I may want to consider incorporating into JNSQ in a future release, it must remain true to JNSQ's original vision. For instance, updated scatterer configs should just make JNSQ compatible with the current version without really changing JNSQ in any appreciable way. Same with volumetirc clouds - JNSQ should keep its current clouds as much as possible, they should just become, well, volumetric. I'm not implying it's your plan to have your work incorporated into JNSQ. For your own personal use, or as a independent release, do whatever you want, provided it doesn't violate the JNSQ license. But if it is your goal to create something that may be added to JNSQ in the future, you know now what will be considered acceptable and what won't.

Updating has been on my wish list for a couple years now. I've actually completed most of it but then just hit a wall and lost motivation. Hopefully I'll complete it someday sooner rather than later. I have no plan, however, to do either volumetric clouds or parallax. If I'm not motivated to finish what I already know what to do, I'm certainly not motivated to figure out something new. I'm going to count on third parties to come up with their own patches for that stuff, which they can share on their own, or perhaps I might be willing to incorporate into the mod as a pull request.