Sigma88

it depends on which mod you choose, for some I use that mod star, for some I create a new one. before adding a mod to GN I always ask the devs so they can choose the type of star and name, so I assume all of them are ok with the star they get in GN

@Olympic1 do you happen to know if the * workaround is still required in 1.3.0 ?

I understand, I would nag the devs who include miniavc to begin with I love KSP-AVC, and I have .version files in all my mods, but I don't like forcing it on people like miniavc does

Now I'm curious, what are you using it for if you don't want the notifications?

I've released a new version of Kronometer (v1.3.0-2) it contains a fix to an error in calculation for non-leap-dates and I've added a true/false option to force time unit values to be integers see the OP for links, and the github page for downloads and readme

I haven't tried to get a specific color, but is it so difficult? I mean, once you are in the ballpark it should be a case of tweaking it up here, down there and the final result should be pretty close to what you want alternatively you could make a spreadsheet and note down for different values of wavelength the colors the sky has and try to reverse engineer the formula from there no, just add randomMainMenuBody = true to all the Body nodes you want to get considered

mainMenuBody

there are two things that come into play here 1- transformscale, the stock one is too low ( transformScale = 1.025,1.025,1.025 ) it is calculated using the outerradius, what I do with SD is double the distance from the radius, the radius is "1" and the outerRadius is "1.025" so the distance is "0.025", double that = "0.05" so I set transformScale = 1.05, 1.05, 1.05 2- the color, since the shader of the sky follows a fixed gradient, and you can only set 1 color, you need to pay attention to not choose one that is too bright if you do, the relationship transformScale / outerRadius won't necessarily be the same I described above. but yes, you will find that most of the times the color tend to stay in a certain range since the shader becomes crap otherwise which means the doubling is still a pretty good rule of thumb I checked and kittopia will not give you a preview of the color, but if you edit the wavelength while on the planet the changes are showed live

I think kittopia tech does that, when you change the numbers you get a preview of what the color is btw, this is the blue to black effect I was talking about it's not as clear on Gael as it is on kerbin but you can still get it. you'll find out that the effect disappears when you install SD (because I wrote SD so that it tweaks the planets so they don't do that)

RGB, you have low red, middle to high green, very high blue that means it's probably midway between cyan and blue, a very light blue, kinda like the color of the sky

wavelength (or lightcolor) = 0.5^-0.25, 0.7^-0.25, 0.9^-0.25,1 that's the closest you can get or, just use kittopia to edit them live until you are satisfied

it's not that those two parameters are very similar. kopernicus stores the info from lightcolor into wavelength (see here) so there's literally no difference between the two looking at the code now I noticed that when using lightcolor it will create an AFG if it is missing, so adding the AFG should really not be required. unless both inner and outer radius default to zero inner and outer radius are just there to define from where to where the gradient goes. all stock KSP bodies have the same, which is from 0.975 to 1.025 planet radii raising the outerradius further than that can cause serious problems if you don't also change the the transformscale for the AFG actually, the outerradius used by stock is already too high, leading to that weird sky transition you can sometimes see where it goes directly from blue to black without fading (see here)

AFG/wavelength and Atmosphere/lightcolor are the same thing I don't remember right now, but I don't think the AFG node is mandatory, I think it gets added by default and can turned off using a bool (useAFG or something along the lines of that)

are you using mods that are updated to 1.3.0?

Updated to KSP 1.3.0 (just needed a recompile)

I'll try to take a look, but I'm no scatterer expert

I am updating this to 1.3.0 so that KSP-AVC won't annoy ppl that have it installed no major changes from the previous version were required

I have improved the descriptions of all parameters available in SD you can find links in the OP

no, KSP uses the power of negative 4 to go back from the intended result to what you feed KSP you need to use the reverse operation which is power of negative 0.25

you are using lightColor = 0.58,0.13,0.13,0.5 what KSP will show is r^-4,g^-4,b^-4,0.5 so in your case is a very bright cyan color if the color you want to get is 0.58,0.13,0.13 you needto use 0.58^-4,0.13^-4,0.13^-4 which is approximated to: lightColor = 1.146,1.665,1.665,0.5

I'm still waiting to see the cfg

thanks I checked the cfg and I cannot see anything wrong with it, other than the fact that you are trying to delete useTheInName even if most likely it isn't there to begin with

could you try with this: (just to make sure it actually is callisto) @Kopernicus:FOR[SA] { !Body[~name[Sun],~name[Kerbin],~name[Jupiter],~#name[Callisto]] {} } if you still see artifacts with this I will need: mm cache without SD mm cache with SD but no resize mm cache with SD and resize I could also use the same mm cache files from 1.2.2 with the cfg I posted above, to compare the systems and see what has changed

Yes that's what I was thinking IIRC it's color = r^-4, g^-4, b^-4,a

In the option used by ohiobob the year is not supposed to end on a day boundary. Usually a year starts with day = 0 (later offset to show day1) When the last day of the year ends, the left over time is displayed as next year's "day -1" (later offset to 0) The code had a couple of errors that I've now fixed in the dev version (probably copy paste errors since some line didn't make any sense) Math.Floor is used to make the code work with both positive and negative values of time I'm still testing to make sure everything works fine but all tests I made are promising. The problem here wasn't the error in the number but the fact that the number was supposed to be different. If the error is bigger it means it is either introduced on purpose (eg. 365.25 days in a year) or it's just bad config syntax A bigger error would also give more consistent results as there would be no issues of time lost to rounding errors.