Jump to content

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


Lisias

Recommended Posts

  On 1/9/2022 at 9:05 PM, Krazy1 said:

Hi Lisias. One more request... make it work for asteroids. Right now it's showing only a small dot from physics range out to DOE setting for max rendering range. Then it suddenly blinks into full detail at the edge of physics range. With a class A it's probably not too noticeable but a Class E certainly is. It went from about 1 mm diameter white dot to 2 cm full detail as I approached it. 

It might be an extra challenge for new asteroids because they are "unowned" and KSP might not even spawn the details of the asteroid until it first enters physics range... just a guess. 

Thanks and good luck with this and IRL.

Expand  

Request recorded: https://github.com/net-lisias-ksp/DistantObject/issues/17

Yep, this is going to need a "new engine" for it. Asteroids, as far as I know, are a special kind of "vessel" - AFAIK it's like a debris from the physics point of view. What means it goes to rails and from it - what can make things a bit easier with a bit of luck.

On a superficial analysis, it can make my life a bit easier as I think I can use the OnRails and OffRails events to detect when DOE should draw the blinking lights and when it does not.

It's an issue on github now: https://github.com/net-lisias-ksp/DistantObject/issues/17

Cheers!

Link to comment
Share on other sites

  • 3 weeks later...

I've been seeing problems (that is, no distant object flares show up at all) with DOE in planet-pack systems where the homeworld is reparented to orbit other planets- is this a known issue, and if so is there any fix? Problem encountered using KSP 1.12.2 and the Whirligig World planet pack, but would likely be replicable in other reparented systems like Alternis Kerbol Rejiggered.

Link to comment
Share on other sites

  On 1/30/2022 at 9:35 AM, Tangle said:

I've been seeing problems (that is, no distant object flares show up at all) with DOE in planet-pack systems where the homeworld is reparented to orbit other planets- is this a known issue, and if so is there any fix? Problem encountered using KSP 1.12.2 and the Whirligig World planet pack, but would likely be replicable in other reparented systems like Alternis Kerbol Rejiggered.

Expand  

I was not aware of that. If no flares are being shown, it's highly probable an exception was thrown inside DOE killing the thread. Please publish your log file on dropbox or something or, if you have a github account, on a comment on this issue:  https://github.com/net-lisias-ksp/DistantObject/issues/18

Link to comment
Share on other sites

  On 1/30/2022 at 12:27 PM, Lisias said:

I was not aware of that. If no flares are being shown, it's highly probable an exception was thrown inside DOE killing the thread. Please publish your log file on dropbox or something or, if you have a github account, on a comment on this issue:  https://github.com/net-lisias-ksp/DistantObject/issues/18

Expand  

I'm putting KSP.log here, so apologies if you meant the modulemanager logs or something. In particular, I found the phrase
[EXC 04:50:18.175] Exception: Distant Object -- Unable to find Kerbin's relationship to Kerbol.
    DistantObject.FlareDraw.GenerateBodyFlares () (at <9b673f98181d4f2ab320f3a8099485cd>:0)
    DistantObject.FlareDraw.Awake () (at <9b673f98181d4f2ab320f3a8099485cd>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.GameObject:AddComponent(Type)
    AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup)
    AddonLoader:StartAddons(Startup)
    AddonLoader:OnLevelLoaded(GameScenes)
    AddonLoader:OnSceneLoaded(Scene, LoadSceneMode)
    UnityEngine.SceneManagement.SceneManager:Internal_SceneLoaded(Scene, LoadSceneMode)

inside, which I suspect is the issue- will be starting KSP with all the Kerbin-related DOE stuff deleted to see if this provides a temporary fix.

https://drive.google.com/drive/folders/17dv1_txbkhFRJloxqPOOTYdmfOhPNmo_?usp=sharing Apologies for the drive link, it was the only thing I had handy.

 

I'll be testing what happens if I remove the DOE definitions for Kerbin- maybe that'll do it, if only as a stopgap measure?

UPDATE: Same exception still fires. I guess it's just looking for Kerbin anyway? Maybe if I remove *all* the DOE references to Kerbin, but that's pretty invasive for a stopgap fix.

Edited by Tangle
update
Link to comment
Share on other sites

  On 1/30/2022 at 10:07 PM, Tangle said:

I'm putting KSP.log here, so apologies if you meant the modulemanager logs or something. In particular, I found the phrase

<snipped by me>

inside, which I suspect is the issue- will be starting KSP with all the Kerbin-related DOE stuff deleted to see if this provides a temporary fix.

Expand  

Yep, it's it. FlareDraw is tied to the Stock, it doesn't knows how to handle Kopernicus. I need to rework FlareDraw in order to allow adding "engines" or "drivers" to it (as I did on VesselDraw), so I (or anyone else) could just write a new one for it to handle Kopernicus.

O added this to the issue on github, I will work on it on my next window for DOE.

 

  On 1/30/2022 at 10:07 PM, Tangle said:

https://drive.google.com/drive/folders/17dv1_txbkhFRJloxqPOOTYdmfOhPNmo_?usp=sharing Apologies for the drive link, it was the only thing I had handy.

Expand  

Not a problem at all. The important thing is to have KSP.log available for downloading somehow.

 

  On 1/30/2022 at 10:07 PM, Tangle said:

I'll be testing what happens if I remove the DOE definitions for Kerbin- maybe that'll do it, if only as a stopgap measure?

UPDATE: Same exception still fires. I guess it's just looking for Kerbin anyway? Maybe if I remove *all* the DOE references to Kerbin, but that's pretty invasive for a stopgap fix.

Expand  

It will not work, unfortunately. The definitions you found is to colorize the planet's flares with its dominant colours - and this is going to be needed anyway later.

The problem at hands is that DOE understand how Stock handles the Sun and Planets, but doesn't knows squat (yet) about Kopernicus.

The first step is to do on FlareDraw what I did on VesselDraw, create a kind of "engine" or "driver" so I can decoupe Stock specific code from the "business logic", and so adding Kopernicus later would be easier - and without compromising Stock only games.

Link to comment
Share on other sites

  On 1/31/2022 at 1:39 AM, Lisias said:

Yep, it's it. FlareDraw is tied to the Stock, it doesn't knows how to handle Kopernicus. I need to rework FlareDraw in order to allow adding "engines" or "drivers" to it (as I did on VesselDraw), so I (or anyone else) could just write a new one for it to handle Kopernicus.

Expand  

The dev of the planet mod I was using when I discovered this says: "you should look into how kopernicus does universal body identifiers as a way of identifying a planet when the in game name changes in things like homeworld switches". Hopefully that's helpful :v

Link to comment
Share on other sites

  On 1/31/2022 at 2:03 AM, Tangle said:

The dev of the planet mod I was using when I discovered this says: "you should look into how kopernicus does universal body identifiers as a way of identifying a planet when the in game name changes in things like homeworld switches". Hopefully that's helpful :v

Expand  

Well, it just confirms my diagnosis. :)

In Stock, the celestial bodies can be found on the FlightGlobals.Bodies array, On Kopernicus, they are somewhere else.

Link to comment
Share on other sites

  • 2 weeks later...
  On 2/9/2022 at 10:49 AM, septemberWaves said:

What does it mean that this doesn't support ReStock? ReStock is just a parts mod, what would need to be supported?

Expand  

ReStock is replacing some Stock Modules by customised ones, and so I need to "teach" DOE how to cope with these customised modules!

DOE was working fine until the introduction of these modules, as documented on the respective issue!

It's not a big of an issue, but RL is bitting harsh in the last 4 months so I didn't had the time to tackle this one yet.

Link to comment
Share on other sites

  • 2 weeks later...

Hello @Lisias.  I hope you are doing well.  This is actually a mod I use, so great to see you picking it up. :)

Kopernicus is doing some frankly, janky crap, that I wish didn't work as well as it does to fix the sinking-landing-gear-on-distant-bodies bug.  But it does and so here we are.  I'm sure you've been there.  KSP is a mystery on some days.

The idea is a mock-invisible moho-sized celestial is placed between the craft and system root at a set distance.  Anyways, you can see how this is weird because this body does end up in FlightGlobals.bodies and of course, DOE tries to draw flares for it.

IF you want to link to Kopernicus, the easiest way to filter it is like so:

            List<CelestialBody> filteredBodies = FlightGlobals.Bodies;
            if (filteredBodies.Contains(Kopernicus.RuntimeUtility.RuntimeUtility.mockBody))
            {
                filteredBodies.Remove(Kopernicus.RuntimeUtility.RuntimeUtility.mockBody);
            }

I imagine you'd probably prefer to iterate through though and not link to Kopernicus.  In that case, just filter by CelestialBody.name.  The name is "KopernicusWatchdog"  No other body should be named that ever.

I can maintain a patchset or even make a PR for you, but I imagine such a change would be easy for you to do too if you don't mind mainlining.  Let me know your plans.

PS:  This "Watchdog" is an optional Kopernicus addon and probably affects less than 25% of the userbase, if it makes a difference to you, but I'd still like mods to be aware of it.

  On 2/20/2022 at 11:40 PM, Kwebib said:

@Lisias DOE shows a "Kopernicus Watchdog" flare (a fake planet being used to alleviate a Kopernicus bug). Do you think you could write a patch to exclude this celestial body? See here:

Kopernicus Thread Comment

 

Expand  

Ah we posted at the same time lol.

Edited by R-T-B
Link to comment
Share on other sites

  On 2/20/2022 at 11:40 PM, Kwebib said:

@Lisias DOE shows a "Kopernicus Watchdog" flare (a fake planet being used to alleviate a Kopernicus bug). Do you think you could write a patch to exclude this celestial body? See here:

Kopernicus Thread Comment

 

Expand  

Sure thing! I will add a blacklist to DOE, and then I will apply a pull request to Kopernicus with a patch populating it.

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

I have defined a roadmap for DOE, I (hopefully) will retake development for the next iteration next WeekEnd.

Cheers!

 

  On 2/20/2022 at 11:43 PM, R-T-B said:

Hello @Lisias.  I hope you are doing well.  This is actually a mod I use, so great to see you picking it up. :)

Expand  

Hi! I'm alive and kicked!! :sticktongue:

Thanks! :)

 

  On 2/20/2022 at 11:43 PM, R-T-B said:

Kopernicus is doing some frankly, janky crap, that I wish didn't work as well as it does to fix the sinking-landing-gear-on-distant-bodies bug.  But it does and so here we are.  I'm sure you've been there.  KSP is a mystery on some days.

Expand  

Dude, you are talking to the Crazy SAS than maintains KSP-Recall. :sticktongue: I feel your pain (we are all masochists…)

 

  On 2/20/2022 at 11:43 PM, R-T-B said:

I imagine you'd probably prefer to iterate through though and not link to Kopernicus.  In that case, just filter by CelestialBody.name.  The name is "KopernicusWatchdog"  No other body should be named that ever.

Expand  

Yep, this is the way I'm going - I will implement a generic solution and then a Config where people can patch their exclusions.

What I intend to do is allow 3rd parties to do things more or less like this one:

@DistantObject:AFTER[DistantObject]:NEEDS[Kopernicus,DistantObject]
{
    @DistantFlare
    {
        @CelestialBody
        {
            @ExclusionList
            {
                name = KopernicusWatchdog
            }
        }
    }
}

Or something like that (don't take this as a Specification yet).

Usually, I think it's not the most productive idea to have these dependencies on the main distribution - experience on TweakScale taught me that the main distribution ideally should be the minimal as possible (i.e., support Stock and DLCs) and additional support implemented by interested 3rd parties or even on "Companions". Any changes on your side, and we don't need to release a new DOE version - and once this feature is published, it will not be changed (worst case scenario, I built a new feature to complement this one, but whatever I do here will be set on stone).

Thoughts?

 

  On 2/20/2022 at 11:43 PM, R-T-B said:

PS:  This "Watchdog" is an optional Kopernicus addon and probably affects less than 25% of the userbase, if it makes a difference to you, but I'd still like mods to be aware of it.

Expand  

Better yet! We can confine the patch to it, removing DOE's and Kopernicus' from the line of fire!

 

  On 2/20/2022 at 11:43 PM, R-T-B said:

Ah we posted at the same time lol.

Expand  

And I was typing this message in the mean time, refreshing the page to see what's going on!!! :D 

Edited by Lisias
Updating Node specification. See https://github.com/net-lisias-ksp/DistantObject/issues/19
Link to comment
Share on other sites

  On 2/21/2022 at 12:15 AM, Lisias said:

Usually, I think it's not the most productive idea to have these dependencies on the main distribution - experience on TweakScale taught me that the main distribution ideally should be the minimal as possible (i.e., support Stock and DLCs) and additional support implemented by interested 3rd parties or even on "Companions". Any changes on your side, and we don't need to release a new DOE version - and once this feature is published, it will not be changed (worst case scenario, I built a new feature to complement this one, but whatever I do here will be set on stone).

Thoughts?

Expand  

I like the philosophy and can go with it.  As you can see, a lot of Kopernicus's more esoteric features are optional cfgs now where possible, so I certainly use that philosophy myself.

  On 2/21/2022 at 12:15 AM, Lisias said:

Better yet! We can confine the patch to it, removing DOE's and Kopernicus' from the line of fire!

Expand  

That will be easy if DOE can understand the exclusion list (obviously that needs to be added).  I will await a spec and then I can easily make up the patch in the same file.

  On 2/21/2022 at 12:15 AM, Lisias said:

Dude, you are talking to the Crazy SAS than maintains KSP-Recall. :sticktongue: I feel your pain (we are all masochists…)

Expand  

Between you and I, I think we have a contest for who can go the most insane, yeah... lol.  I finally just said "no stock issues" to save my sanity.

Link to comment
Share on other sites

  • 3 weeks later...

Hi, I think I've found a new bug in this mod. (KSP 1.12.3  DOE 2.1.1.6)

I searched if this error was reported before in this (and in the previous manteiners) topic unsuccessfully.

It happens when the "Distant Vessel Rendering" is enabled and two (or more) vessels are in the distance threshold specified by the mod, the FPS drop from 60 to 20 (even with small relay satellite) and stops when the vessel reach the stock render distance.

This is the error that appears in the logfile.

  Quote

[EXC 15:52:49.559] ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.
    System.Reflection.Assembly.GetTypes () (at <9577ac7a62ef43179789031239ba8798>:0)
    KSPe.Util.SystemTools+TypeFinder.FindByInterface (System.Type ifc) (at <9f7cd9a529194dc4a60f3cf218f8503b>:0)
    DistantObject.Contract.MeshEngine.CreateFor (Vessel vessel) (at <e30ec9083ad44f3d8c362bd51ed054ea>:0)
    DistantObject.VesselDrawDatabase.VesselCheck (Vessel vessel) (at <e30ec9083ad44f3d8c362bd51ed054ea>:0)
    DistantObject.VesselDraw.CheckDraw (Vessel vessel) (at <e30ec9083ad44f3d8c362bd51ed054ea>:0)
    DistantObject.VesselDraw.Update () (at <e30ec9083ad44f3d8c362bd51ed054ea>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
[LOG 15:52:49.559] [ModuleManager] Intercepted a ReflectionTypeLoadException. List of broken DLLs:

[EXC 15:52:49.600] ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.

Expand  

Modlist

  Reveal hidden contents

I have ReStock installed but i am not sure if it is the culpript in this case.

Almost everything was installed by CKAN

 

P.S. Sorry for my English, it isn't my first language.

Edited by ISO
Link to comment
Share on other sites

  On 3/8/2022 at 4:29 PM, ISO said:

Hi, I think I've found a new bug in this mod. (KSP 1.12.3  DOE 2.1.1.6)

I searched if this error was reported before in this (and in the previous manteiners) topic unsuccessfully.

It happens when the "Distant Vessel Rendering" is enabled and two (or more) vessels are in the distance threshold specified by the mod, the FPS drop from 60 to 20 (even with small relay satellite) and stops when the vessel reach the stock render distance.

Expand  

I think it may be a interaction with some other add'on, because I had tested it on a pretty complex scenario and it worked fine - but only using Stock (and TweakScale) to tell you the true….

See, the following picture has two small crafts on the scene, all of them pretty far from the focused craft:

136482674-587d4a79-b637-41b7-9729-9db9ee

 

Another one, daylight this time:

135759693-4193b931-9989-4196-bf74-9bc346

 

I must have a screenshot somewhere on my rig with at least 4 or 5 crafts in the camera range, but beyound the physics, somewhere here… Anyway, the source for your problem appears to be something else.

Please reproduce the problem again, then quit KSP (to prevent it from truncating the log) and then publish your WHOLE KSP.log using dropbox or something so I can inspect it and see exactly what't happening.

Sometimes, the Exception you see is only a collateral effect of another one you are not seeing, and the KSP.log will help me if this is what's happening with you.

Edited by Lisias
whoopsy...
Link to comment
Share on other sites

I have run into a problem which seems to be caused by DOE.  I installed Poods skyboxes and they were too dim.  He says to use DOE to adjust the brightness.  I did this and all was well for a while.  I turned the brightness up to 100% and turned the dimmer off. 

Then a problem cropped up.  The skybox would get dimmer until there was nothing but solid black everywhere.  My workaround is to install DOE, set it to 100% and dimmer off, then uninstall it.  This seems to work so far.

Link to comment
Share on other sites

  On 3/10/2022 at 8:57 PM, miklkit said:

I have run into a problem which seems to be caused by DOE.  I installed Poods skyboxes and they were too dim.  He says to use DOE to adjust the brightness.  I did this and all was well for a while.  I turned the brightness up to 100% and turned the dimmer off. 

Expand  

Nope. It's normal DOE behaviour! :)

It's the SkyBox dimmer. Every time you look to a planet or a Sun, the skybox will be dimmed.

 

  On 3/10/2022 at 8:57 PM, miklkit said:

Then a problem cropped up.  The skybox would get dimmer until there was nothing but solid black everywhere.  My workaround is to install DOE, set it to 100% and dimmer off, then uninstall it.  This seems to work so far.

Expand  

Humm… Looks like a side effect of the issue #15. In fact, uninstalling DOE and the current SkyBox dimming being perpetuated is, by itself, a bug - more probably a new side effect of the #15.

As I said on the Poods Skyboxes thread, I'll pursue a workaround for what you need without DOE, as I expect that by fixing #15 the workaround you are relying to will cease to work!

Thanks for the head's up!

Link to comment
Share on other sites

  • 1 month later...

ANNOUNCE

Release 2.1.1.7 is available for downloading, with the following changes:

  • A major screwup on Mono's libraries was detected and worked around by KSPe.Light.
    • Whole history available here.
  • Formalizes support for KSP 1.3.1. #HURRAY!!

I'm not 100% certain, but all the tests I made suggests I found a File Handler leakage on a Mono's low level library used by KSPe.Light. This Release merely update KSPe.Light to a version where the problem was (apparently) successfully worked around.

On the bright side, I spent a lot of time playing KSP 1.3.1 lately (just because I could), and DOE /L behave perfectly. So I'm formalising the KSP 1.3.1 support on this Release.

No screenshots this time, I'm in hurry. Again…  :P 

See OP for the links.

— — — — —

This Release will be published using the following Schedule:

The rationale is to gradually deploy the thing in order to cope with eventual mishaps before it reaches too much people.

Edited by Lisias
All your Distribution Channels are belong to us!! =P
Link to comment
Share on other sites

  • 1 month later...

Hi - wanted to share an observation I've been having and see what role DOE plays in this. Here's a screenshot:

  Reveal hidden contents

(It probably needs to be expanded to full size to see the issue I'm asking about)

So this is an atmospheric probe descending into Saturn's atmosphere. The issue I have here is Earth, Mars, and Venus. They are perfect little textbook-colored dots, whereas the rest of the starfield has been dimmed as expected since we're looking right into the sun.

Does starfield dimming not apply to planets as well?

 

Link to comment
Share on other sites

  On 5/27/2022 at 6:36 PM, OrbitalManeuvers said:

Does starfield dimming not apply to planets as well?

Expand  

Nope, the dimming is only applied to the skybox. Planet blinking and skybox dimming are, currently, completely different and independent modules.

In a way or another, I opened a issue so I don't forget to look on it when I (finally) have time again for development. Feel free to add any considerations (as space photographs with the phenomena) to it!

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

Cheers!

Link to comment
Share on other sites

Hi, I've encountered a weird graphical bug that I've not seen mentioned elsewhere. Object flares are only appearing at the very edge of the screen on the left and right, but aren't there otherwise. I can still mouse over and see the nametags appear, but there aren't any flares where they should be unless I rotate the field of view until they're at the edges of my screen. Once they pop in, they behave normally and respond to changing settings. If I disable skybox dimming, they stop appearing altogether. I'm running a bunch of other mods that I've been slowly adding to the game, unfortunately I didn't notice when this started happening so I can't pinpoint which mods might have conflicted with it, but I've had DOE on from the start and this didn't always happen.

Editing to add - looking at it again and I've noticed that there seems to be a radial threshold where the flares are popping in. Outside of a certain radius, the flares are appearing as normal, but at the radius they are cut off and aren't seen inside. Screenshot here shows a flare clipping this radius.

Thanks!


Modlist below

  Reveal hidden contents

 

Edited by Tomahol1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...