OhioBob

You really need to get @Galileo's blessing. I just helped out with some of the sigma settings. Galileo is the author/owner of all the configs. Although I haven't played KSP in a couple months, my last career game was a 2.5x version of GPP. I agree that it's a nice size. Getting to orbit and going interplanetary just seems a little too easy in stock size (1x). For GPP I wanted something that required the use of rockets that looked and behaved more lifelike*, could be played with stock parts, but was not too difficult. 2.5x seems to fit the bill nicely. * I wanted it so that I needed to use at least two stages to get to orbit, and three stages to go interplanetary.

Well, that's strange. I bought KSP through their online store. When a new version comes out I just download the .zip file and extract the contents to my Program Files folder. Been doing it the same way for years, never had a problem. I really don't see how something could be wrong with the installation.

Sorry, I messed up in typing my reply. I do have a KSP_x64_Data folder. But there is no file named output_log.txt in that folder. I have four different installations and none of them have a output_log.txt file. So the question remains, is the file you're looking for the one named KSP.log in the KSP install folder? The problem isn't the path (though I did get confused and typed it wrong), the problem is the missing file.

The problem is that you are using altitudes, not radii. The Pe and Ap that you read in the game are altitudes, measured from the surface of the planet (sea level, or datum, to be exact). The formula that @Snark gave you requires that you use radii, measured from the center of the planet. You therefore must add the radius of the planet (600 km for Kerbin) to the altitudes that you read in the game. So if you're reading Pe/Ap of 75/460 km in game, that's means your radii are 675/1060 km. So you have 675/1060 = 0.637, which matches Snark's number (with some rounding error).

@Sigma88, are you sure the following path and file name is still correct? I don't have a problem to report, but I was reading your instructions and I can't find the above in any of my KSP installations. I have a KSP_x64_Data folder, but it contains no file named output_log.txt. What I do have is a file named KSP.log is the root directory of my KSP installation(s). Is that the file you're referring to? If so, you should change your instructions. (edit) fixed error in my description of the problem.

