OhioBob

It has always done that for me. Not a bug as far as I know, just the way it works.

That's because JNSQ is configured to use EVE eclipses for non-atmospheric bodies, and for atmospheric bodies when scatterer is not present. When scatterer is present, atmospheric bodies use scatterer eclipses, while non-atmospheric bodies continue to use EVE eclipses. If scatterer eclipses are not working, then it is likely either an issue with scatterer, or there has been some change in scatterer that JNSQ is not presently updated for.

It's not random, there's a setting for it. Two settings, actually... navballSwitchRadiusMult and navballSwitchRadiusMultLow. The first sets when the NavBall switches when ascending, and the second when descending. The units are in planet radii. Urlum does not include these settings in its config, but since it uses a Jool template, it inherits Jool's settings. These settings are, navballSwitchRadiusMult = 0.06 and navballSwitchRadiusMultLow = 0.055. (In fact, all the stock celestial bodies use these same settings.) Since Urlum has a radius if 2177000 meters, the NavBall switches when ascending at an altitude of 2177000 * 0.06 = 130620 meters. If you want the switch to take place at some other altitude, you need to give Urlum a custom setting rather than use the default. For instance, say you want the switch to take place at the top of the atmosphere. The height of Urlum's atmosphere is 325000 meters, so in this case you want to set navballSwitchRadiusMult = 325000 / 2177000 = 0.149288. The following patch should do it: @Kopernicus:AFTER[OPM] { @Body[Urlum] { @Properties { navballSwitchRadiusMult = 0.149288 { } } If you want to change other bodies, you'd need to apply a similar patch. P.S. I don't know how to make it not switch at all (forcing you to do so manually).

It's because new planets are added. The distance between planets out to Jool is increased 2.75 times, but because Lindor is added, the distance to Eeloo is increased more the 5 times. And Hamek is nearly 6 times farther away than stock Eeloo. We figured a 4x increase in antenna/DSN range is just barely enough to maintain a very weak connection between Kerbin and Hamek with a single 88-88 antenna. Reaching Nara, however, will require either multiple antennas or an antenna mod such as the JX2.

Yes, as long as you use the latest version of Kopernicus.

My intent was to make it 8 hours, but you're right, it's 4 hours in the config. I need to change that. If you want to make it 8 hours for your Eeloo episode, go ahead and change it.

You should ask your question in the Ad Astra thread. Your problem has nothing to do with JNSQ, and the JNSQ team has nothing to do with Ad Astra.

Just use a stock-scale delta-v map and multiply the values by SQRT(Rescale Factor). For instance, if you are playing at 10x, then multiply the delta-v by SQRT(10) = 3.16.

That's correct. Deleting the file will revert the Stomper from being hidden, but it won't be modified. It will have its same specs from MissingHistory.

If you want the Stomper back, delete the this file... GameData/BetterSRBs/Configs/MissingHistory.cfg I hide it because I didn't want it, and I made this mod to suit my own personal needs and desires.

Yes, though with changes. For instance, Minmus' orbit is moved inside the orbit of Mun. This and other changes are necessary to assure orbit stability. JNSQ detects Principia and makes the changes automatically. The Kronometer packaged with JNSQ is outdated and doesn't work. Also the latest version of Kronmeter (v1.11.0-1) doesn't work with KSP v1.12. You'll have to wait for Kronometer to update. In the meantime, you should delete the JNSQ/JNSQ_Plugins/Kronometer folder.

Plans, no, dreams, perhaps. There are always things we'd like to improve on, but real life and other projects seem to have taken us away from the desire to do any further development at the moment. We might return to it at some point but I make no promises.

You should change reorientFinalAngle to 30.11 degrees, or else the runway won't be aligned east-west. The offsets should probably work as is, but the map decal may not blend in nicely with the surrounding terrain. If you find you need to raise or lower it for aesthetic reasons, just try changing absoluteOffset and repositionRadiusOffset by the same amount.

If you want to relocate KSC, try the following patch. The numbers given are for the current position, just change them to your new position. The map decal is the flattened area around the space center. You will need to relocate both the map decal and the space center.

It should work fine as long as you use the correct version of Kopernicus.

No changes. We're still on v0.9.0 that was released in February 2020.

I think that's correct, you should use "UseKopernicusAsteroidSystem = Stock". As I understand it, true uses the Kopernicus asteroid spawner, false uses no spawner, and Stock uses the stock spawner.

There are belts of heat around Thalia, you must have been unlucky and just happened to park your craft right in the middle of the one of the hottest zones. Changing altitude can lessen the heating effect. There's also excess heat on the surface, but how severe depends on where you are. Icarus isn't completely safe either.

I use B9PartSwitch for my mods BetterSRBs and EveOptimizedEngines and I haven't had a problem with either one in KSP 1.12.1. Everything seems to be functioning normally, at least for what I'm using it for.

The best thing you can do typically is just try a mod to see if it works. Often you'll find they work fine, but sometimes not. It just depends on the mod.

I think that depends on how much PQS mods are used. If the terrain is driven solely by the height map, then larger is probably better. However, for some planet makers it is common for the height map to just provide basic height information. The real terrain detail is added using PQS mods. In that case there is really no need for a high resolution height map.

UPDATE Version 1.2.6 Changelog Deleted texture variants for S2 SRB-KD50 "Lance". See opening post for download link and instructions.

Thanks for bringing this to my attention. I wasn't aware that part even had variants. I'll fix it and release an update.

The current version of Transfer Window Planner works with KSP versions newer than 1.7. I've used it all the way up to at least KSP 1.11. Just because the mod hasn't been updated doesn't mean it won't work. Mod authors often don't bother updating when there's no need to. There's also an online version that you can use: KSP Launch Window Planner by alexmoon

UPDATE Version 1.2.5 Changelog Revised for KSP v1.12.1. See opening post for download link and instructions.