OhioBob

Perhaps you should delete ModuleManager.ConfigCache. The cache will rebuild the next time you launch KSP.

Why don't you ask the makers of Wanderer's Planet pack why their mod isn't working?

I still don't know where the 5130 m/s number comes from, but looking at the KSRSS delta-v maps I see that they give 3400 m/s for stock size, and 5375 m/s for 2.5x. I think where the 5375 number comes from is, 3400*SQRT(2.5) = 5375 m/s. While it is true that delta-v goes up by the square root of the rescale factor, this is really only true for transfer trajectories between bodies, such as going from Earth to Mars. For a launch from the surface of a body to low orbit, this method tends to overestimate the delta-v required. This is because, although the planet is 2.5 times larger, we're typically not launching into an orbit 2.5x higher. For instance, say we typically launch into an 80 km orbit at stock scale. At 2.5x we might increase this to 100 km to get above the higher atmosphere, but we don't start launching into a 200 km orbit just because the planet got 2.5x bigger. Also, drag losses do not get appreciably greater just because the planet got bigger. So while multiplying by SQRT(Rescale) is a quick and easy way to convert delta-v, in this case it yields a very conservative result.

Axial tilt is not possible in KSP. But while the axes can't be tilted, the orbits can. So what RSS does to give Earth's axis a ~23.5-degree tilt relative to its orbit is to incline the entire ecliptic. This gives Earth the correct tilt, but it also gives all the other planets approximately the same tilt as Earth. This is just a limitation of KSP and there is nothing that can be done about it. It's possible to give any one planet the correct tilt, but then all the others are wrong. In RSS, Earth is the correct one, which obviously makes the most sense.

In addition to the fix on the Kopernicus GitHub, it is also posted in this thread three posts above yours.

I've been able to manage 4800 m/s in JNSQ as well, though not every one of my rockets can do it. 4900 m/s is a more reasonably attainable number, thus it's what's on the delta-v map. It's been awhile since I last played, but I seem to recall budgeting about 5100-5200 m/s for early career rockets.

We commonly say JNSQ is 2.7x stock, but it was actually made to 1/4 real scale. That is, the JNSQ solar system was designed at real scale and then scaled down to 1/4 size. I place stock at about 1/10.6 to 1/11 real scale depending on what dimension or property we're looking at. If we call it 1/10.8, then that makes JNSQ about 10.8/4 = 2.7 times stock. So that's where the 2.7x comes from, but it's only approximate. In reality, none of the body radii are scaled directly from stock. I scaled the celestial bodies based on mass, not size. I then selected what I thought were realistic densities and computed new radii from mass and density. Where does the 5130 m/s number come from? Is that RSS at 1/4 scale? The 4900 m/s number for JNSQ was determined in game through repeated launches. I find it to be pretty close for rockets made from 2.5-m parts and larger. The 1.25-m parts tend to be less efficient. This is likely because the small parts have a lower ballistic coefficient and, therefore, more drag loss. For these smaller parts, >5000 m/s is pretty common. 5130 m/s sounds reasonable in that case. As far as rotation speed goes, the faster rotating the body, the less delta-v the rocket takes to get to orbit (assuming we are launching in the direction of the rotation, i.e. east for most bodies). So if Kerbin in JNSQ is rotating faster, then that too could account for some or all of the difference.

JNSQ dosen't do anything to parts but for a couple small exceptions. The LV-TX87 and LV-T91 engines have their thrust, mass, and cost increased slightly (25% for the 87 and 20% for the 91). This is because these engines are intended to power a Titan II analog rocket to lift the Mk2 command pod + service module to orbit. At JNSQ scale, we believed these engines where a little unpowered for that task, so we gave them a buff. We also changed the AtmosphereCurve for a couple Karbonite Plus engines from Umbra Space Industries. I'm not sure what that's all about, I'm not the one who did it.

@linuxgurugamer, I might be getting confused with something else, but I kind of remember talk about adding some custom anomalies. Perhaps the stock anomalies were removed with the intent that they'd be replaced. But further development of JNSQ has pretty much come to a halt, so custom anomalies are a dream that will probably never be realized. If I ever release an update, I'll consider bringing the stock anomalies back.

