OhioBob

@Sigma88, I've got something new to report. I just created a new game to start over from the beginning. Year 1 actually starts on Day 0 (I mistakenly believed it started on Day 1). So that means year 1 runs from day 0 to day 403. Year 2 then runs from day 1 to day 404. Year 3 runs from day 2 to day 405. And year 4 starts on day 3, which is where I stopped. So the problem isn't that I have the wrong number of days in the year - they all have 404 days. The problem is that the start day of each subsequent year is advancing 1 day. Does that still sound like rounding, or could there be something else causing this?

I thought that might be the case. If I can find a way to fix it via cfgs, I will. Otherwise we'll just have to live with it. By the way, I never noticed this problem with ClockFixer in Kopernicus. Is there anything you did differently then that could be implemented now?

I just sent you files, but disregard Gael's SMA in its cfg. For the 2.5X version we're using, semiMajorAxis = 34948895994.9601.

Yes, I can do that. I'll do it via PM because the latest cfgs are a dev version. OK, this is weird. I just time warped through a second year and this time I got a day 404, but when it flipped over to the next year it was on Day 2. It went from Y2, D404, 9:59 to Y3, D2, 0:00.

I'm pretty sure I did use the latest SD. I had fresh install of KSP 1.3.0 with no mods other than GPP and Kopernicus 1.3.0-1. I then downloaded and installed SD 0.8.0.

@Sigma88, I just tried Kronometer out on GPP and it works great, but there is just one thing I'm not so sure about. We already had GPP set up to work using ClockFixer in Kopernicus. To avoid the whole leap year problem, we tweaked Gael's semimajor axis to make sure the year ended on an exact integer number of solar days. So to configure Kronometer I just made the following MM patch: @Kronometer { @useHomeDay = true @useHomeYear = true } which should make it work just as it did before using ClockFixer. The problem is that I'm not sure the year is ending on the right day. For the particular rescale I was using (2.5X), we have a 10-hour solar day with exactly 404 solar days in a year (405 sidereal days). The calendar turned over from Y1, D403, 9:59, to Y2, D1, 0:00. Shouldn't there have been a day 404 before the calendar flipped over to the next year? I think the calendar is only giving me a 403-day year. Had we started with day 0, then you're right, but since we start with day 1, I think there needs to be a day 404. Maybe you're right and I'm wrong, but I need some convincing.

@Sigma88, it looks like there's a mistake on your syntax page. The instructions on useLeapYears says the same thing for both true and false... useLeapYears Boolean, default value = false When 'false': if the year ends halfway through a day, the clock will go: Year 1 Day 365 ==> Year 2 Day 0 (Instead of starting directly with Day 1) Day 0 will last untill Day 365 would have ended, then Day 1 will start. When 'true': if the year ends halfway through a day, the clock will go: Year 1 Day 365 ==> Year 2 Day 0 (Instead of starting directly with Day 1) Day 0 will last untill Day 365 would have ended, then Day 1 will start. In both cases: a new day will not start earlier just because a year has ended.

Be advised that Realistic Atmospheres, version 1.2.3 works with KSP 1.3 and Kopernicus 1.3.0-1.

Eve Optimized Engines, version 1.2.0 works with KSP 1.3.

@Pretorian28715, if you use my supplemental spreadsheet, it includes a means to determine star type from solar constant and distance. Just enter the solar constant in cell C4 and the distance cell C5. From the entered values it will calculate the star's luminosity in cell C10. The spreadsheet then references a table of main sequence stars and returns the star type that matches the luminosity. This star type is given in cell C18. Alternatively, if you have your mind set on a particular type of star, you can adjust the numbers in cells C4 and C5 until you get the type of star you want. This way you can determine how far away from a particular type of star you must be to get the desired solar constant.

As long as the planet is big enough and has the right temperature to retain the gas to begin with, it should be able to hold onto it indefinitely. If a gas is lighter than the "minimum molecular weight retained", it will eventually leak away into space and be lost. And of course there are some gases that are removed by natural processes and need constant replenishment by other processes. If the process that supplies the gas stops, the gas will eventually be removed from the atmosphere. Solar wind will also strip away an atmosphere, particularly if the planet has no magnetic field. There's no easy answer. You're just going to have to make an educated guess.

