OhioBob

I'm glad it's working for you, but something is still messed up. The solution I suggested is only a temporary one to fix your current problem. I don't know what's going to happen when we switch to 1.3.0. The next version of GPP will remove the file SolarPanelChargeRate.cfg because the solar panel fix is now incorporated in Kopernicus. Therefore if the problem returns, we're going to have to find a different solution. When you make the switch to 1.3.0, it would be helpful if you could do some testing to see if we can figure out what's causing the problem. For instance, install only GPP and the minimum required mods (Kopernicus, etc.) and run a test to check the solar panel energy flow. Then install your mods one at a time* and repeat the test until you can isolate what mod is at fault. If a third-party mod is causing the problem, it's likely going to be the responsibility of that mod developer to make their product compatible with Kopernicus 1.3.0+ (or perhaps Kopernicus is at fault). There may not be anything we can do on the GPP side of things because it is no longer us that is implementing the solar panel fix. * You probably don't have to install every mod individually, just the ones you suspect might be the source of the problem.

Yep, going back to GPP 1.2.2 is certainly a possibility. But deleting SolarPanelChargeRate.cfg should return 1.2.3 back to what it was in 1.2.2. I think the result can be achieved without actually switching versions. Of course the problem we had in 1.2.2 was that solar panels near Ciro were overpowered, to which the fix was to change Grannus' luminosity to 1360.

Try deleting the following file and see what happens: GameData\GPP\GPP_Configs\SolarPanelChargeRate.cfg In plain vanilla GPP 1.2.3 (i.e. no other mods), solar panels will be overpowered without the above. We created that .cfg to factor solar panels back down to where they should be. In your game it almost seems like the factor is being applied twice, though I have no idea why that would be. Maybe deleting the file will return things to where they should be. Other than that, I'm not sure what else I can suggest. As long as you have all your mods installed, there's little I can do to help diagnose what is at fault. (edit) If deleting the file alone doesn't fix it, then try deleting the file and change Grannus' luminosity to 1360. Let me know what happens.

It might not be a good idea to bother him too much because the current product with KSP 1.2.2 and GPP 1.2.3 is on the verge of obsolescence. Kopernicus 1.3.0 includes its own solar panel fix, thus we're having to scrap what we did in GPP 1.2.3 and change things to work with the new Kopernicus. Kerbalism may have to change as well. It just seems futile to me to put any significant effort into tracking down this bug. The current product is about to be discontinued, and there's no guarantee that whatever solution we come up with at this time will even help us in the next version. I think we should just push ahead and get our 1.3.0 compatible versions ready. If after that the problem still exists, then we'll have to figure it out. At least then we'll know we're putting our efforts into a long-term solution.

Yes, you can check it using the "Thermal GUI" in the debug menu, but I really don't think that's your problem. If you're using GPP 1.2.3 with the Kopernicus that is packaged with it, I don't see why your stock solar panels are not producing the correct energy flow. Unless there is some conflict with one of the mod you're using. Have you tried uninstalling Kerbalism? If you can, also give it a try in stock size and see if you get the same result. I don't think that should make a difference, but it will be good to eliminate it as a possibility. (You probably should backup your save game just in case changing scale messes anything up.)

Look in GameData/GPP/GPP_Planets/Grannus/Grannus.cfg. Open the file and look for Luminosity = X. The X should equal 42.

I don't know how Kerbalism is affecting things. You might try it again without Kerbalism installed to see what the stock panels give you. One thing that could give you ~0.05 e/s around Ciro is if you changed Grannus' luminosity to 1360. Changing Grannus' luminosity was a fix that we suggested for GPP 1.2.2, but you don't want to do that for 1.2.3. Did you happen to change that?

I don't think there's anything is the rescale configs that should mess up solar panels. I really don't know anything about Kerbalism, so I can't be any help with that. But I can probably debug what's happening with the stock solar panels if you can give me some information. I need to know what your solar panels are producing in order to know if you're getting the right number of not. Can you put a solar panel in orbit around Ciro at a distance of 1 AU (about 13,983,000,000 m at 1x, 89,490,000,000 m at 6.4x) and check the energy flow. Then do the same thing around Grannus. If you use a 3x2 or 1x6 solar panel, you should get about 1.64 when 1 AU from Ciro, and about 0.051 when 1 AU from Grannus.

We implemented a solar panel fix in GPP 1.2.3. It fixes stock solar panels, but I have no idea about Kerbalism. The fix only works if you use the Kopernicus that is packaged with the GPP download. Don't download and install Kopernicus separately, it won't work. Our next GPP release will work only with KSP 1.3 and Kopernicus 1.3.0-x. Kopernicus has made a bunch of changes in 1.3.0, one of which is their own solar panel fix. The changes are drastic enough that there is no forward or backward compatibility. If you're using KSP 1.2.2, you're going to have to use GPP 1.2.3 with the packaged Kopernicus. And if you're using KSP 1.3, you're going to have to wait on the next GPP release.

