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

[Lisias]

4 hours ago, AMolecularMassofUranium235 said:

https://www.dropbox.com/scl/fi/uwkcwsnnslom3eg3tcqud/ksp-log.txt?rlkey=fm1q0cuh5yp9vtvn1a7woem1d&st=gmu15q75&dl=0 I hope that this works

Yes, it did. I forgot to mention, in the future quit KSP first before copying the file, because there's a thingy called "write buffer" that delays the writing in an attempt to be more efficient, and so if you copy the file with KSP alive writting on it it ends up being truncated.

Fortunately, this time it was truncated after the breaking point, so I could find the problem!

[LOG 22:08:36.177] AssemblyLoader: Loading assemblies
[ERR 22:08:36.280] ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null

[ERR 22:08:36.280] ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null

[ERR 22:08:36.284] AssemblyLoader: Exception loading 'B9_Aerospace_WingStuff': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.
  at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0
  at AssemblyLoader.LoadAssemblies () [0x000e6] in <4b449f2841f84227adfaad3149c8fdba>:0

Additional information about this exception:

 System.IO.FileNotFoundException: Could not load file or assembly 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'

 System.IO.FileNotFoundException: Could not load file or assembly 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'

The Assembly B9_Aerospace_WingStuff is borking on a ReflectionTypeLoadException (a thingy that when happens breaks something inside KSP that by itself screws up everybody that needs to use another thingy called Reflection, which DOE needs to use to support Kopernicus). And this is happening because something called KSPUtil is not being able to be loaded.

Problem... KSPUtil is part of KSP!! It must be present, otherwise KSP is badly installed!

On Steam, there's an option called "Verify integrity of game files".

(Source)

Use it. I think your KSP got corrupted somehow. Do you use a SDD or NVM2? Did your computer crashed or rebooted abruptly recently?

Edited August 22, 2024 by Lisias
Entertaining grammars made slightely less entertaining...

[AMolecularMassofUranium235]

I'm pretty sure my power went out recently when I was installing mods on ckan, could that be it?

14 hours ago, Lisias said:

Yes, it did. I forgot to mention, in the future quit KSP first before copying the file, because there's a thingy called "write buffer" that delays the writing in an attempt to be more efficient, and so if you copy the file with KSP alive writting on it it ends up being truncated.

Fortunately, this time it was truncated after the breaking point, so I could find the problem!

[LOG 22:08:36.177] AssemblyLoader: Loading assemblies
[ERR 22:08:36.280] ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null

[ERR 22:08:36.280] ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null

[ERR 22:08:36.284] AssemblyLoader: Exception loading 'B9_Aerospace_WingStuff': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.
  at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0
  at AssemblyLoader.LoadAssemblies () [0x000e6] in <4b449f2841f84227adfaad3149c8fdba>:0

Additional information about this exception:

 System.IO.FileNotFoundException: Could not load file or assembly 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'

 System.IO.FileNotFoundException: Could not load file or assembly 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'

The Assembly B9_Aerospace_WingStuff is borking on a ReflectionTypeLoadException (a thingy that when happens breaks something inside KSP that by itself screws up everybody that needs to use another thingy called Reflection, which DOE needs to use to support Kopernicus). And this is happening because something called KSPUtil is not being able to be loaded.

Problem... KSPUtil is part of KSP!! It must be present, otherwise KSP is badly installed!

On Steam, there's an option called "Verify integrity of game files".

(Source)

Use it. I think your KSP got corrupted somehow. Do you use a SDD or NVM2? Did your computer crashed or rebooted abruptly recently?

Im pretty sure my power went out when I was installing mods on ckan, could that have been it?

[Lisias]

22 hours ago, AMolecularMassofUranium235 said:

I'm pretty sure my power went out recently when I was installing mods on ckan, could that be it?

Im pretty sure my power went out when I was installing mods on ckan, could that have been it?

