OhioBob

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.

That's strange. I've never had mipmaps cause an issue like that. Generally mipmaps are recommended for color maps.

The Grannus system of planets are much closer to the star than either stock or GPP. That's because Grannus is a red dwarf with a habital zone that is less than 1/5th the distance of that around Kerbol and Ciro. So that brought all the planets in closer.

Try DXT1 with mipmaps.

How are you saving your texture, i.e. file type, compression, etc.?

I don't have a screenshot, but I can tell you that when OPM, GPP_Secondary and GEP are all installed together, Ciro orbits the Sun at a distance of 500 to 529 au, and Grannus orbits Ciro at a distance of 88-206 au. Plock's furthest distance from the Sun is 50 au, so there plenty of room for eveything to fit.

I'm not seeing anything obviously wrong in the configs. I'd like to test something, however. What happens if you try to place another Jool in Ignis' place? That is, let Ignis inherit all the settings from Jool except for name and location. If that works, then maybe we can start to narrow on what the problem might be. Try temporarily replacing your Ignis config with the following, and then report what happens: By the way, we really shouldn't be having this discussion here in the Kopernicus thread. These are issues with your mod that we are talking about and not issues with Kopernicus itself. You should either start your own mod thread, or report back to me in a private message.

OK, I misunderstood. I think what you describe would be OK. Writing your own configs or patches to JNSQ I don't think would violate the license. (A highly edited scatterer config is really just a new scatterer config.)

While it's true I've taken over most things related to JNSQ in Galileo's absence, I'm afraid giving premission to use one of the textures is something I'm not comfortable doing. The textures where all made by Galileo and I think only he can give premission to use them. It's not up to me. If your patch must have JNSQ installed to work, why must you repackage any of the textures? You should be able to use the texture by setting the path in your mod to look to where the texture resides in JNSQ.

That works, or I think you can also add removeAtmosphere = True to the template.

I see a couple issues. First, your fades aren't correct. ScaledVersion should be fully faded in before PQS starts to fade out. Assuming your PQS fadeStart/End are correct, then I suggest you use something like this: You can tweak those numbers, but you want ScaledVersion/fadeEnd to be equal to or less than PQS/fadeStart. The second issue is you are using PQS materialType = AtmosphericExtra. That is ancient and is never really used anymore. And I don't think the textures in CTTP are compatible with it. The new shader that is pretty much used universally now is AtmosphericTriplanarZoomRotation. You should make that switch. Also, the Material subnode is going to have to change a bit because the one you are using doesn't appear to be completely compatible with AtmosphericTriplanarZoomRotation. The following is an example of a Material subnode that you can use as a template - it is from stock Moho. You can probably replace the textures with the ones from CTTP that you selected. You can also tweak whatever other numbers need adjusting to suit your needs. I really don't think the low and high textures even work. At least they have never worked for me. I always just used the midTex, which then gets applied to the entire planet. The mid is also the only one that uses a bump map, which I've never understood. If you can't get lowTex and highTex to work, then just omit them. There could be other issues with your config that I didn't see. I stopped looking when I got to AtmosphericExtra. Hopefully the rest of it is good. EDIT I just noticed something else - your planet has no template. It is recommended that you always use a template. A template just uses a stock planet as a starting place, then you change whatever needs changing rather than starting from scratch. This assures that there is nothing critical omitted from your config because you didn't know or forgot to include it. Your planet just inherits the missing item from the template. Since your planet includes an ocean, I suggest using Laythe as the template. Just add the following:

Just double everything in the regular JNSQ dV map. That's not exactly right. JNSQ presumes 10x is real life scale, and JNSQ is built to 1/4th real scale. So everything should really by multiplied by a factor of SQRT(4) = 2. While that should be exact for stuff like interplanetary trajectories, the launch numbers will typically be a little less than double the dV map. That's because not everything about launch is scaled up to 4 times the size. For example, we are generally not launcing into orbits that are 4 times higher.

You can always install the latest version of Scatterer while deleting the following file: GameDate/GEP/GEP_Scatterer/Scatterer_PlanetList.cfg That way all the parts of GEP that are incompatible with the new scatterer will be disabled. You'll get the latest scatterer effects on all the celestial bodies that are configured to use them, while GEP will default to stock atmospheres.

I still haen't figured out the newer versions of Scatterer. It's probably easy enough to learn but I just haven't been motivated to do so. Updating scatterer is really the one thing left to do that is keeping me from releasing a JNSQ update. If somebody comes up with some configs that look good and are bug-free, I'd be happy to incorporate them into JNSQ and make a release. I didn't know EVE required any updates, but if so, I can incoporate it as well. (I do know about volumetric clouds, but I wasn't planning on doing anything with that.)

Did you also install the dependencies -- 000_Harmony, ModularFlightIntegrator, and ModuleManager?

You can resize the solar system using Sigma Dimensions. At least I think it still works. It's been a long time since I last used it. There's also JNSQ, though it's not just a simple resizing. While JNSQ includes all the stock celestial bodies, it completely remakes them with new textures and terrain. It also adds some new bodies. JNSQ is technically suppose to be 1/4 real scale, which works out to be about 2.7x stock scale.

CTTP Community Terrain Texture Pack DART D.A.R.T. (Double Asteroid Redirection Test) Range Challenge GEP Grannus Expansion Pack JNSQ JNSQ (Je Ne Sais Quio) Planet Pack KSRSS Kerbal Size Real Solar System SVE Stock Visual Enhancements SVT Stock Visual Terrain SVT is obsolete but it technically still exists and is available to download.

Not in the current version. It will be removed, however, if and when I ever get around to releasing an update.

That's controlled by a Kopernicus setting... By default it is set to True. The default setting works best for JNSQ because JNSQ has custom asteroids. But that means you get no comets. To get comets you need to switch to Stock, but then you won't get the customized JNSQ asteroids.

You should probably report it to MPE. Let the MPE devs figure out whether it's their mod or Kopernicus.

Just do the following, adding in extra @Body nodes for each additional body that you want to modify. If there is some orbital element that you don't want to change, then just omit it. When completed, save it as a plain text file but with a .cfg extension (you can name it anything). Then place the saved .cfg file anywhere inside the GameData folder of your KSP installation. @Kopernicus { @Body[Moho] { @Orbit { inclination = new value eccentricity = new value semiMajorAxis = new value longitudeOfAscendingNode = new value argumentOfPeriapsis = new value meanAnomalyAtEpoch = new value epoch = new value } } @Body[Eve] { @Orbit { inclination = new value eccentricity = new value semiMajorAxis = new value longitudeOfAscendingNode = new value argumentOfPeriapsis = new value meanAnomalyAtEpoch = new value epoch = new value } } }