While you're adding SSRSS, can you also add GPP? GPP currently includes a Kerbalism config, but the developers would prefer to remove it from GPP and add it to Kerbalism. You can use our config as is, modify it, or make your own. Below is the current GPP config. We also have a version with the science definitions formatted for localization, which I can provide if requested. // ============================================================================ // Distance-field models // ============================================================================ // emits secondary gamma radiation on sun facing side RadiationModel { name = icarus has_inner = true inner_dist = 0.05 inner_radius = 0.95 inner_compression = 0.9 inner_extension = 2.0 inner_quality = 50.0 has_outer = false has_pause = false } // similar to earth but more compact with deformed magnetopause RadiationModel { name = thalia has_inner = true inner_dist = 1.5 inner_radius = 0.3 inner_compression = 1.05 inner_extension = 0.9 inner_quality = 50.0 has_outer = true outer_dist = 1.5 outer_radius = 1.5 outer_compression = 1.1 outer_extension = 0.8 outer_border_start = 0.1 outer_border_end = 1.0 outer_quality = 60.0 has_pause = true pause_radius = 3.25 pause_compression = 1.1 pause_extension = 0.5 pause_height_scale = 1.5 pause_deform = 0.1 pause_quality = 30.0 } // ============================================================================ // Antenna range for GPP bodies // ============================================================================ @PART[*]:HAS[@MODULE[Antenna]]:NEEDS[Kerbalism,FeatureSignal] { @MODULE[Antenna]:HAS[#type[low_gain]] { @dist *= 1.0 // scale using average body radius, versus stock one } @MODULE[Antenna]:HAS[#type[high_gain]] { @dist *= 9.3229 // scale using Gauss' SMA } } // ============================================================================ // Resource change for GPP bodies // ============================================================================ @PLANETARY_RESOURCE,*:HAS[#ResourceName[LqdAmmonia]]:NEEDS[Kerbalism]:AFTER[Kerbalism] { @ResourceName = Ammonia } @BIOME_RESOURCE,*:HAS[#ResourceName[LqdAmmonia]]:NEEDS[Kerbalism]:AFTER[Kerbalism] { @ResourceName = Ammonia } // ============================================================================ // Radiation environments for GPP bodies // ============================================================================ RadiationBody:NEEDS[GPP] { name = Ciro radiation_model = heliopause radiation_pause = -0.020 } RadiationBody:NEEDS[GPP] { name = Icarus radiation_model = icarus radiation_inner = 0.01 } RadiationBody:NEEDS[GPP] { name = Thalia radiation_model = thalia radiation_inner = 1.0 radiation_outer = 0.2 radiation_pause = -0.005 } RadiationBody:NEEDS[GPP] { name = Niven radiation_model = ionosphere radiation_pause = -0.005 } RadiationBody:NEEDS[GPP] { name = Gael radiation_model = earth radiation_inner = 10.0 radiation_outer = 2.0 radiation_pause = -0.010 } RadiationBody:NEEDS[GPP] { name = Tellumo radiation_model = earth radiation_inner = 20.0 radiation_outer = 2.0 radiation_pause = -0.010 } RadiationBody:NEEDS[GPP] { name = Gratian radiation_model = irregular radiation_pause = -0.005 } RadiationBody:NEEDS[GPP] { name = Otho radiation_model = giant radiation_inner = 175.0 radiation_outer = 6.0 radiation_pause = -0.010 } RadiationBody:NEEDS[GPP] { name = Gauss radiation_model = giant radiation_inner = 125.0 radiation_outer = 4.0 radiation_pause = -0.010 } RadiationBody:NEEDS[GPP] { name = Catullus radiation_model = earth radiation_inner = 5.0 radiation_outer = 1.0 radiation_pause = -0.010 } RadiationBody:NEEDS[GPP] { name = Nero radiation_model = giant radiation_inner = 150.0 radiation_outer = 5.0 radiation_pause = -0.010 } RadiationBody:NEEDS[GPP] { name = Grannus radiation_model = heliopause radiation_pause = -0.020 } // ============================================================================ // Tweak heliopause // ============================================================================ @RadiationModel[heliopause]:NEEDS[GPP] { @pause_radius = 12000.0 } // ============================================================================ // GeigerCounter science experiment definitions // ============================================================================ @EXPERIMENT_DEFINITION[*]:HAS[#id[geigerCounter]]:NEEDS[GPP] { @RESULTS { CiroSrfLanded = Ummmm... No. CiroFlyingLow = Son of Kraken! CiroFlyingHigh = At this point you really cannot distinguish ionization from sheer thermal induction. CiroInSpaceLow = You must be reenacting the Sunshine (2007) movie if you're still alive to read this! CiroInSpaceHigh = The solar wind burns more now, unmitigated by the intervention of any planet. IcarusSrfLanded = Geiger attempts to chill, showing no radiation presence, but he's still cooking just as anything and anyone right now. IcarusInSpaceLow = The gamma levels subside. You find this so peculiar, but you take relief in the hope that you may not have to deal with it as well as the heat if you land. IcarusInSpaceHigh = You find a modest and consistent flow of gamma rays coming from the planet rather than the star. Fascinating! ThaliaSrfLanded = You detect a high amount of ambient radiation or at least confirm the presence of a lot of radioactive material within the crust. ThaliaInSpaceLow = The compact magnetosphere shows more vivdly. Where you expect the radiation curve to dial down compared to Gael, it does not, and does so closer to the surface. ThaliaInSpaceHigh = Does it get any scarier here, up close? You find a misshapened magnetic field after just beginning to come to terms with the unexplained and blistering ambient heat. EtaSrfLanded = Geiger is chill. Eta is as chill while landed as while space. EtaInSpaceLow = Nope. Nothing yet. You steele yourself with the anticipation that Eta might surprise with something deadly. EtaInSpaceHigh = It astounds you that this moon dances right outside of a far larger deadly thing than the eyes can measure. Anyway it seems pretty safe here so break out the snacks! NivenSrfLanded = It's safe to put away the foil wrappings but it's still a bad idea to strip down and step outside. NivenFlyingLow = Geiger says it's safe to turn off the red lights now. NivenFlyingHigh = Some space radiation persists here! NivenInSpaceLow = Some deep analysis confirms that this planet's own radiation field is eroding its atmosphere! NivenInSpaceHigh = The device registers a very unique radiation pattern with this planet. It's safe to assume from the look of things that the pattern is tied to the atmosphere. GaelSrfLanded = Geiger sleeps. Though it may wiggle its toes if used near a concentration of Uraninite. GaelFlyingLow = The device is enjoying the ride as much as you are. It forgets to be alert and registers nothing. GaelFlyingHigh = The needle goes up but you wonder if it's measuring radiation or speed. GaelInSpaceLow = You encounter powerful toroidal formations of deadly ionizing particles and wonder absolutely why is this here? ...And can engines be developed around them in the near future(tm)? GaelInSpaceHigh = The space radiation is still very strong out here. It seems deterring... What if everywhere is like this? IotaSrfLanded = The Geiger still rests. it's celebration time! IotaInSpaceLow = It continues to appear very safe in Iotian space. Prepare the shovels. Droops Candy is clearly safe to eat. IotaInSpaceHigh = The needle barely budges. That's a nice but dull entry for the logs. CetiSrfLanded = Your suit ensures that you feel nothing...but it's just a little warm here. CetiInSpaceLow = Since it twitched it has very steadily, very slowly risen. Ceti's looks aren't the only displeasing thing about it anymore. CetiInSpaceHigh = The needle twitches. Geiger must have been slightly jarred by the sight of the moon. TellumoSrfLanded = What's hot and cold at the same time? ....Tellumo. TellumoFlyingLow = Unlike at Gael the needle still holds a very modest position above zero. Well dang, imagine what the surface is like. TellumoFlyingHigh = The atmosphere, it burns! Forget the radioactive stuff! TellumoInSpaceLow = The geiger pulls a high note. It's twice as bad here as around Gael! TellumoInSpaceHigh = That same powerful irradiance from Gael meets you again. It makes you wonder if the ice is radioactive. LiliSrfLanded = If ever you wanted to stick a bulb in a potato and watch it light up, now is the time! LiliInSpaceLow = Lili's kinda... hot. Rimshot. LiliInSpaceHigh = It's reasonably strong out here. Well it makes sense, there's no way this infant world can shield itself. GratianSrfLanded = The needle rises. Depending on the mission goal you picked a good place to land...or not... GratianFlyingLow = Red dust heavily gathers on the face of the instrument but doesn't block the data flow... yet. GratianFlyingHigh = The sensors burn slightly but not from cosmic stuff. GratianInSpaceLow = Spices themselves are kind of like deadly ionizing material. It just depends on where it gets to and if you can resist it long enough. That said, there's nothing to worry about yet plenty to write about the actual weird readouts here. GratianInSpaceHigh = If we ever have to turn on the red lights we can save some battery and just angle the windows at Gratian. That said, it's perfctly safe to roll up the Aluminum. GeminusSrfLanded = The lower you go the more the needle inches up. You wonder what the composition of the darker surface material is and can't discern whether Geminus is absorbing or emitting. GeminusInSpaceLow = The irradiance is modest but clearly present. You wonder if it intervened in any way with Geminus' marvelous geography. GeminusInSpaceHigh = Gratian's irregular field carries over here. You detect an unhampered stream of charged particles flowing past this moon and its parent. OthoFlyingLow = Your ship is as yellow and white as the planet. Be happy. You've attained your membership in the yellow bodies club. OthoFlyingHigh = Although you may be burning alive at this point, the unique irradiance pattern is very bold and is consistent with Otho's distance from Ciro. OthoInSpaceLow = According to the geiger, it absolutely burns just to be here! Is this the weight of Otho's gaze? You find a window and carefully look out to see if its eye is indeed positioned in your general direction. OthoInSpaceHigh = The readings seem particularly high here, higher than even at the largest gas giant. Why this is, warrants a direct run to the nearest science lab. AugustusSrfLanded = You forget that there is a potential equal danger to being here as under any other foreign skies. Apart from an apparent lack of water, this place seems quite inviting. The geiger's lack of response seems to finally confirm this. AugustusFlyingLow = The place gets as yellow and orange as anywhere will ever get. The instrument barely reacts so maybe the extreme color bias is the only actual threat to exposed sensory bits. AugustusFlyingHigh = The geiger doesn't count... The atmosphere must help quite a lot to mitigate Otho's radiation. AugustusInSpaceLow = As you approach you think more about what kind of AugustusInSpaceHigh = You would think that maybe something was up, here, given the strong color, but surprise! It seems very safe. HephaestusSrfLanded = The needle barely jumps but that means you can! Hephaestus does very well to deflect cosmic radiation, it seems! HephaestusInSpaceLow = The needle flops loosely indicating the device has become defective. You consider searching here for metal in case some other bits of technology decide to show their wear. HephaestusInSpaceHigh = The sharp transition from the radiation value outside this moon's SOI to 0 astounds you. There must be something here quite worth finding and mining the science out of. JannahSrfLanded = The device rests again. Either it's passed out from fear or the battery is spoiled. JannahInSpaceLow = The radiation 'down here' doesn't seem as scary or suspicious as up high. JannahInSpaceHigh = You find a very suspicious cavity in the radiation belt here. To your surprise it's geosynchronous with that equally suspicious cavity in the face of the moon! GaussFlyingLow = The glass cracks. GaussFlyingHigh = You're able to separate ionizing radiation from scalding heat. Congratulations! GaussInSpaceLow = Can you hear it? that's te sound of Van Allen Kerman's ghost howling. GaussInSpaceHigh = The needle jitters. You are extremely far but the immediate response seems like you're extremely near. LokiSrfLanded = The Geiger is silent. It may be terrified after what happened on the way down. LokiInSpaceLow = The needle sharply movs and jitters about. It's nearly enough to cause a panic but it stops as quickly as it started. Was it yet another genuine anomaly or is this moon living up to its name. LokiInSpaceHigh = The geiger gives tiny but rhytmic readings. The sine waves almost resemble a comedic villain laughing. CatullusSrfLanded = There seems to be some alpha decay even way down here. Since Catullus is a borderline gas planet it all works out. CatullusFlyingLow = There's so much purple you'd think the atmosphere itself mutated from exposure to itself. CatullusFlyingHigh = The atmosphere is tangy with a weak saturation of radiation. Compared to Gael it's a small deal. CatullusInSpaceLow = The Geiger coasts on higher numbers. You know that stuff is about to get real. CatullusInSpaceHigh = Radiation level is rather high. Catullus clearly has plenty to be scared about. TarsissSrfLanded = The barometer no longer distracts you, but its own readout on landing, lingering in your mind, does continue to distract. TarsissFlyingLow = Your attention is torn between reading this device and staring at the barometer. TarsissFlyingHigh = The device still dos not signal any presence of harmful radiation. You wonder again if it's broken. TarsissInSpaceLow = The Geiger rests. TarsissInSpaceHigh = Radiation level is nill. You suspect that Tarsiss has its own healthy magnetosphere. NeroFlyingLow = Radiation levels just keep climbing. While you need more than just Shielding in order to survive long enough to escape from here, the readings make for epic science and an epic story to tell the grandkids. NeroFlyingHigh = Nero's heartbeat is very evident. This planet is quite alive. Look at all those digits on the screen! Yeah, those on the thermometer too! NeroInSpaceLow = The needles fly up and dance about very lively, though not as much as it did at Otho. NeroInSpaceHigh = You detect a spike. Even at the edge of this immense SOI a modest amount is registered and displayed by the Geiger. The king indeed throws his weight around. HadrianSrfLanded = The Geiger is frozen and does not respond. HadrianFlyingLow = You ponder whether possibly, any radiation at this point may be a sign of proximity to Nero's heavenly Snack Bar. HadrianFlyingHigh = There's still no radiation, but you do confirm the coldness as the cockpit glass glazes over. HadrianInSpaceLow = You know, this moon looks like it's made of ice. Maybe it's so cold that alpha decay is halted. HadrianInSpaceHigh = There's no radiation here... But there's a lot of photo opportunity. NarisseSrfLanded = No evidence of radiation still. Now if Narisse was indeed an edible celestial there'd be no fear of getting epic indigestion. NarisseInSpaceLow = Still nothing... But still a worthy entry for the archives. NarisseInSpaceHigh = You detect nothing; an appropriate expctation of a moon that's barely there. MuseSrfLanded = The readings are nominal. This makes an okay entry to the logs. MuseInSpaceLow = You're able to focus this time and you record the readings, which are technically none. MuseInSpaceHigh = You find yourself thinking a lot of things. Unfortunately none of these include the actual readout of the Geiger, but fortunately it wouldn't have mattered. MinonaSrfLanded = You experience a fair bit of disllusionment. Landed, the radiance seems to vanish. The Geiger would smirk about now if it was alive...like the Mystery Goo. MinonaInSpaceLow = Her radiance increases as you get closer. The sentiment is not mutual, however, as the Geiger shows no response whatsoever. MinonaInSpaceHigh = You find Minona particularly radiant. Maybe not in a harmful way like you expect, but still. HoxSrfLanded = The Geiger rests. Again... HoxFlyingLow = You get no response from the Geiger. It brings some comfort in that the climate here doesn't add to the amount of natural hazards. HoxFlyingHigh = The needle keeps jittering. It's hard to tell whether it's colder in space, or in this sky, or whether the sky is surprisingly radioactive. HoxInSpaceLow = The Geiger jitters slightly. You wonder if there's an erratic property here or even the machinefeels cold. HoxInSpaceHigh = The ambient radiation levels don't change. This is both a good sign anda bad one. ArgoSrfLanded = The Geiger continues to show no interesting numbers. That means one very good thing... The water has one more good reason to pump straight into the ship and drink in a few minutes! ArgoInSpaceLow = The colors and textures distract you from reading the device. When you remember to do so, apparently the values declare that it's completely safe. ArgoInSpaceHigh = No interesting or emphasized numbers arise. It's a good thing too, as that would show argo to actually be just another deadly siren in space. LetoSrfLanded = Radiation levels are very minor and noteworthy to the device. This anomalous turnout prompts the use of more science experiments. LetoInSpaceLow = The readings are soft but erratic and noisy, indicating the presence of a peculiar factor, but not indicating the presence of a clear danger. LetoInSpaceHigh = Readings are as average as they get, however, knowing how far you are from Gael, you anticipate quite a different experience once you go far enough beyond this planetoid. GrannusSrfLanded = The radiation level is over 9000 times 9000! GrannusFlyingLow = Son of True Kraken! GrannusFlyingHigh = The Geiger screams in absolute terror and agony! GrannusInSpaceLow = The radiation levels are surprisingly strong here. So much of it is in InfraRed rather than in UltraViolet and Gamma. Now this is science! GrannusInSpaceHigh = After discovering the increased plights of the interstellar medium, the device's numbers coast at a lower and steady nominal, but still higher than within Ciro's heliopause. Maybe the differences in wavelengths and saturation are a reflection of Grannus' sheer age. } }

