[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 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 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 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 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