[KSP >= 1.3.1] Distant Object Enhancement (DOE) /L - Under new Management - 2.2.0.2 - 2024-0803

[Errol]

17 minutes ago, Lisias said:

It's about the "angular size" of the celestial body in relation to the horizon. To get your eyes screwed into not seeing the stars, you don't need too much light, a puny flashlight will do the trick. So, if you are into a lower orbit where the planet's "angular size" is considerable big, it will affect you vision into a wider FoV than the Sun, as the Sun's 'angular size" is way smaller.

I think I understand what you saying here. When you say FoV to affect vision,  are talking about the angle as the camera rotates where the effect begins to be applied? I think I agree with what you are describing here, but it still feels wrong to me. Even with the camera pointed almost straight at the sun, so the vessel is right next to the sun, there are still stars visible all around. There does not seem to be any angle I can look with the sun in view (and no planet) that will make the skybox as black as it gets when looking at the planet in low orbit. Could you artificially increase the "angular size" of the sun for this mod to make it more likely to get a completely black skybox when looking towards the sun? The fact that not much light is needed to completely mess up your night vision makes me feel like as soon as the sun is on screen at all the skybox should be solid black....so the angular size affecting the amount of dimming when the camera points towards the sun almost feels unnecessary, except that I guess this is required for the logarithmic dimming? 

Edit, and yes, I agree about the diminishing returns on things like persistence of vision on undimming and stuff. I'm mostly concerned with being able to capture screenshots and stuff with the correct look.

Edited Thursday at 04:27 PM by Errol

[Lisias]

1 hour ago, Errol said:

I think I agree with what you are describing here, but it still feels wrong to me. Even with the camera pointed almost straight at the sun, so the vessel is right next to the sun, there are still stars visible all around. There does not seem to be any angle I can look with the sun in view (and no planet) that will make the skybox as black as it gets when looking at the planet in low orbit. Could you artificially increase the "angular size" of the sun for this mod to make it more likely to get a completely black skybox when looking towards the sun?

Humm... This appears to be the new code screwing with the feature...

Can you please install the current release (2.2.0.2) and see if the problem happens the same?

I'm currently on Working Hours (don't ask how I managed time to post here, you don't wanna know), and having this information will save me a bit of time later when I came back to the issue - the thing is still fresh on my head, the time to fix this is "soon as possible", before I forget everything and need to restart from scratch...

[Errol]

52 minutes ago, Lisias said:

Can you please install the current release (2.2.0.2) and see if the problem happens the same?

Tested; skybox dimming is able to go just as dark facing the sun as it can looking at the planet in low orbit (that is to say the effect looks the same for both in low orbit). This looks correct/good enough to me as far as min and max skybox brightness caps are concerned, and also the log-gradual dimming seems good too. It would seem that 2.2.1.1 does introduce a bug that prevents skybox dimming from being fully applied when looking towards the sun.

I just want to say thank you for your efforts on this. Seeing the improvements from 2.2.1.1 despite the new bug was hugely gratifying. It's one of those subtle but hugely impactful things when you know about it. Along with having just gotten city lights working with the new scatterer true volumetric clouds the night side of LKO is significantly more visually interesting and much more similar to real orbital photography. I'm very excited, sunrise from orbit is about to get a whole lot more dramatic.

Edited Thursday at 06:35 PM by Errol

[Lisias]

1 hour ago, Errol said:

Tested; skybox dimming is able to go just as dark facing the sun as it can looking at the planet in low orbit (that is to say the effect looks the same for both in low orbit). This looks correct/good enough to me as far as min and max skybox brightness caps are concerned, and also the log-gradual dimming seems good too. It would seem that 2.2.1.1 does introduce a bug that prevents skybox dimming from being fully applied when looking towards the sun.

Thank you very much! I know exactly which line is the problem now, and also where the problem lies! (I will need to burn some neurons on this one).

 

1 hour ago, Errol said:

I just want to say thank you for your efforts on this. Seeing the improvements from 2.2.1.1 despite the new bug was hugely gratifying. It's one of those subtle but hugely impactful things when you know about it. Along with having just gotten city lights working with the new scatterer true volumetric clouds the night side of LKO is significantly more visually interesting and much more similar to real orbital photography. I'm very excited, sunrise from orbit is about to get a whole lot more dramatic.

