OhioBob

I see in your video that you make some comments about the Mohole at Krel's north pole. I've done some further investigation into this and I've concluded that it is not because Krel uses a Moho template. It is the result of a stock bug that was the cause of the Mohole on Moho in the first place. KSP doesn't like heightmaps that have differences in ground elevation between the north and south poles. The south pole will appear normal, but if the north pole has a different elevation than the south, KSP will force the north pole to match the elevation of the south by creating either a pit or a spike exactly at the north pole. Krel just happens to have a pit, but if you visit the north poles of other bodies, you might find a spike. We typically try to fix this issues by adjusting the heightmaps so there's little or no difference in elevation between the poles, but in some cases, like Krel, it may have gotten overlooked. I am curious about one thing, however. Did your scans show the Mohole anomaly at the north pole? If so, that could still be a problem that we need to look into. While I believe the physical feature that you found at the pole was the result of a known bug, the identification of it as an anomaly could be a carryover from the template. (edit) I just re-watched your video and you clearly say the north pole showed up as an anomaly in your scans. I need to investigate this further to see if there's a way to eliminate that.

delete - accidental post.

That stinks. So frustrating when that happens.

https://www.dropbox.com/s/gcuxvxdnp8yz3cg/JNSQ_PlanetData.zip?dl=0

@Gordon Fecyk, those are certainly some unusual problems that you describe. As you said, JNSQ does not yet officially support 1.10.1. I'm just not yet ready to start debugging problems that may not be directly related to JNSQ, but rather to Kopernicus or some other dependency. That being said, regarding the cache issue, I don't see why deleting he cache should cause any problems with JNSQ. Deleting the cache (.bin files) only forces Kopernicus to rebuild them the next time KSP/JNSQ is launched. You should be able to delete and rebuild them as often as you want; they are just there to save time at startup. I've never known it to be necessary to delete the cache when upgrading Kopernicus, but it doesn't hurt to do so. Changes to JNSQ could require new cache files, but we typically update those when a new JNSQ version is released. Typically anything that changes the size or shape of a celestial body requires updating the cache.

A few but not many.

I don't use Principia other than to test the compatibility of my planet packs with it, but that sounds like a reasonable theory. I can easily see where Principia might not like adding planets to an existing save. If that's the case, there's probably nothing you can do to make your old save work with OPM added.

@AccidentalColonies, did the original save that you are trying to load use Principia? I don't think Principia can be added to an existing save, you always have to start over with a new game after installing Principia.

I don't use CKAN so I can't help you with that. You should be able go into your GameData folder and delete the scatterer folders manually.

@Drupegod02, I suggest you delete these: Environmental Visual Enhancements - Stock Planet Config files (EnvironmentalVisualEnhancements-HR 2:EVE-1.2.2-1) Scatterer Default Config (Scatterer-config 3:v0.0632) Scatterer Sunflare (Scatterer-sunflare 3:v0.0632) GPP and GEP comes with all its own configs. Adding the default configs for those mods are likely messing things up.

They are suppose to be faint. Most mod authors give their planets bright Saturn-like rings. To be different, we wanted to give Lindor faint Uranus-like rings. I don't know how to brighten them. I have no experience with FAR, so I haven't the slightest idea.

Several planets should have clouds - Gael, Tellumo, Gratian, Catullus, Hadrian, Nodens and Epona. Sounds like you likely have a mod conflict. It could be GU, though I don't know much about it. Your best bet is to remove mods until you find the one causing the problem.

I suggest this... 1. Find the file GameData/GEP_Primary/Nodens.cfg 2. Open the file and scroll to the bottom to where you see this: 3. Increase the setting repositionRadiusOffset until the runway is no longer buried.

Not at this time.

If the rocket is tipping too steeply too soon, there are three things that I typically do to fix it: Increase Start m/s Decrease Turn Angle Increase Hold AP Start Time Which items you change and by how much is pretty much trial and error.

It should be. Everything was stable the last time I tested it. In addition to Minmus moving, Bop's orbit becomes retrograde.

Not recommended. The new stock terrain shader that began being phased in with KSP v1.8 far surpasses what this mod was able to do. This mod is a big improvement when applied to pre-1.8 versions of KSP, but for 1.10.1 you'll have better looking terrain if you just stick with plain stock. That's not to say this mod won't eventually be updated, but for now it's mostly obsolete. FYI, I think there's something coming in the future that will be way better than anything we've seen yet. It appears the creator of Parallax is working on a stock planet terrain upgrade. The preview screenshots look fantastic.

Mechjeb2 should work with GPP. I don't use MechJeb myself, but I'm pretty sure it was tested with GPP a long time ago. I don't know if anything has changed since then.

As mentioned, JNSQ packages it's own visual configs; SVE and SVT would only mess things up. And even if you were playing plain stock, SVT is pretty much obsolete now and has been surpassed by the new stock terrain shader introduced beginning with KSP 1.8. The only planet pack I know of that provides JNSQ compatibility is Grannus Expansion Pack. The problem with other planet packs is that they're not built to the correct scale to integrate with JNSQ. Regular GEP is not to the correct scale either, but it comes with an optional mod (GEP_JNSQ) that rescales it to fit.

[snip] Is there a question here? If you're asking if there's a version of Kopernicus for 1.10.1, then yes. It's experimental, however.

Still needed.

Thanks for bringing this to my attention. I'll have to take a closer look at the intensity curves - there may be other scenarios where adjustment is needed. Thanks for the offer to share the curve, but since I need to review all the different installation options, it will probably be best to just redo it all myself.

@Me.hasOwnProperty isHappy, it's impossible to have two surfaces one on top of the other. So in your scenario, it's possible to have a deep crack or canyon with a lake at the bottom, but the lake must have open sky above it. It can't extend underneath a rock overhand for instance.

Stock + OPM + MPE + GEP (secondary) should work fine. If left unmodified, Soden's orbit would take it beyond the orbit of Grannus (possibly crossing into Grannus' SOI eventually). I left Soden's periapsis unchanged but significantly lowered its apoapsis. Grannus' orbit is also changed when MPE is installed. The orbit of Grannus was originally designed to accommodate OPM and GPP, not MPE. With MPE installed, Grannus is moved to more than twice its original distance to accommodate the large orbits of the outer minor bodies. Soden's was so extreme, however, I changed it to accommodate Grannus.

The OPM and GEP Tracking Stations are identical. There is coordination between the mods to assure it gets added once and only once. It depends on how you have the mods installed. I'm assuming you have the stock solar system with OPM added, and GEP installed as a secondary star system. Is that correct? In that case the OPM orbits are not modified at all. The only MPE body to have its orbit changed is Soden. If you have some other installation, such as GEP_Primary, then there could be many orbit changes. GEP works with SVE (assuming, of course, that you have the stock planets as part of your installation). I don't know about Spectra and AVP.