It looks like the Kraken has been removed too. It would normally appear on Bop, and has the name DeadKraken.

I have no list, but it looks like you've already figured out how to find out what's been removed. Just open the configs and look for something like, removePQSMods = PQSCity[UFO]. If you were to edit out that part of the config, I suppose the anomaly would come back, though I'm not sure if it would work in an existing save. Galileo wrote that part of the configs, so I don't know what he had in mind when removing the anomalies. I do know that the planets weren't constructed with accomodation of the anomalies in mind. Perhaps he just felt that the terrain at the location of the anomaly was unsatisfactory. I can only guess at the reasons. That part I don't understand. All my prior experience with monoliths is that they snap to the terrain. No idea why this one is doing otherwise.

The UFO has been removed, as have many anomalies. I'm not sure why.

For the 140 km Kerbin atmosphere, the hard-coded one would be better. That atmosphere was designed from the beginning to be 140 km, so its temperature curve, etc. follows a realitstic Earth-like profile all the way to the top. The Sigma Dimensions atmosphere only has information up to 87.5 km, so above that it is just extrapolating from the last known information. For instance, as I recall, it uses the last known temperature throughout the extrapolated region. However, now that we know atmoTopLayer is actually working, you can use it to modify the atmospheres of other planets.

@Strych74, I think this apparent Sigma Dimensions bug is a false alarm. While it's true the MM cache is showing only the changes produced by atmosphere, it appears that atmosTopLayer is actually working in game. For instance, I ran a test using using atmosphere = 1.25 and atmoTopLayer = 1.6, which should give us a Kerbin atmosphere with a height of 140 km. The curves we see in the MM cache only shows them stretched out to 87.5 km, and not extrpolated out to 140 km as they should be. But when I load up the game and place a satellite in orbit within the 87.5-140 km region, it encounters atmospheric drag. The Aero GUI is also indicating air pressure in this region. So while the MM cache leads us to believe that atmoTopLayer is not working, in game testing shows that it actually is.

That works out nicely because when resizing a solar system, orbital periods change by the sqaure root of the rescale factor. It would actually be better if KSRSS were resized to 1/4 real scale rather than 2.5x stock. At 1/4 real scale, all the orbital periods would be SQRT(1/4) = 1/2 what they are in real life. So if the rotation periods are then also factored by 1/2, the years when measured in days would be exactly the same as they are in real life. Earth's year would be 365 12-hour days, and so on. 2.5x stock scale is is a little smaller than 1/4 real scale, so that's why you are getting orbital periods that are a little less than their real life values. This is one of the main reasons the JNSQ mod was made to 1/4 real scale. The math just works out so nicely. In fact, if I were to make a stock-ish like version of RSS, I would probably make it 1/9 real scale rather than stock size. The difference between 1/9 scale and stock isn't all that much, but 1/9 scale is so much better mathematically. The orbital periods at 1/9 scale are exactly 1/3 real life. So if we give Earth an 8-hour day, all the orbital periods again equal their real life values when measured in days.

I second 12 hours for 2.5x.

It could be that the Kronometer settings are overriding your Sigma Dimensions settings. Rather than trying to change it using SD, you might have to change it on the Kronometer side. I suggest editing the file KronometerIntegration.cfg in KSRSS. I think the following should work: @Kronometer // For Rescale Continued 2.5x { @useHomeDay = false @useHomeYear = true @useLeapYears = true @CustomTime { @Day { value = 67500 // length of day in seconds, use whatever number you want } } }

@Strych74, the following patch will replace Kerbin's atmosphere with a proper 140 km atmosphere. Unfortunately this does nothing to fix the atmospheres of any other planets. You might as well set atmosTopLayer = 1 in your SD config as it doesn't seem to do anything other than change the atmosphere depth as seen in the Tracking Station. For planets other than Kerbin, you'll just have to change their atmospheres using the atmosphere setting, though this is certainly less than ideal.