Land a ship on the Mün and see how the SkyBox behaves as you look down or up!

(also screwed on the last PRE-RELEASE, but I'm going to fix it ASAP)

Edited Thursday at 07:54 PM by Lisias
Entertaining grammars made slightely less entertaining...

[Errol]

1 hour ago, Lisias said:

Land a ship on the Mün and see how the SkyBox behaves as you look down or up!

WOW! Something really weird now. I went back to 2.2.1.1 to test going to the Mun as you suggested. This time I already had a vessel in orbit, so I just went straight to it from the tracking center and SURPRISE, skybox dimming was working correctly when looking towards the sun! At first I had two terrible thoughts, either the bug is *dun dun dun* intermittent OR I was tripping before I wasn't remembering what I saw accurately. Decided to proceed on with testing how mun looks, because I haven't been there in a while anyway. Used the cheat menu to put myself in Mun orbit and BLAM, same bug as before, skybox only partially dimming when looking towards the sun. So I can report that something about scene change/cheat menu is involved, and your new code does seem to work properly in some circumstances. (EDIT: using cheat menu to go back to kerbin causes the bug to persist)

Edited Thursday at 08:54 PM by Errol

[Lisias]

6 hours ago, Errol said:

WOW! Something really weird now. I went back to 2.2.1.1 to test going to the Mun as you suggested. This time I already had a vessel in orbit, so I just went straight to it from the tracking center and SURPRISE, skybox dimming was working correctly when looking towards the sun!

Yep. And was exactly this phrase that ringed a bell in my dull, thick skull.

I just released 2.2.1.2 . Please try it.

TL;DR: I ditched all that code, replace a min with a max, and everything is working as expected since then.

[Errol]

1 hour ago, Lisias said:

I just released 2.2.1.2 . Please try it.

Hate to report this, but it seems like this version is not working correctly. Here is what I observed. (tested both loading a ship already in orbit, and flying a ship to orbit from the pad; no cheat menu)

-Skybox dimming seems to not be working at all when looking at the day side of the planet.

-skybox dimming seems to be only partially applied/not fully darkening when looking towards the sun, similar to the bug state after using the cheat menu to get to orbit in pre-release 2.2.1.1

[Lisias]

48 minutes ago, Errol said:

Hate to report this, but it seems like this version is not working correctly. Here is what I observed. (tested both loading a ship already in orbit, and flying a ship to orbit from the pad; no cheat menu)

-Skybox dimming seems to not be working at all when looking at the day side of the planet.

-skybox dimming seems to be only partially applied/not fully darkening when looking towards the sun, similar to the bug state after using the cheat menu to get to orbit in pre-release 2.2.1.1

Humm... I completely forgot this use case. (when something it's too good to be true, it's usually is).

So, let's enumerate the use cases so I don't lost them again:

1. When the Camera is looking into the Sun, the Sky shall dim.
   • Working on 2.2.1.2
2. When the Camera is looking into a Planet's illuminated side, the Sky shall dim.
   • Screwed on 2.2.1.2
3. When the Camera is looking into a Planet's dark side, the Sky shall be visible.
   • Working on 2.2.1.2, but probably by collateral effect
4. When the Camera is looking away from the Sun and from any planet, the Sky shall be visible.
   • Working on 2.2.1.2, but probably by collateral effect
5. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when the ground is being illuminated.
   • Screwed on 2.2.1.2

There's something missing?

Since I'm working on this thing in small pieces, I think my problem is not having all the Use Cases listed under my nose so I don't screw one by fixing another again - but, thinking a bit on what I had done in 2.2.1.2, from the code point of view it appears to be a step on the right direction.

[Errol]

29 minutes ago, Lisias said:

1. When the Camera is looking into the Sun, the Sky shall dim.
   • Working on 2.2.1.2
2. When the Camera is looking into a Planet's illuminated side, the Sky shall dim.
   • Screwed on 2.2.1.2
3. When the Camera is looking into a Planet's dark side, the Sky shall be visible.
   • Working on 2.2.1.2, but probably by collateral effect
4. When the Camera is looking away from the Sun and from any planet, the Sky shall be visible.
   • Working on 2.2.1.2, but probably by collateral effect
5. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when the ground is being illuminated.
   • Screwed on 2.2.1.2

Not sure what you mean by "collateral effect" but yes, these five game/camera states and if the are working on 2.2.1.2 seem to be what I am getting on my clean install tests.

[Lisias]

12 minutes ago, Errol said:

Not sure what you mean by "collateral effect"

Plain luck - I don't know why it works (and I should).

One of the reasons I'm struggling with this issue is because the code that appears to do the job is duplicating computations, what it's a hint that I should refactor the code again to avoid recalculating values I had already calculated - and I was trying to avoid the extra work. Oh, well...

Well, first things first. Below, you will find a HOTFIX with my last attempt. I will publish hotfixes until getting this thing right,

https://github.com/net-lisias-ksp/DistantObject/releases/tag/RELEASE%2F2.2.1.2

I didn't fully tested this one, only a couple of use cases - I will do it later, right now I need to pay attention to other affairs.

Thanks for the help!

Edited Friday at 06:33 AM by Lisias
Hit "Save" too soon

[Errol]

@Lisias Ok, I've got another interesting datapoint for you on experiemtnal-rc-0. This time I tried flying to orbit from the ground, loading crafts already in orbit from tracking station, and switching between vessels in orbit from map view. At first I thought the problem was scene change/vessel loading. But after flying to orbit, loading crafts a few times, and just generally playing the flight scene for a bit I figured this out:

For freshly loaded vessels, seemingly from anywhere (VAB, tracking station, even from the map screen while controlling another vessel) it works similar to 2.2.1.2

1. When the Camera is looking into the Sun, the Sky shall dim.
   • Working correctly (sky goes fully dim, solid black) on rc-0
2. When the Camera is looking into a Planet's illuminated side, the Sky shall dim.
   • Screwed on rc-0
3. When the Camera is looking into a Planet's dark side, the Sky shall be visible.
   • Working correctly (̷s̷k̷y̷ ̷g̷o̷e̷s̷ ̷f̷u̷l̷l̷y̷ ̷d̷i̷m̷,̷ ̷s̷o̷l̷i̷d̷ ̷b̷l̷a̷c̷k̷) on rc-0
4. When the Camera is looking away from the Sun and from any planet, the Sky shall be visible.
   • Working on rc-0
5. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when the ground is being illuminated.
   • Screwed on rc-0

But as soon as you switch from the flight scene to the map screen and back (without switching vessels), the behavior changes to this:

1. When the Camera is looking into the Sun, the Sky shall dim.
   • Working *partially* (stars still faintly visible) on rc-0
2. When the Camera is looking into a Planet's illuminated side, the Sky shall dim.
   • Screwed on rc-0
3. When the Camera is looking into a Planet's dark side, the Sky shall be visible.
   • Working correctly *̷p̷a̷r̷t̷i̷a̷l̷l̷y̷*̷ ̷(̷s̷t̷a̷r̷s̷ ̷s̷t̷i̷l̷l̷ ̷f̷a̷i̷n̷t̷l̷y̷ ̷v̷i̷s̷i̷b̷l̷e̷) on rc-0
4. When the Camera is looking away from the Sun and from any planet, the Sky shall be visible.
   • Working on rc-0
5. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when the ground is being illuminated.
   • Screwed on 2.2.1.2

Edited Saturday at 11:44 PM by Errol
EDIT: corrections for looking into planet's dark side (it was late, I was tired)

[Lisias]

17 hours ago, Errol said:

@Lisias Ok, I've got another interesting datapoint for you on experiemtnal-rc-0. This time I tried flying to orbit from the ground, loading crafts already in orbit from tracking station, and switching between vessels in orbit from map view. At first I thought the problem was scene change/vessel loading. But after flying to orbit, loading crafts a few times, and just generally playing the flight scene for a bit I figured this out:

For freshly loaded vessels, seemingly from anywhere (VAB, tracking station, even from the map screen while controlling another vessel) it works similar to 2.2.1.2

1. When the Camera is looking into the Sun, the Sky shall dim.
   • Working correctly (sky goes fully dim, solid black) on rc-0
2. When the Camera is looking into a Planet's illuminated side, the Sky shall dim.
   • Screwed on rc-0
3. When the Camera is looking into a Planet's dark side, the Sky shall be visible.
   • Working correctly (sky goes fully dim, solid black) on rc-0
4. When the Camera is looking away from the Sun and from any planet, the Sky shall be visible.
   • Working on rc-0
5. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when the ground is being illuminated.
   • Screwed on rc-0

But as soon as you switch from the flight scene to the map screen and back (without switching vessels), the behavior changes to this:

1. When the Camera is looking into the Sun, the Sky shall dim.
   • Working *partially* (stars still faintly visible) on rc-0
2. When the Camera is looking into a Planet's illuminated side, the Sky shall dim.
   • Screwed on rc-0
3. When the Camera is looking into a Planet's dark side, the Sky shall be visible.
   • Working *partially* (stars still faintly visible) on rc-0
4. When the Camera is looking away from the Sun and from any planet, the Sky shall be visible.
   • Working on rc-0
5. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when the ground is being illuminated.
   • Screwed on 2.2.1.2

That's weird. I could not reproduce the problem on the 5h use case. It worked perfectly for me in both situations - still checking the other 4 use cases.

Can you please send me somehow (as posting on https://github.com/net-lisias-ksp/DistantObject/issues/31 ):

• The whole savegame directory where the problem happened
• The KSP.log after reproducing the problem.

Please remember to quit KSP before zipping the artifacts.

---- POST EDIT ----

I did a full blown Test Session, and everything worked fine for me. Unless there's some environmental glitch, I'm prone to believe you have some configuration or perception issue, and are misdiagnosing the problem.

https://github.com/net-lisias-ksp/DistantObject/issues/31#issuecomment-2660139215

HOWEVER. I think I'm contributing to such misdiagnosing, my screenshots apparently are showing the dimming somewhat aggressive than I remember - it's day time right now, I have Sun hitting my eyes and this may be hindering my judgment? I will check these screenshots again by night to see if I have the same perception.

 

And I also found a glitch on the ground colliders while sitting on Mün (notice Kerbin being drawn below the ground level, the second screenshot is the same scene some time later):

• Check first image on "Glitch Found due Ground Colliders" from https://github.com/net-lisias-ksp/DistantObject/issues/31#issuecomment-2660139215
• Check second image on "Glitch Found due Ground Colliders" from https://github.com/net-lisias-ksp/DistantObject/issues/31#issuecomment-2660139215

Since I'm using the Sun's visibility on my algorithm, perhaps we had found the reason for some apparently glitches on the dimming?

I initially tried to check the Sun's Coronas, but since there're at least two for Stock, I tried to cut some corners by using the Sun directly, but apparently this is backfiring. I will rework the code to check the Coronas too if the Sun is visible (and will avoid doing if the the Sun is not, to save some CPU cycles where possible).

===== POST EDIT =====

It's night now where I live, and that screenshots are sensibly more visible to me right now.

So the sunlight was interfering with my perception.

Since I do most of my coding by night, it's not a surprise that I didn't see any problems where @Errol where (not) seeing some.

I'm coding a DEBUG window so we can track the Dimming Factor and, then, check if we have really a code problem happening on the user's machine, or if it's a perception problem...

 

===== POST POST EDIT =====

Oukey, no subjectivity anymore. I implemented a Debug Window that will give us exactly the numeric value used to dim the SkyBox.

@Errol, please download and install the RC1 hotfix from https://github.com/net-lisias-ksp/DistantObject/releases/tag/RELEASE%2F2.2.1.2 .

From this point, I believe that we will not lose ourselves anymore in our own personal perceptions and will be able to discuss objectively about the skybox dimming!

Further instructions on this link: https://github.com/net-lisias-ksp/DistantObject/issues/31#issuecomment-2660589340

Edited Saturday at 01:00 AM by Lisias
POST POST EDIT

[Errol]

@Lisias

Yeah, sorry, today is not a great day for me for testing. I will try to get an early start tomorrow and do testing with screenshots, and logs. Should I wait for a version with a debugger option?

[Lisias]

1 minute ago, Errol said:

@Lisias

Yeah, sorry, today is not a great day for me for testing.

Don't worry, this is not a job. We do what we can with the time we have available! Thank you very much for yours!

 

1 minute ago, Errol said:

I will try to get an early start tomorrow and do testing with screenshots, and logs. Should I wait for a version with a debugger option?

Not anymore! I just published it!

Cheers!

https://github.com/net-lisias-ksp/DistantObject/issues/31#issuecomment-2660589340

Edited Saturday at 01:03 AM by Lisias
Missing link.

[Errol]

@Lisias

Ok, started testing today and clearly something is off between our setups. I'm using a freshly unzipped copy of ksp 1.12.5 (new sandbox save), module manager 4.2.3 (from ckan), windows 11, AMD64 (smt turned off) and an nVidia GPU. All drivers are up to date. I'm manually installing DOE 2.2.1.2 from zip, then manually installing rc-01 from zip and replacing the .DLLs the version for DOE listed in-game is 2.2.1.3/L EXPERIMENTAL RC-0....I even removed toolbar and clickthrough blocker so now it's literally just DOE, squad and MM in my gamedata folder.

In game I am able to open the new debug window, but the targetColorScalar stays at 0.000000 no matter what is happening. Behavior is the same as I described in my last test post where I discovered the map screen breaks the functionality partially. Since the debug window output isn't working for me, here is an imgur album to show all the states. In the that previous test post I made a couple of mistakes, I've corrected them in that post for clarity as well.

https://imgur.com/a/VtWeoZd

I've noticed some log spam as well.
 

[EXC 18:23:56.220] AlreadyLoadedException: The Assembly SolarSystemStock is already loaded!
    KSPe.Util.SystemTools+Assembly+Loader.LoadAndStartup (System.String assemblyName) (at <afd2f6694f9b4edcab4e21c3406dce44>:0)
    DistantObject.Contract.SolarSystemEngine.Create () (at <238038e99bd849ee843bb5a00531d699>:0)
    DistantObject.Contract.SolarSystemEngine.get_Instance () (at <238038e99bd849ee843bb5a00531d699>:0)
    DistantObject.DarkenSky.Update () (at <238038e99bd849ee843bb5a00531d699>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

 ̷H̷e̷r̷e̷'̷s̷ ̷a̷ ̷s̷n̷a̷p̷s̷h̷o̷t̷ ̷o̷f̷ ̷t̷h̷e̷ ̷b̷e̷g̷i̷n̷n̷i̷n̷g̷ ̷o̷f̷ ̷m̷y̷ ̷K̷S̷P̷.̷l̷o̷g̷ ̷u̷p̷ ̷t̷o̷ ̷t̷h̷e̷ ̷p̷a̷r̷t̷ ̷w̷h̷e̷r̷e̷ ̷t̷h̷e̷ ̷e̷x̷c̷e̷p̷t̷i̷o̷n̷ ̷s̷p̷a̷m̷ ̷b̷e̷g̷i̷n̷s̷.̷.̷.̷.̷t̷h̷e̷ ̷.̷t̷x̷t̷ ̷f̷i̷l̷e̷ ̷i̷s̷ ̷a̷b̷o̷u̷t̷ ̷2̷5̷0̷m̷g̷b̷

Edited Sunday at 05:24 AM by Errol
EDIT: removed excessively long KSP.log

[Lisias]

5 hours ago, Errol said:

Ok, started testing today and clearly something is off between our setups. I'm using a freshly unzipped copy of ksp 1.12.5 (new sandbox save), module manager 4.2.3 (from ckan), windows 11, AMD64 (smt turned off) and an nVidia GPU. All drivers are up to date. I'm manually installing DOE 2.2.1.2 from zip, then manually installing rc-01 from zip and replacing the .DLLs the version for DOE listed in-game is 2.2.1.3/L EXPERIMENTAL RC-0....I even removed toolbar and clickthrough blocker so now it's literally just DOE, squad and MM in my gamedata folder.

In game I am able to open the new debug window, but the targetColorScalar stays at 0.000000 no matter what is happening. Behavior is the same as I described in my last test post where I discovered the map screen breaks the functionality partially. Since the debug window output isn't working for me, here is an imgur album to show all the states. In the that previous test post I made a couple of mistakes, I've corrected them in that post for clarity as well.

https://imgur.com/a/VtWeoZd

I've noticed some log spam as well.
 

[EXC 18:23:56.220] AlreadyLoadedException: The Assembly SolarSystemStock is already loaded!
    KSPe.Util.SystemTools+Assembly+Loader.LoadAndStartup (System.String assemblyName) (at <afd2f6694f9b4edcab4e21c3406dce44>:0)
    DistantObject.Contract.SolarSystemEngine.Create () (at <238038e99bd849ee843bb5a00531d699>:0)
    DistantObject.Contract.SolarSystemEngine.get_Instance () (at <238038e99bd849ee843bb5a00531d699>:0)
    DistantObject.DarkenSky.Update () (at <238038e99bd849ee843bb5a00531d699>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

So now we have a smoking gun. Something is initializing DOE twice and it's complaining about - and I suspect this may be the source of a lot of headaches on this Scene - this is the very reason I big, wide mouth and complain about anything remotely fishy - we could not cope with what we don't know that exists.

This explains a lot of things. I'm checking your log right now.

In time, can you please edit your post and remove the spoiler contents? It have almost 5K lines and this screwed me on Mobile. As a rule of thumb, I don't post logs with more than 200 or 300 lines, being 500 really pushing some limits. More than this, and people using mobiles start to get screwed, as it happened to me. Paste it on github - that thing likes log files no matter the size!

 

Edited Sunday at 05:05 AM by Lisias
Hit "Save" too soon

[Errol]

10 hours ago, Lisias said:

So now we have a smoking gun. Something is initializing DOE twice and it's complaining about - and I suspect this may be the source of a lot of headaches on this Scene - this is the very reason I big, wide mouth and complain about anything remotely fishy - we could not cope with what we don't know that exists.

This explains a lot of things. I'm checking your log right now.

In time, can you please edit your post and remove the spoiler contents? It have almost 5K lines and this screwed me on Mobile. As a rule of thumb, I don't post logs with more than 200 or 300 lines, being 500 really pushing some limits. More than this, and people using mobiles start to get screwed, as it happened to me. Paste it on github - that thing likes log files no matter the size!

 

OK! This is feeling like some real progress now! Log spam is gone now. Just an fyi before I get to my test results; the version reported in-game and the label on the download .zip don't match:

installed version: 2.2.1.2-EXPERIMENTAL-RC-3.zip
version reported ingame: 2.2.1.3/L EXPERIMENTAL RC 2

Anyway, the targetColorScalar seems to be working now. Not sure if it is working as intended though, it does not seem to change with the skybox dimming, it reads 0.000000 when facing the planet and 1.000000 when facing the sun, with gradual decimal values in between.

As for what the mod is actually doing...functionality seems to all be correct until you go to map view, then things still seem to be getting messed up. I also added an extra case to check for (landed on atmosphereless body and looking at sun)

For freshly loaded vessels, seemingly from anywhere (VAB, tracking station, even from the map screen while controlling another vessel) appears to be fully functional!

1. When the Camera is looking into the Sun, the Sky shall dim.
   • Working on rc-3
2. When the Camera is looking into a Planet's illuminated side, the Sky shall dim.
   • *WORKING* correctly on rc-3
3. When the Camera is looking into a Planet's dark side, the Sky shall be visible.
   • Working on rc-3
4. When the Camera is looking away from the Sun and from any planet, the Sky shall be visible.
   • Working on rc-3
5. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when the ground is being illuminated.
   • *WORKING* correctly on rc-3
6. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when looking at the sun.
   • Working correctly on rc-3

But as soon as you switch from the flight scene to the map screen and back (without switching vessels), the behavior changes to this:

1. When the Camera is looking into the Sun, the Sky shall dim.
   • Working *partially* (stars still faintly visible, they still do some sort of logarithmic dimming) on rc-3
2. When the Camera is looking into a Planet's illuminated side, the Sky shall dim.
   • *WORKING* correctly on rc-3
3. When the Camera is looking into a Planet's dark side, the Sky shall be visible.
   • Working on rc-3
4. When the Camera is looking away from the Sun and from any planet, the Sky shall be visible.
   • Working on rc-3
5. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when the ground is being illuminated.
   • *WORKING* correctly on rc-3
6. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when looking at the sun.
   • Working  *partially* (stars still faintly visible, they still do some sort of logarithmic dimming) on rc-3

 ̷W̷o̷u̷l̷d̷ ̷y̷o̷u̷ ̷l̷i̷k̷e̷ ̷a̷ ̷l̷o̷g̷ ̷a̷g̷a̷i̷n̷?̷ 

EDIT: Ok, so I was optimistic and decided to do some testing in an install with more other visual enhancements, and I immediately noticed some weird behaviors. For case #3 before looking at map, it was not working UNTIL I opened the DOE dialogue window(?? very weird thing to see). And then when I opened the map and went back case #2 was screwed. This install has over 100 mods though, so I wouldn't be surprised if there is a conflict somewhere...

Edited Sunday at 03:23 PM by Errol

[Lisias]

22 hours ago, Errol said:

 ̷W̷o̷u̷l̷d̷ ̷y̷o̷u̷ ̷l̷i̷k̷e̷ ̷a̷ ̷l̷o̷g̷ ̷a̷g̷a̷i̷n̷?̷ 

EDIT: Ok, so I was optimistic and decided to do some testing in an install with more other visual enhancements, and I immediately noticed some weird behaviors. For case #3 before looking at map, it was not working UNTIL I opened the DOE dialogue window(?? very weird thing to see). And then when I opened the map and went back case #2 was screwed. This install has over 100 mods though, so I wouldn't be surprised if there is a conflict somewhere...

Yep, I will need the full logs so I can see if there's something different happening when you switch to the Map view.

The way you are describing the problem in this last paragraph suggests me that:

• I may had screwed something while loading/reloading/saving settings between Scene changes
  • But, by then, why I'm not being able to reproduce it?
• Something else is screwing the scene changes, leading DOE to bork while using these settings...
  • I remember a code that reloads the default values if anything goes wrong, but I need to check it again to be sure.

In a way or another, please reproduce the problem, then quit KSP, then send me a full KSP.log on that github issue.

Worst case scenario, I reproduce a test bed mimicking yours and try it myself - if it's a specific combination of mods (or the presence of one), I will be able to detect going nuclear on the problem.

[Errol]

@Lisias

OK, more big progress today (lots of uninstalling mods one at a time to check for compatibility issues/bugs). First, I have to say there was definitely some user error going on. Bit of a learning curve. I figured out a few things that were causing me issues. The DOE settings seem to save only when the DOE window gets closed; if you return to main menu with the dialogue still open your settings will not be saved.

So, with that in mind, I also have no idea what the skybox dimmer options actually do. I had previously been trying all sorts of things with the sliders (max and min for each) when there were missing updated .DLLs in the first EXPERIMENTAL release. So at first I didn't realize that it was these extreme DOE settings I had that was causing the unexpected behavior in my modded install. Now that I have that figured out (and the settings returned to sensible values), I believe I've managed to get the rc-03 release (listed as 2.2.1.3 RC 2 in-game...) working the same in both my clean install and modded install. I will post my KSP.log after triggering the map view bug on github.

As far as things that affect the sun and rendering, the modded install is tested with scatterer, deffered, parallax, kopernicus, shabby, shaddy, KSPBurst and texture replacer. To recap, these are the test results:

 

For freshly loaded vessels, seemingly from anywhere (VAB, tracking station, even from the map screen while controlling another vessel) appears to be fully functional!

1. When the Camera is looking into the Sun, the Sky shall dim.
   • Working on rc-3
2. When the Camera is looking into a Planet's illuminated side, the Sky shall dim.
   • *WORKING* correctly on rc-3
3. When the Camera is looking into a Planet's dark side, the Sky shall be visible.
   • Working on rc-3
4. When the Camera is looking away from the Sun and from any planet, the Sky shall be visible.
   • Working on rc-3
5. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when the ground is being illuminated.
   • *WORKING* correctly on rc-3
6. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when looking at the sun.
   • Working correctly on rc-3

But as soon as you switch from the flight scene to the map screen and back (without switching vessels), the behavior changes to this:

1. When the Camera is looking into the Sun, the Sky shall dim.
   • Working *partially* (stars still faintly visible, they still do some sort of logarithmic dimming) on rc-3
2. When the Camera is looking into a Planet's illuminated side, the Sky shall dim.
   • *WORKING* correctly on rc-3
3. When the Camera is looking into a Planet's dark side, the Sky shall be visible.
   • Working on rc-3
4. When the Camera is looking away from the Sun and from any planet, the Sky shall be visible.
   • Working on rc-3
5. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when the ground is being illuminated.
   • *WORKING* correctly on rc-3
6. When the Camera is "landed" on an atmosphereless body, the Sky shall dim when looking at the sun.
   • Working  *partially* (stars still faintly visible, they still do some sort of logarithmic dimming) on rc-3

Edited 6 hours ago by Errol
formatting