OhioBob

No plans to do that. There will likely be an update, but just to fix a few bugs. Parallax I'm leaving up to some industrious third party to volunteer his/her time to release a community patch. If it doesn't happen, then I guess the community didn't want it bad enough.

JNSQ does not support Parallax, though some parts of Parallax for stock KSP may work with JNSQ. The following post explains it...

Save it as a plain text file with a .cfg extention. Then put it anywhere inside your GameData folder.

Use the setting "offsetTime" to change the starting time. For example, if you want the clock to start at 12:00:00, you have to offset 12 hours, or 43200 seconds. Try this: @Kronometer:FINAL { @DisplayDate { @PrintDate { @offsetTime = 43200 } @PrintDateNew { @offsetTime = 43200 } @PrintDateCompact { @offsetTime = 43200 } } }

A 365-day orbit around Earth would require a semimajor axis of about 2,157,400 km. So the SOI would have to be greater than that. You should be able to change it with a patch like this: @Kopernicus:AFTER[RealSolarSystem] { @Body[Kerbin] { @Properties { %sphereOfInfluence = 2200000000 } } }

I don't know, but I suspect asteroids that have already been spawned in will be unchanged.

DART comes packaged with both Kopernicus and Parallax. Perehaps if you install just Parallax_StockTextures without the Parallax plugin, it will work. I don't know, but it might be worth a try.

None are. Because JNSQ hasn't been updated. If is is updated, the fix will be included. Kopenicus also includes a patch for this. See ColorFix.cfg.

Asteroids are a bit messed up in the current release of JNSQ. The issue has been fixed, but not yet released. I really need to release an update just to fix a few minor things, such as this. If you want to update your installation, go to the file JNSQ/JNSQ_Configs/Asteroids.cfg and make the following change: @PART:HAS[@MODULE[ModuleAsteroid]]:FOR[JNSQ] { @MODULE[ModuleAsteroid] { @density *= 33 // Stock asteroids will have density of 1.0; Number taken from RSS %maxRadiusMultiplier = 1.67 //Default is 1.25 %minRadiusMultiplier = 1 //Default is 0.75 } } That being said, asteroids are quite a bit more massive in JNSQ then they are in stock. It's not because we've made the them all that much bigger, but because we've made them denser. Densities are unrealistically low in stock, so we increased the density to a more lifelike value. (edit) I just noticed an issue with your math. 2.5^3 = about a 15x increase. So a 10-ton asteroid would be about 150 tons. If I'm reading our changes correctly, we've increased radius by 1/3 and density by 33 times. So I think we should expect asteroids in JNSQ to be about 1.333^3 * 33 = 78 times more massive than they are in stock.

That's correct, stock only. DART is not intended to be used with any other planet packs. Also, do not install Kopernicus if using DART. DART comes packaged with a specially modified version of Kopernicus.

For JNSQ and GEP to work together properly, you need to resize one of them. You must either add the GEP 2.5x Rescale mod to make it match the size of JNSQ, or the JNSQ 1x Rescale mod to make it match the size of GEP. In either case, JNSQ will be the primary system with Kerbin the home world. The star Grannus will orbit Kerbol with the GEP planets orbiting Grannus. Both JNSQ and GEP have been tested with Principia and verified to work fine individually. I've never tested the two installed together with Principia, but I suspect it should work OK. Both systems require some changes to work correctly with Principia, but those changes are built in, so you shouldn't have to do anything.

Yes.

Do you have scatterer installed, and if so, what version? JNSQ is not compatiable with 0.08+ versions of scatterer, so if that's the problem, revert back to v0.0772.

Yes, the orbit of Grannus should be changed. That fact that it isn't is an oversight. I figure the best place to add this change is in the JNSQ 1x rescale, since that's the only rescale mod required in that scenario. To the JNSQ 1x rescale mod I'm adding the file JNSQ_Bodies/Grannus.cfg, which includes the following: @Kopernicus:AFTER[GEP]:NEEDS[JNSQ,!GPP,!GEP_Primary] { @Body[Grannus] { @Properties { @sphereOfInfluence = 7.5E+11 @hillSphere = 7.5E+11 } @Orbit { @eccentricity = 0.1 @longitudeOfAscendingNode = 195 @meanAnomalyAtEpoch = -0.426 } } }

Do you have TextureReplacer installed?

@gooh12, your image isn't showing up for me. I don't know why, but without it I don't know what artifact your are referring to. Thus I can't help.

How big is Earth in game? Look at the planet information in the Tracking Station and tells us what it says.

Yes, that is the assumption. All three bodies are rapidly rotating at the start. Interesting hypothesis. I might have to study this in more detail when I get a chance.

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.