Yes. I strongly suggest you not only check the game (if you downloaded it from Steam), but also to tell CKAN to reinstall all files - chances are that more files got damaged in the incident - it's almost a statistical certainty.

There're two types of Mass Storage devices that are nastily susceptible to power outs:

• SDDs, NVMe or any other kind of flash media
• HDDs with SMR.

These technologies erases a significant amount of data in order to write a tiny little bit of it - they read the whole macrocell (or group of tracks) into memory, change the bits that need to be changed and write them back. If you have a power outage in the process, you lose the whole macrocell (or track group), and not only what you was writing at that time.

It's usually a better idea to use a Journaled file system (like APFS on MacOS, or EXT4 and BTRFS on Linux - Linux really shines on file systems, there're a lot of different ones, each one of them shines on a specific niche...), but Windows users are out of options (and luck) at the present time.

Spoiler

And, yeah.. I defenestrated Windows from my life 10 years ago - I think more!

 

Edited August 23, 2024 by Lisias
Kraken damned autocompletes...

[MusicByVano]

https://imgur.com/a/iMZgHWB

Just found a small bug, a conflict with singularity

[Lisias]

6 hours ago, MusicByVano said:

https://imgur.com/a/iMZgHWB

Just found a small bug, a conflict with singularity

Not exactly a bug, DOE is doing what it's meant to do - Name Celestial Bodies.

Apparently Singularity is kinda (ab)using the CelestialBody concept to do something else and, so, fools DOE.

Try this patch to see if it solves this glitch:

@DistantObject:FINAL
{
	@DistantFlare
	{
		@CelestialBody
		{
			@ExclusionList
			{
            	name = <name of the celestial body you want to do not flare on Singularity)
			}
		}
	}

This should prevent DOE from flaring it.

[MusicByVano]

5 minutes ago, Lisias said:

Not exactly a bug, DOE is doing what it's meant to do - Name Celestial Bodies.

Apparently Singularity is kinda (ab)using the CelestialBody concept to do something else and, so, fools DOE.

Try this patch to see if it solves this glitch:

@DistantObject:FINAL
{
	@DistantFlare
	{
		@CelestialBody
		{
			@ExclusionList
			{
            	name = <name of the celestial body you want to do not flare on Singularity)
			}
		}
	}

This should prevent DOE from flaring it.

Thanks, I will try this out

[MusicByVano]

12 hours ago, Lisias said:

Not exactly a bug, DOE is doing what it's meant to do - Name Celestial Bodies.

Apparently Singularity is kinda (ab)using the CelestialBody concept to do something else and, so, fools DOE.

Try this patch to see if it solves this glitch:

@DistantObject:FINAL
{
	@DistantFlare
	{
		@CelestialBody
		{
			@ExclusionList
			{
            	name = <name of the celestial body you want to do not flare on Singularity)
			}
		}
	}

This should prevent DOE from flaring it.

I can just remove flares from Kcalbeloh planets, but I think the problem is that those flares are rendering on top of singularity, It's not really DOE problem, just found out the reason

[Lisias]

6 hours ago, MusicByVano said:

I can just remove flares from Kcalbeloh planets, but I think the problem is that those flares are rendering on top of singularity, It's not really DOE problem, just found out the reason

Humm... so the feature is working. 

What I think it's happening I'd that you are not being able to determine correctly the celestialBodyName of the singularity. I will give this a try by night and come back to you.

[MusicByVano]

10 minutes ago, Lisias said:

Humm... so the feature is working. 

What I think it's happening I'd that you are not being able to determine correctly the celestialBodyName of the singularity. I will give this a try by night and come back to you.

So it can be the problem that causes flares to be rendered in front of black hole, while the planet itself is behind it?

[Lisias]

38 minutes ago, MusicByVano said:

So it can be the problem that causes flares to be rendered in front of black hole, while the planet itself is behind it?