@Pretorian28715, although I haven't officially released a formula to compute surface pressure, there is a method I sometimes use as a rough guideline to help me determine the surface pressure of one planet versus another. If you use my atmosphere spreadsheet, there is a number given in cell M33 titled "Minimum molecular weight retained." The lower that number, the more effective the planet is at retaining an atmosphere. Also important in determining the surface pressure is the surface gravity. If the atmospheres of two bodies have the same mass per unit area, the one with the greater surface gravity will have the higher surface pressure (where surface pressure is weight per unit area). So what I end up doing it taking the planet's surface gravity and dividing it by the minimum molecular weight retained. This gives a parameter that can be used to estimate roughly the ratio of one planet's surface pressure to another (assuming the planets evolved similarly). The surface pressures can still vary considerably, but at least this gives us something to start with so we're not just making wild guesses. (edit 1) If forced to write a formula, I'd use P = 5 * g / M where P is surface pressure in atmospheres, g is surface gravity is standard gravities, and M is minimum molecular weight retained in g/mole. The constant 5 is used so that when the formula is applied to Earth we get a surface pressure of about 1 atmosphere. Let me remind you that this is only a very rough estimation. Wild variation is possible. (edit 2) For gas giants, I just use a standard value for the datum level pressure. For stock sized planets I typically use 15 atmospheres, only because that's the pressure at Jool's datum. For RSS we used a pressure of 1000 atm. Whatever value you decide to use, I recommend you use the same for all gas giants.

For making an atmosphere, I recommend you use the tools I've developed for this, which @Galileo just linked too. To answer your specific question, no, I have not been able to derive any particular formula to determine how much atmosphere a planet should have. There is a formula to determine what gases a planet should be able to retain based on size and temperature (included in my spreadsheet), but not what a planet's surface pressure should be. Just look at our own solar system. We have Earth and Venus very similar in size, yet Venus has nearly 100 times the surface pressure. And then we have a small body like Titan that has nearly 1.5 times Earth surface pressure. (And considering Titan's low surface gravity, the mass of the atmosphere per unit area is about 10 times Earth.) And then we have other bodies with extremely thin atmospheres. There is just so much extreme variability that coming with a formula has proven impossible. For most other parts of the atmosphere modeling process I've been able to come up with formulas to at least make some suggestions, but deciding what surface pressure to give your planet is still entirely up to you. Generally speaking, I think the larger and colder a planet is, the more likely it is to have a think atmosphere. But other than that, I don't have much advice.

Other than the PQSMods thing, I don't see anything obvious. There are some things you could have added but didn't, like timewarpAltitudeLimits for example. When you don't specify something like that, you'll get the values of the template. I presume you'll eventually add biomes and an atmosphere?

You didn't mention the textures. Did you download and install them? There are two downloads, GPP and GPP_Textures. After installing GPP into your GameData folder, you must copy GPP_Textures into your GPP folder.

That's the old fix for version 1.2.2 (if you do that in version 1.2.3, it will break things). The new fix is much better. I won't bore you with details, but you should now get the correct solar panel power output at both Ciro and Grannus. However, the fix only works with the Kopernicus bundled in the GPP download. You must use the bundled Kopernicus, do not download it separately.

There have been some ongoing issues with solar panel power output. In this thread we've suggested some fixes meant to remedy these problems. If you were playing without all the fixes, then it's possible you were getting a power output way greater than it should have been (about 32 times greater). GPP version 1.2.3, if installed correctly, incorporates all the fixes and should give you the correct power output. This is likely why you are seeing a reduction from your previous installation. What you are getting now should be correct. If you put a 3x2 or 1x6 solar panel in orbit around Gael, you should get a power output of about 1.64.

Now that I've had some time to think about it, no, we can't do that. The chargeRate factor applies to all solar panels everywhere. We can't lower the chargeRate at Grannus below the ratio of its luminosity to Ciro's luminosity. The only way to decrease the chargeRate at Grannus is to artificially lower its luminosity. And if we lower the luminosity, we lower heating rates below where they should be. So there's no way to have both a reduced chargeRate and correct heating rates at the same time. Best just to keep the luminosities where they are.

I think MaxL_1023 is saying that the solar panel power output should be even less than luminosities imply because Grannus radiates much of it light in a part of the spectrum where solar panels do not work efficiently. So while Grannus has 3% of Ciro's luminosity, solar panels might produce only 1-2% (or whatever the right number is).

We could, but it might confuse people who don't know that. We'll discuss it and decide.

@TheRagingIrishman, you're awesome man! That's perfect. Thank you so much.

I don't know if the multiple star/luminosity/solar panel problem is something in Kopernicus or something in KSP itself. Either way, it's frustrating. I recently exchanged PMs with one of the KSP devs and gave him a wish list of fixes. One of these was the multiple star problem. I was told that they'd discuss it and possibly put it on their bug tracker. I have no idea if anything will ever become of it.

The presumption is that Kerbal and human technology have developed along a similar timeline. My article is written assuming a 1950s level of technology. Adaptive optics didn't become practical until the 1990s.

I doubt I'll ever get around to making a book because my priorities are elsewhere at the moment. I just don't see the motivation to do so returning. When I did consider making a book, I was planning to simply make it a PDF that could be downloaded for free. Although a hardcover coffee table book would be terrific, I've never considering absorbing the expense to do such a thing.

Post deleted - instructions previously posted here are no longer applicable.