OhioBob

Be careful if you're playing GPP + GEP. GPP has not yet been updated for the new scatterer (0.0540), so to play GPP you have to continue using the old scatterer (0.0336). And the new GEP (1.0.1.4) is not compatible with the old scatterer. So if you're playing GEP with GPP, you have to continue using the old GEP (1.0.1.3) with the old scatterer configs. Once GPP updates, you'll be able to combine all the new versions. Of course, if you're not using scatterer, then it doesn't matter. You should be able to use the new GEP in that case without any problems.

UPDATE Version 1.0.1.4 Changelog Updated scatterer configs for v0.0540. (Not backwards compatible) Updated HazardousBody for Kopernicus 1.6. Deleted Epona clouds. (Couldn't make it look right) Revised rim and fog color ramps Added support for Kerbal Health. See opening post for download link and instructions.

UPDATE Version 1.0.8 Brought back parts that got hidden in KSP 1.6 (1.875m nosecone and adapter). See opening post for download link and instructions.

I've solved the problem of the dark limb artifact and the scatterer not rendering below the highest config point altitude. Sorry, @blackrack, user error. My mod has a bunch of installation options, so I actually have two planetsList for different types of installations. I changed one list but forgot to change the other. Adding flatScaledSpaceModel = True seems to have fixed the issue. Now I just have an issue of a sudden brightness change when passing through the last config point. It's much brighter above than below. I'm still trying to debug. EDIT: I think I've traced the brightness problem to postProcessAlpha. Changing postProcessAlpha alters the atmosphere brightness when below the final config point altitude, but not when above it. EDIT2: Correction... the issue with postProcessAlpha doesn't occur when passing through the last config point, it occurs when passing through PQS deactivateAltitude.

@blackrack, I'm experiencing some of the same problems reported by @evileye.x, @Citizen247, and @BadOaks. But I'm working in regular stock scale, so the problems aren't just associated with rescaled systems. I'd like to also add one additional observation. People have commented that things look good once the transition to scaled space takes place. I don't think that's it, at least not in my case. For me it's when I cross the altitude of the final scatterer config point that things seem to fix themselves. For example, in the following images my final config point is set at an altitude of 160000. In the first screenshot I'm at an altitude of 161000, and in the second 159000. You can see a marked difference between the two. In this case my PQS fades out at 140000 and deactivates at 180000, so I don't think that has anything to do with it. EDIT: The dark artifact along the planet's limb appears between approximately, 30% cfgPoint1 + 70% cfgPoint2, and <100% cfgPoint3. Either below or above that range, everything looks good with no dark artifact.

The ! means no. If it had been NEEDS[BetterSRBs], then BetterSRBs would be required for the change to execute.

UPDATE Version 1.0.7 Expanded ReStockPlus support (0.625m SRBs now included). See opening post for download link and instructions.

OK, I see the problem right off the bat... NEEDS[!BetterSRBs] That means that the gimbals are added only if BetterSRBs is not installed. So the problem is not BetterSRBs. Whoever wrote that MM config intended that their changes not be made if BetterSRBs is installed. They apparently want BetterSRBs to take precedence in that case. It's my intend with BetterSRBs that the RT-5 and RT-10 are primitive technology for which gimbaling is not yet available. I don't introduce gimbaling until the Thumper. I don't intend to change that. Edit: If you want the gimbals, then delete the :NEEDS[!BetterSRBs] part from the config.

@vardicd, I've added the Mallet and Striker to the ReStockPlus config. I haven't published a release yet. I don't know what the deal is with gimbals. BetterSRBs doesn't do anything with gimbals on the RT-10. And I don't see anything in the ReStock config that adds gimbals to the RT-10.

I can add the Mallet and Striker easy enough. I just didn't know they were there.

@vardicd, I just re-read you initial post and I guess I'm confused about what ReStock actually does. I had the understanding that it did nothing but makeover the stock textures while retaining everything else about the original parts. But now you're talking about a "Mallet" and a "Striker" and adding gimbals. I didn't think those kinds of changes were within the scope of ReStock. I don't really have the motivation to figure Restock out.

@vardicd, I got a pull request on GitHub to add the Anvil from ReStockPlus. I assumed it came from one of the ReStock guys, but now that I think about it, I'm not sure it was. It could have been some third party. The ReStock guys may not know anything about it.

The ReStockPlus configs included in BetterSRBs were provided to me by the Restock guys. I've included only what they told me to include, so if something's not there, I assume they wanted it that way. I'm not very familiar with ReStock/ReStockPlus, so I can't talk intelligently about it. If there is something else that you think should be included in BetterSRBs, you may need to talk to the ReStock developers about it. Edit: By the way, my updated says it supports ReStockPlus, not ReStock.

Oh. About the same. The farthest planet in GPP is 38.8 AU, while Pluto is 39.5 AU. But GPP has only three gas giants. GPP has an ice planet where Neptune would be, and a second ice planet where Pluto would be.

GPP is stock scale, so it's way smaller than RSS. The home planet in GPP is the same size as stock Kerbin.

@PatelPratham, delta-v is proportional to the square root of the rescale/resize factor. So for a 10x system, the delta-v is increase by a factor of 10^0.5 = 3.16 over what it is at 1x.

75 km is correct. It was changed to that in v1.3.0. It was 70 km in earlier versions.

UPDATE Version 1.3.1 Changelog Revised Tylo's atmospheric gradient. Updated Tylo's atmosphere for scatterer v0.053. Updated HazardousBody for Kopernicus v1.6.x. See opening post for download link and instructions.

Perhaps it would be even better to also redefine a minute to be 20 seconds long. That way a day will have 24 hours and an hour will have 60 minutes. @Kronometer:AFTER[SSRSS] { @CustomTime { @Hour { value = 1200 } @Minute { value = 20 } } }

Are you saying you want to the clock to show that 24 hours elapse during the 8-hour rotation period of the planet? If so, then yes, Kronometer can do that. You can find the Kronometer syntax on GitHub. I think you might need to do something like this, which redefines the length of an hour to be 1200 seconds, or 20 minutes. That way the clock will click off 24 hours in one day. @Kronometer:AFTER[SSRSS] { @CustomTime { @Hour { value = 1200 } } } If I've misunderstood and you actually want to change the rotation period of the planet to 24 hours, then that's not a Kronometer issue. You can't do that by writing a Kopernicus config.

I think the best option is to set the clock to 24 hours in the game settings, and not use Kronometer. The main reason to use Kronometer is when the day is neither 6 nor 24 hours. But when you want a 6- or 24-hour day, those options are available in the standard game.

UPDATE Version 1.0.6 Added support for ReStockPlus. Miscellaneous config updates and fixes. See opening post for download link and instructions.

This mod doesn't per se, but I'm pretty sure Sigma Dimensions does. SD changes stuff like the flying and space thresholds, time warp limits, etc. There is no specific setting for it, but it's linked by some formula to other settings, such as the resize factor. It's all internal, I doubt there is anything you can do to stop it. However, you can write a config to change it back to whatever you want it to be after SD has done its thing. For instance, the following should change Kerbin's space threshold back to its original 250,000 meters. @Kopernicus:AFTER[SigDim] { @Body[Kerbin] { @Properties { @ScienceValues { @spaceAltitudeThreshold = 250000 } } } }

I guess the Kerbal Alarm Clock folder is GameData/TiggerTech for the same reason that the Kerbal Space Program folder is GameData/Squad.

If the dossier says 86y328d, then, yes, that's incorrect. But I compute 86y335d. Not sure why we differ. The documentation is based on a spreadsheet that includes all the values as we intended them. Otho's SMA is suppose to be 72718700000, but we apparently made a typo when the number got transferred to the config. It's much easier to change the config than it is to change the documentation. Fixing it could break some saves, but people will get over it. We tried to check the dossiers pretty closely, but many changes were made along the way. Hopefully not much slipped past our proof readers. (We got Nero's orbital period is wrong, so there could be other errors as well.) But if errors are found, they're not likely to get fixed. Editing those things is a pain in the neck, and anybody who had anything to do with it is likely very unmotivated to do anything about it. CelestialBodies.pdf is linked directly to the numbers in the master spreadsheet, so it should be correct. If you find any differences between the .pdf and the .cfg, please bring them to my attention. It could mean errors in the configs, which are easy to fix.