@Strych74, I don't know why it isn't working for you. Almost all atmospheres end with something like "70-0-0-0". Sigma Dimensions is suppose to ignore that last key and extrapolate from the keys preceeding it. So if it were working as designed, it would properly extraloate the atmosphere to 140 km. The last key shouldn't be the problem. I know it worked properly when it was initially tested, but that was a long time ago. Maybe something has broken since then. You can try changing the last key to see if it makes any difference, but I'm not sure it will. If I hadn't forced the pressure curve to go to zero, the next key would have been: key = 70000 3.00633E-04 -6.33976E-08 -6.33976E-08 It might also be benificial if I could see your Sigma Dimensions config. Perhaps I can spot an error if one exists. (edit) If all else fails, we could use Earth's atmosphere curves from RSS and write a patch that will change Kerbin's atmosphere without the use of Sigma Dimensions. Of course this won't help with any of the other planet's atmospheres if they're experiencing the same problem. (edit 2) I just loaded up KSP with Realistic Atmospheres and Sigma Dimensions installed and I'm getting the same problem as you described it. Changing the last key of pressureCurve did nothing to fix it. It seems clear to me that atmoTopLayer in Sigma Dimensions is now broken. Unfortunately I haven't heard anything from Sigma88 in probabaly a year or more. I think he has lost interest in KSP and has stopped maintaining his mods. And since his mods are licensed All Rights Reserved, there really isn't anything anybody can do to fix it. I might consider writing patches for Realistic Atmospheres that will edit the atmospheres for different scales without the use of Sigma Dimensions, but I don't have time for that now. Perhaps in the future. (edit 3) Further in game testing has shown that Sigma Dimensions is in fact working as it should. For some reason the atmosphere curves we're seeing in the MM cache do not match what we're actually getting in game.

Did you reset the funds in both the persistent.sfs and the persistent.loadmeta files?

Not really, that's just a consequence of the way the textures wrap around the planet. It happens on almost every celestial body. The only way to fix it would be to change the heightmap so that the poles are flat (like Kerbin's ice caps). But other than that, you're stuck with it.

It looks like some celestial bodies are inheriting anomalies from their template, while others have had their anomalies removed. Anomalies are placed using a mod called PQSCity. If you look in Mercury's config (RealSolarSystem/RSSKopernicus/Mercury/Mercury.cfg) you'll see that it uses a Mun template and under removePQMods the mod PQSCity is listed. This is going to remove the anomalies from the template, and hence from Mercury. Vesta, on the other hand, uses a Eeloo template with no PQS modes removed. Since the mod that adds the anomalies hasn't been removed, Vesta will have Eeloo's anomalies. If you want to know which bodies will have anomalies and which ones won't, just look in the body configs to see if PQSCity has been removed. But those bodies that have anomalies will just have the same ones as the template. For instance, Ceres also uses an Eeloo template with no mods removed, so it will also inherit Eeloo's anomalies. But this means Ceres and Vesta will both have the same anomalies.

Sorry, I got a little confused. The other guy responding to you mentioned GPP, so somehow I got it in my head you were using GPP. Clearly that's not the case. But nonetheless, the issue could be the same. (edit) I just looked in the planet configs for KSRSS and it looks like colliders are turned off. So unless there is some other config somewhere that turns them on, colliders are not likely to be your problem. One way to be sure if they are on or not is the look at the scatters in the MM cache to see if colliders are enabled.

I don't know how much of an issue this is anymore, but GPP use to have FPS problems like you descibe because of all the colliders on the ground scatter. You can try disabling the colliders to see if that fixes it. To do so, delete the file, GPP/GPP_Configs/EnableColliders.cfg. If that doesn't help then I don't know what the problem is. (FYI, for the next release of GPP we're changing the colliders to optional with them turned off by default.)

This bug has been pointed out to me already and has been fixed, though not yet released. To fix it, just open the file JNSQ_Rescale/JNSQ_Bodies/Sun.cfg and replace the intensity curves with the following: