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

[Krazy1]

17 hours ago, Lisias said:

so I postponed it to the next weekend!

No worries. You work hard enough man.

17 hours ago, Lisias said:

if you are looking into the Sun, or if you are looking into the Planet your are orbiting from a reasonable distance, the sky is dimmed.

I was at about 40 km altitude orbit of Moho when I noticed it. Maybe that's an extreme condition because the sun is so bright there. 

[Krazy1]

@Lisias one more weird thing for 2.1.1.11r2 on KSP 1.12.3... The first time a flight scene loads, in high sun orbit (between Moho and Kerbin), planets dim regardless of the direction of the sun. Planets are only visible near the edge of my monitor. It doesn't matter where they are in the sky. It does dim them if I'm looking at the sun, meaning that part is working correctly I think.

BUT going to the map view and back to craft view fixes this... then looking away from the sun, planets are visible again. So there's some initialization issue I think.

[Lisias]

19 minutes ago, Krazy1 said:

@Lisias one more weird thing for 2.1.1.11r2 on KSP 1.12.3... The first time a flight scene loads, in high sun orbit (between Moho and Kerbin), planets dim regardless of the direction of the sun. Planets are only visible near the edge of my monitor. It doesn't matter where they are in the sky. It does dim them if I'm looking at the sun, meaning that part is working correctly I think.

BUT going to the map view and back to craft view fixes this... then looking away from the sun, planets are visible again. So there's some initialization issue I think.mm

I don't have a 1.12.3 available for testing anymore, so I gave this a try on 1.12.5 (and, of course, on 1.4.3 too - why not? ).

This is what I did:

1. Launched the game, created a new sandbox called "test-doe"
   1. this step, obviously, is only executed the first time
2. Opened the DOE Settings, clicked on Reset to Defaults and made sure the Flares and the SkyBox Dimming are enabled. Also enabled the Show Names on MouseOver. Closed the Settigns after clicking Apply.
3. On VAB, loaded the Ion Powered Space Probe
4. Launched it into LaunchPad
5. Cheated it into a 6000000000 (9 zeros) orbit around the Sun.
6. Made sure to move the camera to be between the Sun and the Probe (so the Sun was "behind me" for sure), and at the same time be able to see the flare of some planed, in my case, Duna.
7. Quit the game to Desktop
8. Reloaded the game, reloaded the savegame, got into Tracking Station, selected the probe and clicked on Fly.
9. Nothing wrong detected - the Sky is not dimmed, and the flares are visible.
   1. Moving the camera around worked as expected - things got dimmed when the Sun appeared, and got back to be visible as the Sun is out of the view.

I repeated this procedure on 1.4.3 and 1.12.5.

I think you may be experiencing some 3rd party conflict, perhaps? Or something that is mangling with the game's life cycles?

[Krazy1]

7 hours ago, Lisias said:

I think you may be experiencing some 3rd party conflict, perhaps? Or something that is mangling with the game's life cycles?

Thanks for spending time on this... I have a fresh 1.12.5 install and also confirmed it works normally there with a similar sequence you did. The planet flares work normally the first time loading a craft. I do have a lot of mods on my main 1.12.3 install and there are errors so IDK. Ignoring it for now.

Noticed it required MM but load screen says zero patches installed...? It's obviously working though. 

[Lisias]

12 minutes ago, Krazy1 said:

Noticed it required MM but load screen says zero patches installed...? It's obviously working though. 

Ouch, I forgot about! It was going to be needed for some customisations, but I ended up not implementing them (yet) and forgot the thing there!

Thanks for the heads up!

 

12 minutes ago, Krazy1 said:

I do have a lot of mods on my main 1.12.3 install and there are errors so IDK. Ignoring it for now.

That's the problem with errors on KSP: they break the chain of events of the life cycle of some components.

As an example, let's suppose we have a one part vessel with 3 modules: ModuleA, ModuleB, ModuleC.

When KSP fires up the vessel, it does something more or less like this:

1. Call VesselModule's OnStart
2. Call the OnStart of every Module:
   1. ModuleA.OnStart()
   2. ModuleB.OnStart()
   3. ModuleC.OnStart()
3. Release control to the GameEngine.

And the GameEngine, so, loops more or less this way:

1. For every vessel in the physics range:
   1. Call  its FixedUpdate
   2. For every Part on the Vessel:
      1. Calls its FixedUpdate, i.e:
         1. ModuleA.FixedUpdate()
         2. ModuleB.FixedUpdate()
         3. ModuleC.FixedUpdate()

Now imagine: each Module's OnStart initialises some data needed by its respective FixedUpdate, right?

So, what's happens if there's an Exception while handling the ModuleB.OnStart()? Well, the ModuleC.OnStart() will not be called, because the thread was killed while calling ModuleB.OnStart()! So ModuleB.FixedUpdated will probably be screwed, and ModuleC.FIxedUpdate will surely be royally screwed - besides not being its fault ModuleB killed the thread on the OnStart phase.

The same happens if ModuleB.FixedUpdate() throws an Exception - the thread is killed, and the ModuleC.FixedUpdate() is never called because of that.

This is the reason we should not play KSP when there're exceptions being thrown on the KSP.log. Kraken knows what's not being called because of that.

Edited February 13, 2023 by Lisias
Brute force post merging.

[Krazy1]

1 hour ago, Lisias said:

This is the reason we should not play KSP when there're exceptions being thrown on the KSP.log. Kraken knows what's not being called because of that.

Yeah... I know... but it just gets overwhelming because either there are so many mods it's hard to pinpoint or the authors are not responsive so we have to hope for the best or not use some mods. *sigh* at least I'm remembering to back up my save files... this one is now 26 MB. I'm glad you're here and trying to help with individual troubleshooting. 

Presently I'm working on a new JNSQ build - up to 74 mods. So I'll see how that behaves. BTW when installing DOE/L with CKAN, it autoinstalls the DOE/L default config.  I see another DOE config for RSS but not JNSQ.

[Lisias]

2 minutes ago, Krazy1 said:

I see another DOE config for RSS but not JNSQ.

That's something we can work on! Let's talk about it on the next WeekEnd!

In the end, it's really simple: a list of bodies by name and the RGB colours you want their flare. Check this file: https://github.com/net-lisias-ksp/DistantObject/blob/master/GameData/DistantObject/PlanetColors.cfg

[R-T-B]

On 2/12/2023 at 10:39 PM, Lisias said:

This is the reason we should not play KSP when there're exceptions being thrown on the KSP.log. Kraken knows what's not being called because of that.

I mean on one hand you are correct, but on the other hand, EVE volumetric clouds beta and parallax both throw internal exceptions on every single scene change, and I'm not giving my pretty kerbin up.

Edited February 14, 2023 by R-T-B

[Lisias]

19 minutes ago, R-T-B said:

I mean on one hand you are correct, but on the other hand, EVE volumetric clouds beta and parallax both throw internal exceptions on every single scene change, and I'm not giving my pretty kerbin up.

Choose your poison!

EVE beta is, well, beta. You know you are risking your savegames using it. And since the thing is being actively developed, such problems are really expected to happen.

Parallax is a bit more hairy, because it's being used as stable nowadays. IMHO, someone should at least handle that exceptions in a graceful way to make sure this is not aborting any threads. A lot of weird issues may be related to it, not only here on DOE or even TweakScale, but on some others too. Including efforts to fix KSP internal problems.

There's no way to keep the game healthy with threads being murdered by unhandled Exceptions. This may be one of the reasons so many people are getting screwed on KSP while gaming, with crafts suddenly being saved missing modules and when reloaded, missing the configurations. I have diagnosed at least one case in which some (but not all) satellites on a savegame lose all communications: by inspecting the savegame, the affected crafts had lose the ModuleDataTransmitter and the values were reinjected in a way that made them unuseable. This must had happened in a single gaming session, because some 2 or 3 crafts had the problem - the other ones probably had never be unrailled on the doomed gaming session, so they were preserved.

Again, if you don't mind risking your savegames, it's your choice. But users need to have the same choice too - and users can't choose what they don't know about - and they are not skilled techinicians as both of us.

[R-T-B]

1 hour ago, Lisias said:

and they are not skilled techinicians as both of us.

Aye.

FWIW I've looked at both those exceptions and they effectively happen in the scene cleanup section of the code, in their own neat little method, so at worse, a minor memory leak.  But me?  I try-catched them with dnspy to stop them from bugging me... lol.

Most users are probably safe using those mods but thats kind of the exception, the advice in general is sound:  Don't just ignore a mile long exception list.  And my god have I seen error reports where people do.

Edited February 14, 2023 by R-T-B

[Gotmachine]

On 2/13/2023 at 7:39 AM, Lisias said:

what's happens if there's an Exception while handling the ModuleB.OnStart()? Well, the ModuleC.OnStart() will not be called,

Nope. Managed exceptions happening in the UnityEngine.MonoBehaviour "message" methods (Awake, Start, FixedUpdate, Update, etc) are always catched.
Same for the PartModule major virtual methods (OnAwake, OnStart, OnFixedUpdate, OnUpdate, etc), each individual call is wrapped in a try/catch block.
Said otherwise, triggering an exception in those methods will only affect the problematic call, all subsequent calls on other objects will run  as usual.

[Lisias]

1 hour ago, Gotmachine said:

Nope. Managed exceptions happening in the UnityEngine.MonoBehaviour "message" methods (Awake, Start, FixedUpdate, Update, etc) are always catched.
 

So the problems  happen when  the uncaugh exceptions happens on KSP overriden methods only?

The OnSave for sure screws the whole game when it happens, preventing even the UI from working once it happens.

 

11 hours ago, R-T-B said:

FWIW I've looked at both those exceptions and they effectively happen in the scene cleanup section of the code, in their own neat little method, so at worse, a minor memory leak.  But me?  I try-catched them with dnspy to stop them from bugging me... lol.

On exactly what method this is happening? We have information that Unity's "callbacks" are caughthing exceptions and preventing the thread's murder, but I have empirical evidences that at least the PartModule.OnSave royally screws the whole game when an uncaught exceptions os thrown...

Edited February 14, 2023 by Lisias
Grammars... (Sigh)

[R-T-B]

5 minutes ago, Lisias said:

On exactly what method this is happening?

OnDestroy(), IIRC.  If I am remembering right: The problem is a null test that is done.  One must remember in Unity land, things aren't always null when they are dead, or might even not be dead and show as null, null is just a bad test!

Explaining why goes into the origins of Unity and how C# and C++ get merged, but it's the truth.

I think scatterer once had a similar issue but it was fixed.

Edited February 14, 2023 by R-T-B

[Lisias]

So I did what I usually do: I don't guess, I measure.

With this project

https://github.com/net-lisias-ksp/ScrewMeUp/releases

one can selectivelly induce the injection of NRE's on the different points of the Unity's and KSP's Life Cycles - and so measure the consequences on the current gaming. I don't really have to explain that this thing can royally screw you over, so don't even consider using it on anything that you would remotely like to use again after!

The M.O. is simple: on any scene, open the PAW for the selected strutCube and activate the "Screwer" you are interested on checking (KSP or Unity). Then look into the KSP.log for situations where the "Screwed" PartModule doesn't logs an entry telling its is fine. Failing to log "it's fine" indicates a situation where the NRE had screwed the Life Cycle of the PartModule.

Only the strutCube (Cubic Octagonal Strut) was patched with these PartModules. Only crafts using it will be subject to the problem, we would need to inject these Modules on more complex parts (including with 3rd parties modules as TweakScale) to completely appreciate the consequences - but, hey, this is a start.

Additional very important info on spoiler:

Spoiler

Screw me up!!!

If you screws me up
If you screws me up, I'll never stop
If you screws me up
If you screws me up, I'll never stop

I've been running hot
You got me wrecking gonna blow my top
If you screws me up
If you screws me up, I'll never stop
Never stop, never stop, never stop

You make a grown man cry
You make a grown man cry
You make a grown man cry

 

9 hours ago, Gotmachine said:

Nope. Managed exceptions happening in the UnityEngine.MonoBehaviour "message" methods (Awake, Start, FixedUpdate, Update, etc) are always catched.
Same for the PartModule major virtual methods (OnAwake, OnStart, OnFixedUpdate, OnUpdate, etc), each individual call is wrapped in a try/catch block.
Said otherwise, triggering an exception in those methods will only affect the problematic call, all subsequent calls on other objects will run  as usual.

Not entirely true - at least, depending from what you call "major". At least some methods are screwing KSP when an uncaught Exception happens, on the very least we have the already known PartModule.OnSave that can halt the whole User Interface when happens. Interesting enough the "damage" is not permanent, if you disable the "Screwing" the game goes back to normal. Not a bad thing, not a bad thing at all.

See above.

I didn't mapped exactly what ones are screwing the game and where, this is Research in Progress (something to be done on a longer Week End to say the true), but it's enough to say that it can impede the part from being loaded on recent KSPs if the test is activated on the Loading Scene (by setting true on the patch that inject the Screwer module into the part) - on some older KSPs, it plain crash the game to CTD.

Additionally, I didn't created a test for VesselModules. Yet.

7 hours ago, R-T-B said:

OnDestroy(), IIRC.  If I am remembering right: The problem is a null test that is done.  One must remember in Unity land, things aren't always null when they are dead, or might even not be dead and show as null, null is just a bad test!

I will need a more refined Test Artefact in order to check about this one (see above). 

It's important to consider that failing to complete the OnDestroy() can leave not only memory left behind on the heap, but entire objects on GameEvents (as it happened in the past with B9PS, that ended up screwing TweakScale), what I called Zombies in the past. TweakScale is one thingy that really misbehaves when transformed into a Zombie.

Edited February 15, 2023 by Lisias
Grammars… {sigh) - good thing I'm a programmer, not a novelist!!

[R-T-B]

On 2/14/2023 at 5:00 PM, Lisias said:

I will need a more refined Test Artefact in order to check about this one (see above). 

Of course.  I wouldn't expect that to be enough information, was just providing the bread crumbs I recall, so to speak.

When I next have time to look, I will update you on what I find with more details.

[Krazy1]

On 2/13/2023 at 12:36 AM, Krazy1 said:

BTW when installing DOE/L with CKAN, it autoinstalls the DOE/L default config.  I see another DOE config for RSS but not JNSQ.

Actually DOE is working great in JNSQ. The new planet flares are there and the stock planets are different colors to match the JNSQ changes. CKAN autoinstalls the DOE default config, so I suppose JNSQ is overriding that. Well, it works.

[Why485]

This is one of those mods that I've been using since forever, but I don't recall having as much of an issue with the dimming as I am now. Is it intentional that when "Dynamic Sky Dimming" is disabled, all the planet flares no longer render? Basically if you disable the dimming, the mod seems to do nothing. I also kinda feel like intensity 100 is too dark for a lot of the planets as well.

Edited March 5, 2023 by Why485

[Lisias]

2 hours ago, Why485 said:

This is one of those mods that I've been using since forever, but I don't recall having as much of an issue with the dimming as I am now. Is it intentional that when "Dynamic Sky Dimming" is disabled, all the planet flares no longer render? Basically if you disable the dimming, the mod seems to do nothing.

Good catch! I confirm the glitch!

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

 

2 hours ago, Why485 said:

I also kinda feel like intensity 100 also feels kind of too dark for a lot of the planets as well.

This is a "design" decision - you kinda hardcode the maximum "brightness" of a body on its configuration. You can toy with this settings yourself if you like it by patching this file on your GameData.

On a side note, I think the current intensity is fine. Planets does not emit light, they reflect it and some planets have a lower albedo than others.

[SiCaRiO31]

Hi! I was just messing around orbiting a few bodies in sandbox and noticed that the sky dims when looking at the direction of Kerbol even when you are in LKO at the night side (meaning, there should not be any light from Kerbol to dim the sky). Is this a config issue on my part or is the code writen like that :p

[Lisias]

4 hours ago, SiCaRiO31 said:

Hi! I was just messing around orbiting a few bodies in sandbox and noticed that the sky dims when looking at the direction of Kerbol even when you are in LKO at the night side (meaning, there should not be any light from Kerbol to dim the sky). Is this a config issue on my part or is the code writen like that :p

Hi! Known issue, bug in the code! Thanks to reporting, though!

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

[Athur Dent]

Hey, thanks for continuing the development of this awesome mod!

I am playing with JNSQ + GPP + GEP (all rescaled to x2.5) and noticed that neither Ciro nor Grannus (so, both extrasolar stars in this setup) are visible from LKO despite both having a (mod author provided) DOE config.
Is there a way to manually increase the visibility of selected bodies?

After all, stars should probably be generally easier to spot than planets.

[Lisias]

23 hours ago, Athur Dent said:

I am playing with JNSQ + GPP + GEP (all rescaled to x2.5) and noticed that neither Ciro nor Grannus (so, both extrasolar stars in this setup) are visible from LKO despite both having a (mod author provided) DOE config.

UGH… I was fearing this day!!

That's the problem, DOE is kinda hardcoded into believing there's only one Sun (#highlander style), so everything else would be a piece of rock or a blob of gases - no exceptions. So all the code assumes that the flares are result of reflecting back the light of sun (with the albedo hardcoded into the body's color definition in the config and the distance being represented by the size of the flare).

And it's kinda tied to the Stock data structures to fetch the celestial bodies, and since JNSQ, GPP et all uses Kopernicus, that it' essentially a new data structure for celestial bodies that somehow were shoved into the game in a way that everything kinda works together (I really don't know how yet), DOE just can't tell if that thing waaaaaayyy there is a star that emit it's own light or a weird kind of big. really big asteroid or planet.

In theory, solving this problem is easy - once I determine that thingy far away is a star, I paint the flare no matter the distance from the Sun - as long the thing doesn't get too small to be drawn in the current resolution.

The real problem that I will need to solve to proper support Kopernicus, however, is to support multiple Suns. Right now, only Kerbol is considered a Sun in order to do all the effects (like the skybox dimming). Once you are orbiting a different Sun, DOE will be at lost because it will think that that gigantic and bright thing you are orbiting (or in orbit on something that it's orbiting it) it's just a mega sized Juno, and so the skybox will not be dimmed, for example, as you are probably really, really far away from the "real" Sun.

In a way or another: https://github.com/net-lisias-ksp/DistantObject/issues/33

 

Edited March 7, 2023 by Lisias
Tyop! Surprised?

[Athur Dent]

@LisiasSorry for being the one to bring upon you that "feared day". However, as far as I remember Galaxies Unbound has DOE flares for all its stars. Therefore I was assuming that there must be some config node already., or at least some "hack" to achieve the effect ...

Full Kopernicus support would rock, however

[Lisias]

54 minutes ago, Athur Dent said:

@LisiasSorry for being the one to bring upon you that "feared day". However, as far as I remember Galaxies Unbound has DOE flares for all its stars. Therefore I was assuming that there must be some config node already., or at least some "hack" to achieve the effect ...

Full Kopernicus support would rock, however

That hack probably got lost when I changed something on the DOE's engine, probably the code for the threshold for visible objects based in the distance they are from their "Sun".

The fix is relatively trivial - if the thing is a Star, its flare will always be painted and it will never be smaller than a pixel. The "hard" part is determining if the thing is a star.

And since I'm going the "proper" way on this, supporting multiple stars on the Sky Dimmer will also be implemented - the code was heavily refactored by many reasons, one of them is to make easier (of less difficult) to add new features as this one.

I will not make promises about a deadline, but I will work on it Soon™ enough (hopefully).

Edited March 7, 2023 by Lisias
tyops as usulla…

[G_Force080491]

Somehow, when i point mouse on Minmus flare and roll the camera relatively close to my craft, the flare name disappear. Other planets flares looks fine so far.

And can confirm Krazy1's issue. Indeed, the skybox dimming when you try to look at the planet you orbiting from the dark side, as if there is a sunlight shining through.

Thanks!

Edited March 8, 2023 by G_Force080491