Nevermind.

I've noticed many things that have made their way into configs that are unnecessary or obsolete. These things get copied from one config to another because few people know what they do, so nobody removes them. I'm surely guilty of it as well because I certainly don't know what everything does. But when I do discover that something is unnecessary, I like to let people know. For instance, solarPowerCurve is no longer used by KSP, so it's utterly useless to have it in a config. I also don't know what something like temperatureLapseRate is doing in there. A temperature lapse rate is the rate at which air temperature decreases with increasing altitude (presumably in units of Kelvins per meter). But air temperature in KSP is controlled completely by the temperature curves, so temperatureLapseRate doesn't do anything (it's probably a relic from an earlier version of the game). A couple other parameters that I'm uncertain about are albedo and emissivity. I know what these do in real life, but I haven't figured what, if anything, they do in KSP. Perhaps they're used in temperature calculations, such as computing the radiative heat flux coming off a planet. Since I don't know, I continue to assign values to them. But I do know they don't do anything if placed under the Atmosphere node. Albedo and emissivity need to go under the Properties node, yet I've seen many a config that has albedo under Atmosphere.

I understand the problem with having a non-standard number of hours in a day. I've experienced some of the same problems that you have with some mods not recognizing that the length of day has changed. I discussed this with @Sigma88 and he told me that there are hardcoded variables used by KSP that define the length of the day and year. Kronometer changes those variables. So if a mod uses those variables in its calculations, it should work with Kronometer. However, if a mod has its own hardcoded numbers (i.e. it assumes the day is 6-hours or 24-hours long), then it won't be compatible with Kronometer. Those mods should change their programming to use the stock variables. (KAC is one of the mods Sigma88 told me should work with Kronometer, so if it's not, I don't know what's going on.) When using Sigma Dimensions / Kronometer, I have always made the length of the day equal to the solar day, and the length of the year equal to the orbital period. I have no idea what might break by doing otherwise.

I made my own curve editor: http://www.braeunig.us/KSP/AtmoTutorial/FloatCurve.xlsx. The numbers in columns E to H is the same data that makes up the curve in the cfg file. You just manipulate the data until you get the curve you want. As you add or remove rows of data, you'll likely have to redefine the data range of the curve.

@Gameslinx, I just went through your Olu'um config and made a few changes. I added it to my stock game (both 1.2.2 and 1.3.0) and it is now working fine for me. I'm also not getting any NullReferenceException. I'm not entirely sure which one of the changes I made fixed the problem, but the problem is fixed as far as I can tell. Here's Olu'um.cfg with my changes: @Kopernicus:FOR[GPO] { Body { name = Olu'um // flightGlobalsIndex = 185 // cacheFile = Olei/Cache/Supergiant.bin Template { name = Sun } Properties { description = Olu'um is a sub-star. It's very close to being massive enough to ignite. If Olu'um swallows much more of its accretion disk, there's a good chance it will become a tiny star. If this happens, it will not be good for the planets in its system, as they would all burn to a crisp. radius = 10000000 geeASL = 0.4 rotates = true rotationPeriod = 15000 tidallyLocked = false initialRotation = 0 isHomeWorld = false timewarpAltitudeLimits = 0 20109 40219 80438 160875 321750 643500 1287000 ScienceValues { landedDataValue = 0 splashedDataValue = 0 flyingLowDataValue = 8.5 flyingHighDataValue = 8 inSpaceLowDataValue = 2.5 inSpaceHighDataValue = 2 recoveryValue = 0 flyingAltitudeThreshold = 100000 spaceAltitudeThreshold = 350000000 } } Orbit { referenceBody = Sun color = 0.415686,0.352941,0.803922,1 inclination = 0 eccentricity = 0 semiMajorAxis = 53394283856 longitudeOfAscendingNode = 259 argumentOfPeriapsis = 0 meanAnomalyAtEpoch = 2.27167344093323 epoch = 99.6799999999973 } Atmosphere { ambientColor = 0.781,0.882,0.697,1 lightColor = 0.781,0.882,0.697,1 enabled = true oxygen = false altitude = 405000.0 staticPressureASL = 607.95 pressureCurve { key = 0 607.95 key = 20000 607.94 key = 40000 600.036 key = 60000 590.5595 key = 80000 570.8192 key = 100000 530.40557 key = 120000 500.71404 key = 140000 450.02383 key = 170000 310.416679 key = 200000 300.184984 key = 300000 290.0716413 key = 400000 240.0237546 key = 403000 10 key = 405000 0 0 0 } pressureCurveIsNormalized = false temperatureSeaLevel = 3400 temperatureCurve { key = 0 3500 key = 15750 3000 key = 83250 2500 key = 133750 1000 key = 189750 500 key = 260000 100 key = 400000 50 key = 403000 1 key = 405000 0 } temperatureCurveIsNormalized = false adiabaticIndex = 1.667 atmosphereMolarMass = 0.0014 } ScaledVersion { Light { sunlightColor = 1,0.6573034,0.758427,1 sunlightIntensity = 1 scaledSunlightColor = 1,0.6573034,0.758427,1 scaledSunlightIntensity = 1 IVASunColor = 1,0.6573034,0.758427,1 IVASunIntensity = 1 ambientLightColor = 0.9420224,0.7191012,0.8764045,1 sunLensFlareColor = 0.5393258,0.02808989,0.3146067,1 sunAU = 21841200 luminosity = 350 brightnessCurve { key = -0.02 0.4 0 0 key = 0.01 0.4 0 0 key = 0.1 4 0 0 key = 0.2 4 0 0 key = 0.8 4 0 0 } } Material { emitColor0 = 0.3033708,0.8988764,0.6179775,1 emitColor1 = 1,0.8370786,1,1 sunspotColor = 0.2471908,0.1235956,0.1797753,1 sunspotPower = 1 sunspotTex = BUILTIN/sunsurfacenew rimColor = 0.6573033,0.3146068,0.5730336,1 rimPower = 0 rimBlend = 3 } } } } Most of my changes were things we already discussed, or just simple format cleanup (indentation, etc.). I've commented out flightGlobalsIndex and cacheFile. In GPP we found that assigning flightGlobalsIndex numbers started messing with the sequence of contracts being received. I think the working theory at this point is that it works better if we just let Kopernicus assign the index numbers. I removed cacheFile only because I didn't know exactly how to set up your file structure. You can certainly re-enable that. Something else that you'll want to change back is sunspotTex. I changed it to the builtin texture only because I didn't have your texture. I also added sunspotPower, though I'm not 100% certain what that does (I assume it controls how strongly visible the sunspots are). You'll have to play around with it. I suspect that whatever fixed the problem was just in the format cleanup. This is the second time in the last month or two in which somebody was having a problem with a config that I was able to fix just by going through the file and reformatting indentation, line spacing, etc. (I always use tab for indentation, no spaces). There's apparently just some small thing in there that Kopernicus doesn't like. It pays to keep things neat and clean. I also recommend that you add some in and out slopes to pressureCurve and temperatureCurve.

@Gameslinx, I just noticed something in your logs. It seems that for some reason Kopernicus isn't picking up your atmosphere. For example, Olu'um.Body.log is showing the following: [LOG 14:16:06]: atmosphereDepth = 600000 [LOG 14:16:06]: atmosphereTemperatureSeaLevel = 5840 [LOG 14:16:06]: atmospherePressureSeaLevel = 16 [LOG 14:16:06]: atmosphereMolarMass = 0.0022 [LOG 14:16:06]: atmosphereAdiabaticIndex = 1.43 Those are the values for the original stock sun. It's using the values of the template rather than your values. I don't see anything in your config that could be causing this. There could be some tiny glitch in your formatting that's just going unnoticed. You could try comparing your config to Grannus.cfg from GPP. Grannus is the second star in a binary system. It has been working fine for us.

That doesn't surprise me. My suggestions were things to help clean up the config, not necessarily suggestions for fixing the immediate problem. There is really nothing obvious that I can see that would be generating the error.

@Gameslinx, I haven't looked at the logs, but I have looked over you config. I've got several comments to share with you, but I'm not sure if any of this will fix your problem. SolarPowerCurve is a relic from the past and doesn't do anything. I see that you have it commented out, but you should probably just delete it. Do you really want the atmosphere to have oxygen? You don't need an albedo for stars, but even still, albedo goes under the Properties node, not the Atmosphere node.* I don't think temperatureLapseRate and gasMassLapseRate do anything (I believe they're obsolete), so you should probably delete them. Hydrogen in stars is monatomic, not molecular. Therefore atmosphereMolarMass should be about half what you have it. The adiabaticIndex should be 1.667, which is typical for monatomic gases. You haven't given the star a luminosity. The star should be given a luminosity or else you'll get the same value as the template. Here's some more explanation about luminosity. In real life luminosity is the total energy emitted by a star per unit time. In KSP, however, luminosity is the solar flux at the distance from a star equal to the distance of the home world from its star. In the case of the stock sun, luminosity = 1360. This means that the solar flux at Kerbin (13.6 Gm from the sun) is equal to 1360 W/m2. Whatever luminosity you give to a different star in the same universe, that will be the solar flux at a distance of 13.6 Gm from that star. The ratio of the luminosities as defined in KSP is directly proportional to the ratio of the luminosities as defined in real life. So if you have a star that has 1/2 the total energy output of the stock sun, you should assign it a luminosity of 680. I always use the parameter "luminosity", I don't know if "solarLuminosity" is also valid of not. * I don't know where this error originated, but it's been copied over and over again from one config to another.

It was frustrating for the GPP developers as well. We have a two-star system and struggled for months trying to figure out how to deal with the solar panel bug. Kopernicus 1.2.2-9 and 1.3.0-4 now fixes it. Kopernicus now correctly recognizes the difference in the stars' luminosities and adjusts the output of solar panels accordingly. Be advised, however, if you use the mod Kerbalism, it doesn't play well with Kopernius Solar Panels. Kerbalism still need to figure out a solution and catch up. That's the only bug that I'm aware of.

@Tyko, something you might try doing that should make everything easier is to delete all the custom planet-specific changes. You can then make all your changes using the global settings. To delete the planet-specific changes, open the file SSRSS_Sigma.cfg and make the following edit: /////////////////////////////// (delete everything between the lines above and below) /////////////////////////////// Now modify the global settings until you get what you want. For example, you might try something like this: @SigmaDimensions { // Base Settings @Resize = 0.25 @Rescale = 0.25 @Atmosphere = 0.88 @dayLengthMultiplier = 0.5 // Advanced Settings @landscape = 2 @geeASLmultiplier = 1 @resizeScatter = 1 @resizeBuildings = 1 @CustomSoISize = 0 @CustomRingSize = 0 @atmoASL = 1 @tempASL = 1 @atmoTopLayer = 0.75 @atmoVisualEffect = 1 @scanAltitude = 1 } Of course you'll also need to adjust the cloud altitude multiplier, but you'll need to figure out what value to use.

What problem do you have with the atmospheres? @atmosphere = 1.3 is way too high. That is going to stretch the pressure and temperature curves out to unrealistic values. Since you're going from a 10x RSS model down to a 2.5x model, if anything you want to compress the curves, not stretch them. I'd recommend setting @atmosphere to somewhere in the 0.8-0.9 range for 2.5x scale, but definitely not greater than 1 in any circumstance. If you want to change the heights of the atmospheres further, you should do it using @atmoTopLayer. This factor either trims off the tops of the existing pressure and temperatures curves (if <1), or extrapolates them out beyond where they leave off (if >1). The final height of the atmosphere will be the multiple of @atmosphere and @atmoTopLayer. For example, for Earth in SSRSS we used @atmosphere = 0.8 and @atmoTopLayer = 0.625. Earth's original pressure and temperature curves in RSS go to an altitude of 140 km. So what these factors do is first the curves are compressed to 140*0.8 = 112 km by rescaling the altitudes and slopes. We then trim off the top 42 km of the rescaled curves leaving us with a 70 km high atmosphere, i.e. 112*0.625 = 70 km.

SSRSS isn't really made for doing what you suggest. It does a lot more than just resize everything by some global factor. There were a lot of planet specific changes made, some of which may not work as intended if you go and change the scale of the solar system. If you want to give a 2.5x system a try, I recommend you start by making the following changes: (1) Find and open the file SSRSS_Sigma.cfg. (2) Search for any occurrence of @Resize and multiply the factor by 2.5. (3) Search for any occurrence of @Rescale and multiply the factor by 2.5. (4) Search for any occurrence of @atmoTopLayer and multiply the factor by 1.3. (5) Save the revisions. These changes should increase all distances and sizes by 2.5x what they are in SSRSS, and increase the heights of the atmospheres by 1.3x. However, I can't guarantee that everything else will work right. For instance, I have no idea if the terrain will look right in proportion to the resized bodies. If not, you may have to change all the @landscape factors. There could also be some rotation periods messed up, and the moon might not show the correct face toward Earth. If you need to change any of the @rotationPeriod or @initialRotation settings, these can be found in the file SSRSS_Kopernicus.cfg. I have no idea if any of the visual enhancements will be affected because that's all Galileo's work. Just be aware that there was a lot of tweaking and customizing that went into SSRSS to make it work at the size that it is. Galileo and I can't predict or be responsible for what might happen when you start changing things.

Woops. Sorry about that. I've fixed my original post so it doesn't happen again to somebody else.

Mun and Kerbin have the same LAN, so that simplifies things. To stop solar eclipses from happening every new-Mun, you'll have to give Kerbin and Mun different inclinations. Anything less than a couple degrees difference in inclination means that you'll still have at least a partial eclipse every orbit, with Mun's limb grazing the Sun. For there to be a clear separation between Mun and Sun (at the times of greatest separation), the difference in the inclinations needs to be greater than 2 degrees. How much greater is entirely up to you. Mun will pass directly over the face of the Sun only when new-Mun occurs at the same time that Mun at or near one of its nodes*. Be advised that inclining Mun's orbit means that it will no longer orbit around Kerbin's equator. This means that getting to Mun will be more difficult, much like getting to Minmus. * Note that total solar eclipses shouldn't ever occur in KSP. This is because Mun has a smaller apparent diameter than Sun when viewed from Kerbin (1.9o vs. 2.2o). Solar eclipse should actually be of the annular type. The fact that Sun completely disappears during a solar eclipse is an error.** ** It looks to me that the Sun behaves as a point source of light. A body doesn't need to completely cover the Sun to produce an eclipse, it just needs to cover the center point. When the center point is covered, the sunflare is extinguished, and when the center point is uncovered, the sunflare returns. The same thing happens during sunrises and sunsets. This is why Mun is able to produce what looks like total solar eclipses even though it shouldn't.

OK, that's a valid point. If one just reads the OP and not the entire thread, they'd definitely miss out on a lot of important follow up discussion. I can see how somebody could possibly misinterpret to intent of the OP and read as a recommendation to eject from the altitudes given. However, even in the OP I qualified my statements with the following:

Agreed. It is easy to say that one should drop into an elliptical orbit and eject at periapsis, but executing it is an entirely different matter. You can't just place the periapsis at any old spot. The maneuver has to be executed in such a way the spacecraft passes through periapsis at the right place (proper ejection angle) and at the right time. The analysis made in the referenced thread just tells us that if we start out at an altitude higher than the gate orbit, then we should be able to eject using less Δv if we first drop the periapsis to just above the atmosphere, and then eject when passing through periapsis. That's what the math tells us. However, if the execution is off, we could end up with a suboptimal burn because of incorrect ejection angle or some other misalignment or mistiming. We could waste enough Δv that we squander any potential savings. What mathematically sounds like an advantage could actually end up costing us more. That's why I don't intend to propose any particular set of rules for what a person should do or when. It is up to the each individual to decide for themselves what they fell comfortable doing and what they think they can properly execute. However, knowing what the math says is an important first step.

The "rule" to which I refer is the often stated incorrect claim that it is always best to eject from the lowest possible orbit to take advantage of the Oberth effect. The only reason for the thread in question was to show that that's not necessarily true. For me the thread was nothing more than reporting an observation, and then spending the next several pages trying to find a mathematical explanation for it, and exploring the implications. This lead to the discovery of something none of us had ever heard of before, a gate orbit. I suggested in the thread that it is up to each individual to use the information as they see fit and to determine whether or not they can find a practical application for it. No attempt was made to replace an old rule (or fallacy) with a new rule. We simply went were the math took us. What I enjoyed about that thread was that those of us involved were making some real time discoveries (new to us at least). That's not true. A considerable amount of the thread discussed elliptical orbits with ejection at periapsis. One of the implications of a gate orbit is that it provides a dividing line between when it is best to eject directly from the initial orbit, versus lowering the periapsis and ejecting when passing through periapsis. Much mathematical analysis was devoted to this issue (did you not read it?). The math shows that if you start out above the gate orbit, it is most efficient to lower the periapsis to just above the atmosphere and eject from there. On the other hand, if your initial orbit is below the gate orbit, it is most efficient to eject directly from the initial parking orbit without lowering the periapsis. (That's not a rule, it's a mathematical fact. Use the information as you like to make your own rule.)

Ah hah, that explains it. Of course I never tried to scan the gas giants, I went straight to the moons. I'm glad it's an easy fix. I also had problems with the planets of a companion red dwarf star not showing up in the menu. I assume this should fix that problem as well (i.e. they didn't show up in the menu because I didn't first scan the star)?

The units are body radii, with 3 implied decimal places, and measured from the center of the body. So the numbers 30000 and 40000 means that the rings extend from 30 to 40 radii from the center of the sun, where 1 solar radius = 261,600 km. (edit 1) Oops, I didn't see that the question has already been answered. (edit 2) Also note that the inner and outer radii mark the inner and outer edges of the ring texture. It's possible the texture could be transparent in parts, making the ring appear smaller than the texture.