Hummm... So this is the problem? I had though the the problem is the flare being drawn on the black hole itself, what's obviously.wrong.

The planet behind the black hole is being flared because DOE is not being able to determine it's cloacked from the current point of view.

I need to check how singularity works.

Ok, this is officially a change request.

I will come back to you by night with whatever I found. Don't hold your breath, however, I have some duties already on the pipeline for today.

https://github.com/net-lisias-ksp/DistantObject/issues/52

Edited November 17, 2024 by Lisias
Link to github issue

[MusicByVano]

15 minutes ago, Lisias said:

Hummm... So this is the problem? I had though the the problem is the flare being drawn on the black hole itself, what's obviously.wrong.

The planet behind the black hole is being flared because DOE is not being able to determine it's cloacked from the current point of view.

I need to check how singularity works.

Ok, this is officially a change request.

I will come back to you by night with whatever I found. Don't hold your breath, however, I have some duties already on the pipeline for today.

I guessed that we talk about different problems, thanks in advance

[Lisias]

10 hours ago, MusicByVano said:

So it can be the problem that causes flares to be rendered in front of black hole, while the planet itself is behind it?

I checked the Singularity code, and I think that now I know what's happening; the singularity add'on only draws an event horizon (or a worm hole) to an existent Celestial Body directly "on the canvas", it's a visual "only" code without any kind of physics interaction.

What's happening to you is the effective Celestial Body used to "hook" the black hole is "tiny", way smaller than the event horizon and the accretion disks. And since these visuals are merely... visuals... without any effect on the Celestial Body itself, DOE keeps doing its business looking only into the Celestial Body, unaware of any event horizon or wormhole being drawn around it.

I suppose that I can write a "plugin" (like it was done for Kopernicus) to allow the Flare drawing code to hide the flare if it's behind a "imaginary" sphere centered on the Celestial Body itself, and so "pervert" the game engine to accomplish the occlusion without trying to do the hard lifting myself using math.

I will give this some thoughts in the next weeks.

https://github.com/net-lisias-ksp/DistantObject/issues/52

[MusicByVano]

2 hours ago, Lisias said:

I checked the Singularity code, and I think that now I know what's happening; the singularity add'on only draws an event horizon (or a worm hole) to an existent Celestial Body directly "on the canvas", it's a visual "only" code without any kind of physics interaction.

What's happening to you is the effective Celestial Body used to "hook" the black hole is "tiny", way smaller than the event horizon and the accretion disks. And since these visuals are merely... visuals... without any effect on the Celestial Body itself, DOE keeps doing its business looking only into the Celestial Body, unaware of any event horizon or wormhole being drawn around it.

I suppose that I can write a "plugin" (like it was done for Kopernicus) to allow the Flare drawing code to hide the flare if it's behind a "imaginary" sphere centered on the Celestial Body itself, and so "pervert" the game engine to accomplish the occlusion without trying to do the hard lifting myself using math.

I will give this some thoughts in the next weeks.

https://github.com/net-lisias-ksp/DistantObject/issues/52

That's interesting 

[Tequhella]

On 11/16/2024 at 3:00 PM, MusicByVano said:

https://imgur.com/a/iMZgHWB

Just found a small bug, a conflict with singularity

I tried with a wormhole, and the scatterer sun flare goes through too.
I think it's not really in DOE, or at least not only in DOE that this problem should be fixed.

https://imgur.com/AcsboDY

[Lisias]

9 hours ago, Tequhella said:

I tried with a wormhole, and the scatterer sun flare goes through too.
I think it's not really in DOE, or at least not only in DOE that this problem should be fixed.

In theory, the flares are only drawn if the Celestial Body is visible - what means that, yeah, the Celestial Body are not being cloaked by the Singularity add'on.

I didn't though on making the Sun check, by the way. Thanks for the help!

