OhioBob

I've done some further studying of this situation. While I agree with your numbers, I think we are dealing with what is an impossible system. According to my calculations, Tarsiss would very quickly become tidally locked to Catullus, and Catullus' rotation would begin to slow due to tidal forces from both Gauss and Tarsiss. But at the same time, Catullus would migrate away from Gauss, and Tarsiss from Catullus. Tarsiss' migration would greatly lessen its tidal force on Catullus, causing Gauss' tidal force to become dominate. By my estimates, Tarsiss would escape Catullus' sphere of influnce, and Catullus would become tidally locked to Gauss. I'm not an expert on this, so I can't guarantee the veracity of my calculations. But the entire system as it exists in GPP appears to be artistic license. There is certainly nothing wrong with your calculations, but Tarsiss just seems to be in an orbit that it would never occupy in real life. And since the likely real-life outcome would have Catullus becoming tidally to Gauss, I'm inclined to keep the system as it currently is. (edit) @Leganeski, I might consider moving Tarsiss' orbit from its current 6,000 km out to 8,000 km. This would reduce the tidal force from Tarsiss to just barely below that from Gauss, thus removing the conflict and making things more mathematically palatable. Tarsiss would still be well inside the Hills sphere, so the orbit should be stable. And hopefully it wouldn't be big enough of a change to significantly alter things visually.

Because only Galileo can edit the opening post, and he's not around anymore. I would if I could, but I can't. Because the current JNSQ release predates the problem. If and when there is a JNSQ update, the problem will be fixed.

I don't know what the problem is, but it could be the kerbal renamer. You might try deleting the folder GPP_Renamer. I'm not sure what happens to an existing save if you do that, however. It would be a good idea to backup your save beforehand. You might have to start a new game.

The internal name of the home world is always Kerbin, although it can be given a different display name. What you see when playing the game is the display name, which in GPP is Gael. But all the configs reference the home world by the name Kerbin. This is true of any planet pack. Glad to hear it.

It looks like Kerbin isn't loading. According to the logs, [LOG 15:58:45]: [Kopernicus]: Configuration.Loader: Failed to load Body: Kerbin: Default constructor not found for type UnityEngine.Material I don't know what that error means, however. I need to see what and how you have your mods installed. Can you provide a screenshot of your GameData folder?

JNSQ has an optional config that allows it to be downsized to stock scale. JNSQ and GPP are both Team Galileo products. There's also Grannus Expansion Pack (GEP). It was originally made as a secondary star system to add to GPP, but it includes an option that makes it the primary system. It has about the same number of planets as the stock system, but they orbit a red dwarf star. The home world is also slightly larger than Kerbin. The home worlds in JNSQ (with 1x rescale) and GPP are both the same size as Kerbin.

Just to be clear, Parallax is not supported by JNSQ. If it works with JNSQ, that's probably just because JNSQ uses the same planet names as stock KSP. Parallax is apparently applying its stock configs and textures to JNSQ. But those configs and textures are made for the stock bodies, not for JNSQ. So even though Parallax may at first appear to be working, I suspect there may be cases where things are not working, or where things don't fit JNSQ either in scale or style. If anyone does run into issues, do not expect to get support from the JNSQ team. Our official position is... don't use Parallax with JNSQ.

If you have scatterer installed but have deleted SVE_Scatterer, then you are getting scatterer's default configs and textures. That might be OK for your purposes, but it's not SVE. If you want SVE's scatterer configs and textures, then you should reinstall SVE_Scatterer and revert to the older version of scatterer. The dust storms in SVE have been turned off. I don't know the reason for this, but I'm guessing they either didn't work properly or were causing some problem. If you want to try turning them back on, you can find the config for them in the file StockVisualEnhancements/SVE_Configs/SVE_Clouds.cfg. If you scroll down you'll find the config for Duna-DustStorms, It hasn't been removed, just commented out so it doesn't execute. If you want to reenable it, just remove the comment tags // to the left of each line. I make no promises about what will happen if you do this.

@Vphurple Izumi, SVE hasn't been updated in years and is likely not compatible with the latet versions of its dependencies. I know for certain that scatterer v0.08+ can break stuff that's has been updated for it. I recommend reverting to scatterer 0.0772. I don't know if the current EVE works or not. You might have to roll back to an earlier version of it as well. I also see you have SVT installed. I strongly recommend against that. SVT was made for a very old version of KSP that had pretty poor terrrain quality. Stock KSP now comes with improved terrain that is far better than what you can get with SVT.

OPM requires Kopernicus, and Kopernicus turns comets off. If you want comets you need to use the stock asteroid generator (which supports comets), rather than the Kopernicus asteroid generator (which does not support comets). Find the file Kopernius/Config/Kopernicus_Config.cfg. Open the file and find the setting UseKopernicusAsteroidSystem. Change UseKopernicusAsteroidSystem from equal to True to equal to Stock and save.

We have no current plans to do that. If somebody else wants to write and release Parallax configs for JNSQ, they are welcome to do so.

I don't understand. But JNSQ is not configured to use Parallax. You should not be using it with JNSQ.

Why are you posting this in the JNSQ thread?

Any unopened saves will be unaffected by the installation of RSS. After installing RSS, you should start a new game just for RSS. If at some point you want to go back to your old saves, you'll need to remember to uninstall RSS before opening them. Opening a non-RSS save with RSS installed could mess up your old save, possibly deleting some of your vehicles.

It use to be Kerbin sized, but 1/9 scale works better mathematically, so it has been changed. The mod is apparently retaining the old name because it is familiar. It's not unprecidented to keep a traditional name (why is the Big 10 called the Big 10 when the conference has 14 schools).

Yes, about 2500 m/s at an altitude of about 80 km. About 2400 m/s at 150 km, and about 2300 m/s at 220 km. Because at 1/9 scale, orbital periods are exactly 1/3 what they are at real scale. So Earth can be given an 8-hour day, and all the planets will retain their familiar real life orbital periods when measured in days. That is, Mercury will orbit in 88 days, Venus in 225 days, Earth in 365 days, etc.

Yes. If you use Sigma Dimensions and Rescale, the OPM planets will be rescaled along with the stock planets.

Interesting. I would have thought @*,* would have worked. Although JNSQ uses "Class", not all planet packs do. Some use "Value", though it really doesn't matter name is used, it can be anything. The first asterisk is suppose to be a wildcard that will work with any sub-node name, and the second asterisk is suppose to apply the change to all instances where that sub-node name appears. @R-T-B, has @*,* ever been tested to assure that it works? Perhaps you should do something like this just to cover all the bases: @landClasses { @*,* { @color = 0,0,0,0 @noiseColor = 0,0,0,0 } @Class,* { @color = 0,0,0,0 @noiseColor = 0,0,0,0 } @Value,* { @color = 0,0,0,0 @noiseColor = 0,0,0,0 } } I think I may have seen other posts where people have reported ColorFix.cfg not working, though I could be getting confused with something else.

I've never seen anything like your first screenshot. That being said, ghosting can occur when rescaling if you don't refresh the cache, though it usually doesn't look like your screenshot. If you haven't already done so, I recommend deleting the .bin files located inside the GPP/Cache folder, and restarting.

Logs might as well be written in Egyptian hieroglyphics for all the good they do me.

I'd like @JadeOfMaar to give his oppinion on this. As far as I'm concerned, it can all go. None of it is worth keeping if it has the potential to cause problems. The only possible exception that I wouldn't mind keeping is the Skybox**, but only if we can be certain it is working bug free. The rest of it I've never really been a big fan of, and I certainly wouldn't be broken hearted if the skybox goes as well. Generally speaking, I don't like frills and extras that do little to enhance the game. The maintenance and risk of bugs isn't worth it. ** GPP has it's own sky box, assuming it is working. Honestly, I haven't really noticed if it is or not.

Yeah, I really don't want to lose HeatShifter. Sounds like something is going to be broken no matter what I do.

It looks like there's an error in the config. GPP adds BG surface features to the GPP planets only when GPP is installed in its normal primary mode. But then it removes all BG surface features not added by GPP regardless of whether it is installed primary or secondary. It should remove those features only in primary mode, not secondary. Or else it will strip the stock planets of all their surface features. I think the fix is to add a no GPP_Secondary condition to the removal. Try this... Find the file GPP/GPP_Configs/GPP_ROCdefinitions.cfg, and change the first line to the following: !ROC_DEFINITION:HAS[~Mod[GPP]]:NEEDS[!GPP_Secondary]:LAST[GPP] {} I've been made aware that Sigma Renamer has been causing crashes, but this is the first I've heard of any issues with Sigma Replacements. I've already decided to delete the Renamer from the next release. I might have to delete the Replacements as well.

What is "eva science kit"? Are you referring to the deployable science parts that came with Breaking Ground?