That part about transformscale is pretty useful. I'm making a note of it for future reference. Thanks. Yeah, I always use the preview in Kittopia to figure out what wavelength color (or lightcolor) I want to use. I'd like to be able to take 256 color RGB and convert straight to wavelength, but I'm still looking for an equation to do that.

OK, I know what you mean now. That's what I was talking about when I wrote, When I adjusted the outerRadius settings for GPP, I tried to eliminate or at least minimize the effect. I found that it varied quite a bit from planet to planet.

If those three colors red, green, blue in order, the obviously the invWaveLength is heavy in blue and low in red. That part I see. But is there some way to convert between that and a 256-color palette?

I don't think that works. waveLength = invWaveLength^-0.25, or invWaveLength = wavelength^-4. But in neither case do the numbers seem to correspond to RGB colors. For instance, for Kebin we have, waveLength = 0.65,0.57,0.475,0.5 invWaveLength = 5.602046,9.473285,19.6438,0.5 but where is either of those blue? (edit) Obviously the invWaveLength is heavy on the blue end, but how do we convert between a 256-color palette and invWaveLength?

I tweaked those default values quite a bit for GPP and I didn't notice any problem, but maybe I just didn't investigate enough. Using a one size fits all approach I thought made the atmospheres of some planets look pretty crappy from low orbit. I customized the radii settings for each body. By the way, the AFG node has a waveLength color and an invWaveLength, where invWaveLength = waveLength^-4. But I don't see were either of those relate to normal RGBA color. If I want my sky to be, say, 128,179,230 (0.5,0.7,0.9), I still haven't figured how to convert that to a wavelength color.

I've always had more luck getting it to look the way I want using AtmosphereFromGround.

You don't have an AtmosphereFromGround node. You need something that looks like this, which are the settings for Kerbin: Atmosphere { AtmosphereFromGround { innerRadius = 599625 outerRadius = 615000 waveLength = 0.65,0.57,0.475,0.5 } } The AtmosphereFromGroundNode has a bunch of other settings too, but I don't know what they do. I generally just mess with the three shown above. The inner radius is generally just a little smaller than the planet's radius, and the outer radius is generally somewhere around 3% larger than the planet's radius. It can vary though. You'll just have to play around with the settings until you get something that looks good. If you choose wrong you could end up with a very thin atmosphere, or one that has a sharp edged boundary with space. It's just trial and error. To select the color, use KittopiaTech. Choose your body, and then select 'Atmosphere Editor'. Find waveLength and click the 'Edit Color' button. Move the sliders back and forth until you find the color you want.

Ah, that makes sense. Rounding off to the nearest second sounds like a reasonable solution. That tiny bit of rounding could cause things to get a little bit out of sync, but insignificant for the time periods we're liking dealing with. (And in my case, the rounded off value is really the value I want.) Must dayLengthMultiplier be a number, or can it be an operation, e.g. dayLengthMultiplier = 5/3 ?

Here you go: http://www.braeunig.us/KSP/MMcache.zip

No difference. Years are still starting at Day 0. I put everything under the same @Kronometer{} node, that shouldn't make any difference, should it?

This works like a charm. I started a new game from the beginning and time warped through several years. Every new year started right on schedule just like the one before it. The only thing that I think is a little weird it that each year starts with Day 0. That's not a big deal and I can certainly live with it, but having a Day 0 just seems odd to me. I would think the year should start with Day 1.

Yep, I figured that out just as you were typing it (except I forgot the @). I'll give it a try.

How do I write that? Would I do something like this: Kronometer { CustomTime { Year { Value = 14544000 } Day { Value = 36000 } } }

I'm glad you implemented a solution that will fix some of the problems. If I notice any mods that are still broken, I'll post in their thread requesting they make the necessary change. How about Transfer Window Planner? Do you know if that one works with Kronometer? KAC and TWP are two of the mods I most rely on, so if those both work, I'll be pretty happy.

Another issue I had when using ClockFixer (haven't tested it with Kronometer yet) is that some other mods are not compatible with it. These other mods are apparently not detecting that the length of day has changed. For example, Kerbal Alarm Clock. KAC alarms go off at the correct time - probably because the internal calculations are based on seconds - but the display is incorrect. For instance, if an alarm is set for 30 hours, the display shows five 6-hour days instead of three 10-hour days. I've seen similar problems with other mods, but I can't recount all of them. I understand this isn't a Kronometer problem per se. But is there any recommendation you can make that would help remedy these compatibility problems?

Is there any code you could add that would ensure each new year always start with Day 1?