OhioBob

@Cruesoe, to fix this you have to use the variable Dm instead of D in your DisplayDate config (also Dmth instead of Dth). D is the day of the year while Dm is the day of the month. I'm also planning to release JNSQ v0.10 at some point in the not too distant future. When that happens the intialRotation and offsetTime changes will be incorporated into JNSQ. You'll therefore need to delete this from JNSQRealDate when v0.10 drops.

Did you install GEP_Rescale? GEP is built to a different scale than JNSQ, so it's designed to work with JNSQ only if you resize it using the optional mod GEP_Rescale, which comes packaged with GEP. In addition to resizing GEP, GEP_Rescale also fixes some things that JNSQ breaks, including the scatterer atmospheres.

The current JNSQ version was never designed to work with other planet packs. However, GEP does include an optional addon that is suppose to make it compatible with JNSQ. The responsibility for making to two work together is on GEP, not JNSQ. If something doesn't work it should be reported there. That being said, I've never observed any issue with scatterer atmospheres when GEP and JNSQ have been installed together. Not sure what the problem is. There has been no effort to make GPP work with JNSQ, so there is no support available for that.

I'm just waiting to see how Gordon gets off Nara. Curious to see if his hydrogen-breathing engines factor into the equation.

From the OP...

Yes, but I don't remember what caused it. I'm thinking it might have been a scatterer related issue, but I'm not sure about that. I recommend that you start uninstalling mods and try to figure out what's causing it that way.

There's no firm target date for an update, but I hoping it will be sometime in the next couple weeks.

At this point I'm planning to remove Kronometer from JNSQ and instead list it as a recommended mod. The user will have to download and install Kronometer separately.

There are no Parallax configs written for GPP, so there's no point having it installed. Would be best to uninstall it. We hope to make GPP Parallax compatible as some point in the future, but there's no schedule for making that happen.

Most of the changes have already been pushed to GitHub. But to be honest, I really don't know what it all includes. I'm going to have to look over 19 months worth of commits to figure out what's been done and get it all into a changelog. Along the way I might discover it's not release ready and requires more changes.

There won't be anything silent about it. It will be a pretty significant upgrade with 1-1/2 years worth of changes that have never been released. It's about time we get JNSQ up to date. There will be an announcement about it here with a lengthy changelog. If there is anything about it that has the potential to break existing saves, we'll issue warnings. (It probably won't be version 0.9.0.1 as the updates are more significant than that minor version number change suggests.)

I'm considering doing that. That's correct, it's the ribbons for the celestial bodies added by JNSQ. The Final Frontier mod includes the ribbons for the stock bodies.

It should work in either, but since you're installing it separately, it probably makes more sense just to put it directly in GameData. We're likely going to delete it from JNSQ in the future, so a separate install is probably going to be the way forward.

I don't really pay much attention to pitch vs. altitude. My rule of thumb is to hold the "time to apoapsis" at about 50 seconds. If it starts to fall below 50 s, pitch up a little bit, and if it starts to climb above 50 s, pitch down a little. And if it starts to run away to where I can't control it with pitch alone, throttle back. Only during the final moments of ascent does the time to apoapsis start to rise well above 50 s.

I calculate that for a modifier of 0.9, a radio signal can be received at a station up to about 30-35 degrees beyond the visible horizon. The angle varies depending on the spacecraft altitude and the size of the celestial body, but 30-35° is about right for most low orbits extending from the top of the atmosphere to several hundred kilometers in height. Does that sound reasonable? For a modifier of 0.8 the angle increases to about 45-55° beyond the horizon. That looks like a Trajectories error. Not sure why you're posting it in JNSQ.

There are separate occlusion modifiers for atmospheric and non-atmospheric bodies, so it's possible to do what you suggest -- set it to 1 for non-atmospheric and, say, something like 0.8-0.9 for atmospheric (I don't know what would be realistic). Of course even with the modifier set to 1, a signal could still pass through mountains. It's my understanding that for occlusion the body is considered a sphere with a radius equal the body's specified radius times the occlusion modifier. So terrain features aren't considered, which is a reasonable simplification. Of course it gets weird for a small irregularly shaped body, like Gilly or Bop. An irregular body might be a situation where we'd want to set the modifier >1 (say close to the mean radius), but it's not configurable by body.

If you are playing KSP 12.x, then the Kronometer packaged with JNSQ is outdated. Delete the folder JNSQ/JNSQ_Plugins/Kronometer, then download and install this version of Kronometer: Release 1.12.0 · linuxgurugamer/Kronometer · GitHub

Yes, but just not JNSQ, it can happen for all celestial bodies. How much the signal passes through a body depends on the game difficulty. You can change it by adjusting the "Occlusion modifier" slider in the game difficulty settings. As I understand it, a modifier of 1 means that the body will occlude any signal where the line-of-sight passes below sea level. Modifiers less than 1 will allow signals to pass through the the outer edges of the body. While modifiers greater than 1 can occlude signals even if the line-of-sight clears the edge of the body.

No. Ad Astra is made specifically for JNSQ and won't work with anything else. I don't think there are any third-party mods that will replace GPP's terrain.

Yes

JNSQ should work fine. The only issue is that the version of Kronometer that's package with JNSQ doesn't work in KSP 1.12.1. If you decide to use it, you'll need to delete Kronometer from the JNSQ/JNSQ_Plugins folder. Then download and install this version in its place: https://github.com/Kopernicus/Kronometer/files/6717738/Kronometer-1.12.zip Rescale probably also still works even though the forum page says it's only good to 1.9. Grannus Expansion Pack (GEP) also comes with a config that rescales it to 2.5x. To use it you need to install GEP along with the optional mods GEP_Primary and GEP_Rescale (both included in the GEP download).

You might have to redo your game settings. Go into your KSP folder and delete the file settings.cfg and restart KSP. (Restarting will create a new settings.cfg.) When the game restarts, go into Settings and reselect all your settings. For Terrain Detail I recommend using JNSQ_High. The elevation of KSC was designed around the JNSQ_High settings, so other terrain settings could result in KSP floating. Note that the JNSQ specific terrain settings are selectable only when a new setting.cfg file is created. You can't select or change them later. That's why you must delete and recreate settings.cfg.

You'll just get the regular stock calendar, i.e. 6-hours days, 426 days per year.

Your guess is as good as mine.

Thatmo has an inclination of 161.1 degrees, which means it should be orbiting retrograde. However its rotation is likely messed up. @Poodmund, I see that Thatmo is set to be tidally locked, but my experience is that tidal locking doesn't work correctly when a body is orbiting retrograde. (As I recall, tidal locking gives the body the correct rotation period, but it rotates prograde instead of retrograde.) To properly tidally lock a retrograde orbiting body, we have to set tidallyLocked to false, and set rotationPeriod to the manually computed rotation period using a negative value. For Thatmo, I think the following should work: tidallyLocked = False rotationPeriod = -306390.347