But my "solution" still stands (if it's possible)... It just don't need to be implemented on DOE - if it would be possible to create a unrenderable Sphere around the center of the Black Hole that could be used to cloak celestial bodies' on Singularity itself, then the problem will be solved for everybody and not only for people installing an hypothetical new release of DOE.

Edited November 20, 2024 by Lisias
Oh, damnit... Tyops as usulla. :)

[MusicByVano]

28 minutes ago, Lisias said:

In theory, the flares are only drawn if the Celestial Body is visible - what means that, yeah, the Celestial Body are not being cloaked by the Singularity add'on.

I didn't though on making the Sun check, by the way. Thanks for the help!

But my "solution" still stands (if it's possible)... It just don't need to be implemented on DOE - if it would be possible to create a unredered Sphere around the center of the Black Hole that could be used to cloak celestial bodies`, them the problem will be solved for everybody and not only for people installing an hypothetical new release of DOE.

Okay, now I understand why this happens, it's not really annoying, I can deal with this quite easy, wish you the best

[Errol]

On 5/8/2024 at 4:42 PM, Lisias said:

You know, the idea is not bad - but I would do some calculations the same just for it, and I think I found a dirty trick to get it for free.

I don't have the time to try it in the short term (things are somewhat hairy on DayJob©), so I'm reticent to open my big mouth without proper grounds (I had to eat my words recently on MM/L on something about :HAS, I think it's a good idea to try to avoid doing it again! )

Any progress on this at all? I saw there was some more discussion around edge cases related to this in issue #50.....honestly though I think that even a janky solution that only works in most simple cases (LKO) would be better than nothing. Even if the stars all snap off instantly as soon as any sunlight hits your vessel, regardless of camera position or if you are orbiting a moon.

Edited February 12 by Errol

[Lisias]

1 hour ago, Errol said:

Any progress on this at all?

Nothing that I would be willing to share. The last hack I tried backfired, run out of time for modding since then.

If you have any hint of idea that you tried and worked, I'm listening!

Edited February 12 by Lisias
Hit "Save" too soon

[Errol]

48 minutes ago, Lisias said:

Nothing that I would be willing to share. The last hack I tried backfired, run out of time for modding since then.

If you have any hint of idea that you tried and worked, I'm listening!

I just had a thought which is more of a QoL work-around. Could you give us a key-binding for enabling/disabling skybox dimming? I wouldn't mind having to manually turn it on and off myself when appropriate, but I'd like to be able to do it without having the settings dialogue up, for screen recording purposes. I'd like to be able to capture a nice sunrise from LKO with the HUD completely turned off. I realize that there are very few keys left that aren't already used by other mods or something, so perhaps a binding with a modifier key? Something like alt + U?

[Lisias]

48 minutes ago, Errol said:

I just had a thought which is more of a QoL work-around. Could you give us a key-binding for enabling/disabling skybox dimming? I wouldn't mind having to manually turn it on and off myself when appropriate, but I'd like to be able to do it without having the settings dialogue up, for screen recording purposes. <...>

Ah, now I see. Kinda a "gambiarra", but heck, why not?

I got kinda conscience-stricken on the subject and I'm revisiting the code I wrote sometime ago and left behind. I had found some idiocies while handling Kopernicus, anyway, and frankly I don't know why nobody had complained before (or someone did and I forgot about?). So I have material to at least one more bug fix release.

Anyway, I'll commit that trashy, really unforgivable way to handle the use case I ended up writing and got ashamed of publishing it before being dragged out of the task.

Let's see if it would be good enough for your use case, I'm trying to make that thing not too horrible to be published as a EXPERIMENTAL release. I will add too the brute-force option (key binding).

 

[Lisias]

ANNOUNCE

Release 2.2.1.0 2.2.1.1 2.2.1.2 is available for downloading, with the following changes:

• Finally implements Sky Undimming when on the dark side of a planet where the Sun is not visible!
• Fixes a potential glitch involving Kopernicus, discovered while implementing #31.
• Closes issues:
  • #31 Check the SkyBox Dimming when looking on the Planet from it's dark side.

So... Last year I chased my tail on this thing trying to do things the... hum... "smart" way:

• I computed the angular size of the Sun, then launched 3 ray casts (to the center, to the leftmost and to the rightmost, these two inferred by the angular size - in KSP¹ there're no planetary tilts, so I didn't had to check the topmost neither the bottommost).
  • I wanted to know when the Sun started to be eclipsed, and when it would be completely eclipsed.
  • Obviously, this performed like crap due the raycasts and extra trigonometry.
• Then I tried to be "smarter", computed the apparent size of the Sun, got the boundaries, cropped the damned thing using current viewing frustrum, and then tried to figure out if any planet also inside the frustrum would be eclipsing it.
  • I realized the idiocy of this thing when I considered using a ray cast to see if there's anything between the camera and the Sun, what would just degenerate the "solution" on something like the first try.
• Then I tried to monitor the Sun's Coronas (there're two on Stock), trying to figure out if they were being drawn or not.
  • Reading code around the World, I found one dude doing a similar check but using the GameObject's Renderer IsVisible attribute...
• And then something finally sparked inside my dull skull, and I just checked if the Sun's Renderer exists and, if it exists, if the IsVisible is true or not... (sigh)
• And finally I shoved all this code in the trash bin, replaced a min with a max and "implemented" the feature without collateral effects...
  • Oh, the joy of fixing issues by removing code...
  • The difference between humility and humiliation is... thin.
• Only to realize that such code were important to an important use case, and by "luck" I had tested the thing only on the very use case where it would not matter, and screwed everything else.
• Currently I finally managed to secure the Use Cases, and are currently debugging any mishap on the algorithm that could be happening on borderline situations.
  • But the code is somewhat inefficient, and I will probably try to optimize it a bit before a proper release!

This release will be available only as a PRE-RELEASE on github:

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

I want to tackle out some more glitches before doing an update fest to the rest of the World.

Ping @Errol, @Krazy1

Edited Saturday at 02:54 AM by Lisias
2.2.1.2

[Errol]

4 hours ago, Lisias said:

<...>

Tried installing this in my regular testing install with only visual enhancements and QoL mods and it seemed like it was not installed, no setting dialogue in blizzy's toolbar or the stock app launcher and no effect from the mod in flight. So I tried switching to a clean install with only module manager, blizzy's toolbar, toolbar controller and clickthrough blocker....and double and triple checked that I had the distant object folder properly in the gamedata folder. I also verified that it has all the files in it that were present in the previous version. Then I check my log and found this, not sure if it is helpful, but yeah, sorry, I was unable to test because I'm not sure if I messed up installing somehow, or if there's something wrong with the pre-release...
 

 

[LOG 01:38:28.100] ActionCanvas MASK: 3458764513820540928
[LOG 01:38:28.100] AppCanvas MASK: 3458764513820540928
[LOG 01:38:28.101] MainCanvas MASK: 3458764513820540928
[LOG 01:38:31.357] Load(Assembly): /ModuleManager.4.2.3
[LOG 01:38:31.357] AssemblyLoader: Loading assembly at C:\Users\errol\Documents\KSP_win64\GameData\ModuleManager.4.2.3.dll
[LOG 01:38:31.371] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0
[LOG 01:38:31.371] Load(Assembly): 000_ClickThroughBlocker/Plugins/ClickThroughBlocker
[LOG 01:38:31.371] AssemblyLoader: Loading assembly at C:\Users\errol\Documents\KSP_win64\GameData\000_ClickThroughBlocker\Plugins\ClickThroughBlocker.dll
[LOG 01:38:31.371] AssemblyLoader: KSPAssembly 'ClickThroughBlocker' V2.1.10
[LOG 01:38:31.371] Load(Assembly): 000_Toolbar/Plugins/aaa_Toolbar
[LOG 01:38:31.371] AssemblyLoader: Loading assembly at C:\Users\errol\Documents\KSP_win64\GameData\000_Toolbar\Plugins\aaa_Toolbar.dll
[LOG 01:38:31.372] AssemblyLoader: KSPAssembly 'Toolbar' V1.8.1
[LOG 01:38:31.372] AssemblyLoader: KSPAssemblyDependency 'ClickThroughBlocker' V1.7.0
[LOG 01:38:31.372] Load(Assembly): 001_ToolbarControl/Plugins/ToolbarControl
[LOG 01:38:31.372] AssemblyLoader: Loading assembly at C:\Users\errol\Documents\KSP_win64\GameData\001_ToolbarControl\Plugins\ToolbarControl.dll
[LOG 01:38:31.373] AssemblyLoader: KSPAssembly 'ToolbarController' V1.0.1
[LOG 01:38:31.373] AssemblyLoader: KSPAssemblyDependency 'ClickThroughBlocker' V1.0.0
[LOG 01:38:31.373] Load(Assembly): DistantObject/Plugins/DistantObject
[LOG 01:38:31.373] AssemblyLoader: Loading assembly at C:\Users\errol\Documents\KSP_win64\GameData\DistantObject\Plugins\DistantObject.dll
[LOG 01:38:31.373] Load(Assembly): DistantObject/Plugins/KSPe.Light.DOE
[LOG 01:38:31.375] AssemblyLoader: Loading assembly at C:\Users\errol\Documents\KSP_win64\GameData\DistantObject\Plugins\KSPe.Light.DOE.dll
[LOG 01:38:31.375] AssemblyLoader: KSPAssembly 'KSPe.Light.DOE' V2.5.0
[LOG 01:38:31.376] AssemblyLoader: Loading assemblies
[ERR 01:38:31.413] ADDON BINDER: Cannot resolve assembly: KSPe, Culture=neutral, PublicKeyToken=null

[ERR 01:38:31.413] ADDON BINDER: Cannot resolve assembly: KSPe, Culture=neutral, PublicKeyToken=null

[ERR 01:38:31.415] AssemblyLoader: Exception loading 'DistantObject': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.
  at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0
  at AssemblyLoader.LoadAssemblies () [0x000e6] in <4b449f2841f84227adfaad3149c8fdba>:0

Additional information about this exception:

 System.IO.FileNotFoundException: Could not load file or assembly 'KSPe, Version=2.5.5.1, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'KSPe, Version=2.5.5.1, Culture=neutral, PublicKeyToken=null'

[LOG 01:38:31.419] VesselModules: Found VesselModule of type AxisGroupsModule with order 999
[LOG 01:38:31.444] VesselModules: Found VesselModule of type CometVessel with order 999
[LOG 01:38:31.445] VesselModules: Found VesselModule of type SuspensionLoadBalancer with order 999
[LOG 01:38:31.446] VesselModules: Found VesselModule of type FlightIntegrator with order 0
[LOG 01:38:31.447] VesselModules: Found VesselModule of type CommNetVessel with order 999
[LOG 01:38:31.449] VesselModules: Found 5 VesselModule types
[LOG 01:38:31.452]
************************************************************************

 

Edited February 13 by Errol

[Lisias]

1 hour ago, Errol said:

Tried installing this in my regular testing install with only visual enhancements and QoL mods and it seemed like it was not installed, no setting dialogue in blizzy's toolbar or the stock app launcher and no effect from the mod in flight. So I tried switching to a clean install with only module manager, blizzy's toolbar, toolbar controller and clickthrough blocker....and double and triple checked that I had the distant object folder properly in the gamedata folder. I also verified that it has all the files in it that were present in the previous version. Then I check my log and found this, not sure if it is helpful, but yeah, sorry, I was unable to test because I'm not sure if I messed up installing somehow, or if there's something wrong with the pre-release...

Crap... I screwed the dependencies last year, and didn't realized.

On the bright side (#badumtss), white testing the thing properly this time, I detected that I had screwed the planet's influence on the Sky Dimmer, so I fixed it too.

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

[Errol]

@Lisias

Ok, ran a quick test and here are my observations.

-Skybox dimming when the day side of the planet comes into view makes the stars go completely black. No skybox visible at all.

-Skybox dimming when looking towards the sun is not as dark....you can still faintly see the stars. Dimming does get properly disabled when shadowed by a celestial body though.

I tried playing with all the sliders in the distant object settings under dimming, but none of them seemed to affect this. Not sure how difficult this would be to address, but I'll mention I feel like this would be less noticeable if it were the other way around. The sun is the brighter object, it should make the skybox harder to see.

 

Edited Thursday at 04:07 PM by Errol

[Lisias]

5 hours ago, Errol said:

Ok, ran a quick test and here are my observations.

-Skybox dimming when the day side of the planet comes into view makes the stars go completely black. No skybox visible at all.

AFAIK this is the desired result - if the planet is "visible enough", it's brightness will dim the stars completely. The nearer you are from the planet (i.e., the lower the orbit), quicker will be the effect.

Keep in mind that now the Sun is also playing a hole on the dimming if it's somewhere ahead of the camera. So, now, we have two bodies that "when visible enough" will sum their effects.

You should see the dimming changing as you rotate the camera to a position where the Sun is somewhere ahead of it, and then behind it. So it rotating the camera around the normal axis (i.e., point the camera to prograde on a circular orbit, then move to north/south, then move to retrograde). The dimming, now, will be different between prograde and retrograde unless the Sun is exactly at the top (local midday).

 

5 hours ago, Errol said:

-Skybox dimming when looking towards the sun is not as dark....you can still faintly see the stars. Dimming does get properly disabled when shadowed by a celestial body though.

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.

Cheat the vessel into a higher orbit, where the apparent size o the planet and the Sun will be more or less equivalent, and so some tests:

• Look directly into the celestial body: the sky should be completely dark.
• Start to slowly mode away from it: the sky will start to fade back gradually, but not linearly - more like logarithmically.
  • Our eyes adapt to the lightning into a non linear curve. It's logarithmic when going to a brighter environment, and more or less exponential when going to a darker one (i.e., we adapt pretty quickly to lighter envs, but very slowly into darker ones).
    • This is something I wanna tackle down eventually on https://github.com/net-lisias-ksp/DistantObject/issues/26
    • This is where looking into the Sun or into the Planet should cause some different effects, as the Sun is way brighter than the Planet and, so, will demand more time to recover once you look the other way.
      • It's bright enough to hinder the whole view, and not only the skybox!

I will be able to do some screenshots demonstrating the features ("or documented bugs" :P) by night.

In the mean time, I understand that there're some improvements opportunities here, but... We are reaching quickly the peak of the curve of diminishing returns. Once the lower hanging fruits are collected, the efforts to reach the higher ones will be greater and greater, while the rewarding will be... lower and lower.

And some of them would not be even desirable - who wants to be blind for some seconds after looking into the Sun? On the middle of an important burn, for example?

--- --- EDIT --- ---

Additionally... When I implemented this last feature, I was focusing on making the thing work fast trying to avoid to create that hotkey to brute-force dim/undim the Sky and quickly deliver something that would solve your problem now.

So the code that would (or not) undim the sky when you are on the dark side of the planet are bluntly capping MAX or MIN dim into the current environmental brightness.

It's the reason I didn't pushed it into the mainstream, I didn't gave too much thinking on the caps and I can probably make it slightly better without too much effort after thinking a bit more on the problem - worst case scenario, I shove this "bug" on the #26.

Edited Thursday at 09:05 PM by Lisias
brute force post merge