[1.6.x] Distant Object Enhancement bis v1.9.1.1 (16 October 2018) - Free to a Good Home

[Chimer4]

That is the kopernicus patch from the ksprc thread. I did link directly to Thomas P's post with it

[Drew Kerman]

Skybox Dimming in v1.5.6 w/ KSP 1.0.4 also affects flare rendering. As in, you set the Skybox Dimming to 0% and no flares are rendered either. This is not how it worked in the 0.90 version...

[MOARdV]

Skybox Dimming in v1.5.6 w/ KSP 1.0.4 also affects flare rendering. As in, you set the Skybox Dimming to 0% and no flares are rendered either. This is not how it worked in the 0.90 version...

Yet before that change, I got complaints because the flares didn't dim the right way when the sky dimmed.

[Sigma88]

Yet before that change, I got complaints because the flares didn't dim the right way when the sky dimmed.

Did you really think it was going to end there?

[MOARdV]

Did you really think it was going to end there?

No. Just observing that no answer is going to be the right answer. Other than maybe adding so many config options that everyone can fine tune the behavior to their heart's content. And then there'll be an endless series of "How do I configure this?" questions.

I'll roll back the change, partially, for the next release. That way, everyone will be unhappy with it.

[Sigma88]

That way, everyone will be unhappy with it.

Probably

Honestly I think you should try to aim for the most realistic solution.

I don't really know how those things are supposed to work, but I have a feeling that the sky dimming is not related to the sun flares. (so one shouldn't affect the other)

[MOARdV]

Honestly I think you should try to aim for the most realistic solution.

I don't really know how those things are supposed to work, but I have a feeling that the sky dimming is not related to the sun flares. (so one shouldn't affect the other)

It's not actually the sun flares (lens flares, whatever you want to call them) - it's that Squad dims the sky when the sun is in view, but I don't know how to find out how much they're dimming it, so I can't account for it. And they don't do that for the actual planets, so I have to come up with a heuristic that guesses what the sun's dimming effect is, and tries to account for that, along with the dimming that DOE does for worlds that are in view, and figure out how to reconcile them. And, since DOE is a side-project mod (keeping it alive, and hopefully not making it worse), it doesn't get all of my brain cells when I *do* work on it.

If this were *my* game, I'd be using high dynamic range and automatic tonemapping, which would make everything "just work" in a natural sense. However, it's not, so I have to make semi-educated guesses at what's going on (partially based on the code that Ducky originally wrote, and bits and pieces I glean from other mods and posts on the forum), and figure out how to make it do the right thing within the black box of KSP.

I know there's a problem, and I know I can solve it if I had one missing piece of information, but I don't know how to find that missing piece, which is frustrating. But, enough ranting. I'll be dropping another update today some time, since I found & fixed a stupid null reference exception bug, anyway.

[nukeboyt]

Why don't you set it the way YOU want it and say "take it or leave it".

Try to please everybody

Get frustrated

Get burned out

Stop developing

DON'T WANT THAT!

[Sigma88]

Oh, I thought the guy's problem was that skybox dimming affected lens flares also.

Btw I didn't want to irritate you

[MOARdV]

Btw I didn't want to irritate you

I'm not irritated at anyone on the forum. I'm mildly irritated at not knowing how to get the information I need to fix the problem the right way. But, enough of that.

Distant Object Enhancement v1.5.7 is now live on GitHub and KerbalStuff. No huge changes (other than changing flare dimming again ).

• NullReferenceException in FlareDraw.OnDestroy has been fixed.
  
• Sky dimming has changed again. Flares are dimmed less aggressively, particularly for very low max brightness settings.
  
• The flare model's texture was resized and converted to .dds. If you are installing over an existing DOE, please make sure to delete GameData/DistantObject/Flare/model000.png
  

[Drew Kerman]

woah Ok, I do remember people talking about flares not dimming properly, but I thought I was reporting a bug because I did not make any connection between "Skybox" and "flares". To me, the "Skybox" setting is referring to the texture of the skybox, so setting that dim or bright should only affect the background stars. I thought flares were a separate thing - they even have their own brightness settings. So I wasn't expecting the Skybox Diming setting to affect them in any way.

[MOARdV]

woah Ok, I do remember people talking about flares not dimming properly, but I thought I was reporting a bug because I did not make any connection between "Skybox" and "flares". To me, the "Skybox" setting is referring to the texture of the skybox, so setting that dim or bright should only affect the background stars. I thought flares were a separate thing - they even have their own brightness settings. So I wasn't expecting the Skybox Diming setting to affect them in any way.

Skybox dimming affects flare brightness - otherwise, the flares would look very strange when the sky fades to black, but the flares do not (especially with a high skybox brightness).

[ebigunso]

Wouldn't squad tell you these things if you send them a question? Or if you make out your own alternate solution to the stock effects and send that over as a proposal, maybe they'd consider it.

I do think it's a good thing to not bother them so much, but if working it out by yourself is as hard as you say, I say you should take the problem up to squad also.

I'd really love to see your visions come true, of a truly magnificent view of space!

[Weywot8]

Was going through my manual mod update (CKAN works great but then I'd still need to read up on the forums anyway, in case of significant changes) and have to say thanks for all the effort!

To a certain extent, there comes a point where "realism" becomes a subjective human matter vs. Kerbal physiology, i.e. your artistic/modder vision. All things being equal physics-wise, if those huge Kerbal eyes have a wider dynamic range than humans/different power scaling, they would see the universe quite differently, as reflected in your KSP visuals.

See https://en.wikipedia.org/wiki/Weber%E2%80%93Fechner_law - psychophysics affects everything from how NASA processes images to how supermarkets light their meat & fresh produce (and why makeup can go soooo badly wrong when leaving the house ).

[Olsson]

https://www.dropbox.com/s/5iht89g3khmjw91/output_log.txt?dl=0

First of all I'm using 64-bit Windows so this might in itself be the problem.

Whenever I go inbetween scenes such as recovering vessels, tracking station to ship, back to space center, etc. My game freezes up completely.

This will happen very often for me recently and I don't know what is causing it.

At the end of my output_log I saw this message related to Distant object enhancement:

Distant Object Enhancement v1.5.7 -- BodyFlare (null bodyflare?) Destroy

[Olympic1]

First of all I'm using 64-bit Windows so this might in itself be the problem.

Did you mean KSP 64-bit?

Whenever I go inbetween scenes such as recovering vessels, tracking station to ship, back to space center, etc. My game freezes up completely.

This will happen very often for me recently and I don't know what is causing it.

At the end of my output_log I saw this message related to Distant object enhancement:

Distant Object Enhancement v1.5.7 -- BodyFlare (null bodyflare?) Destroy

Try it on KSP 32-bit and see if your games freezes when changing scenes

[taniwha]

Olsson: If you really need 64-bit KSP, then I strongly recommend using Linux: it is much more stable, and (more importantly) modders will not yell at you.

[MOARdV]

https://www.dropbox.com/s/5iht89g3khmjw91/output_log.txt?dl=0

First of all I'm using 64-bit Windows so this might in itself be the problem.

Whenever I go inbetween scenes such as recovering vessels, tracking station to ship, back to space center, etc. My game freezes up completely.

This will happen very often for me recently and I don't know what is causing it.

At the end of my output_log I saw this message related to Distant object enhancement:

Distant Object Enhancement v1.5.7 -- BodyFlare (null bodyflare?) Destroy

Those are harmless debug messages I forgot to remove from DOE. The last thing in the log is a status message from PlanetShine. You have a large number of exceptions in that log, but none of them I saw are from DOE. If you're running a 64 bit version of KSP in Windows, I strongly suggest using 32 bit. 64 bit Windows KSP is unsupported.

[Olsson]

Those are harmless debug messages I forgot to remove from DOE. The last thing in the log is a status message from PlanetShine. You have a large number of exceptions in that log, but none of them I saw are from DOE. If you're running a 64 bit version of KSP in Windows, I strongly suggest using 32 bit. 64 bit Windows KSP is unsupported.

Are exceptions bad in general? Are they something I should aim to fix?

Yeah I know, this was a longshot and I'm not really expecting anything to come out of this because I'm running 64-bit.

Did you mean KSP 64-bit?

Try it on KSP 32-bit and see if your games freezes when changing scenes

Yes KSP 64-bit. I don't think 32-bit can handle my amount of mods and will run out of RAM.

Olsson: If you really need 64-bit KSP, then I strongly recommend using Linux: it is much more stable, and (more importantly) modders will not yell at you.

I've thought about it. But 1. I don't want to install and adjust to new OS just to be able to play KSP. 2. GEMFX Injector is not compatible with Linux (or so I've heard).

[Landwalker]

Are exceptions bad in general? Are they something I should aim to fix?

Yeah I know, this was a longshot and I'm not really expecting anything to come out of this because I'm running 64-bit.

Yes KSP 64-bit. I don't think 32-bit can handle my amount of mods and will run out of RAM.

I've thought about it. But 1. I don't want to install and adjust to new OS just to be able to play KSP. 2. GEMFX Injector is not compatible with Linux (or so I've heard).

If I may make a recommendation that has worked very well for me: Force-run KSP in DirectX 11. That's what I do for my mod-overloaded mission log career (87 /GameData/ sub-folders and hopefully not counting anymore!), and I've only noticed a couple of very minor graphical glitches. And unlike OpenGL, it doesn't erase shadows.

I've actually had screens similar to what you experienced (I noticed you didn't link the image here, but I saw it in the SETI thread), but my game "recovered" after a second or two rather than crashing.

[MOARdV]

Are exceptions bad in general? Are they something I should aim to fix?

The exceptions I saw are mostly "Null Reference Exceptions", which indicate some data objects in the game don't exist at a time they're assumed to be valid. It could be a problem with the mods (I know I've had my share of those), or it could be that there's something substantially different about the 64 bit Windows KSP that changes the when data becomes unavailable. Short of trying the same configuration with 32 bit KSP and seeing which exceptions are still present, I can't say for sure which problem is the source of the exception. If the exceptions don't happen in 32 bit, then the problem is in the 64 bit version. If they're still present, it likely indicates some bugs in mods that should be fixed.

[chuckles73]

I haven't been able to see flares for ships/satellites/debris since ksp 0.25. I tried messing around with dynamic dimming, flare brightness, distant vessel rendering, etc, to no avail. While it's nice to see planets from far out, the coolest part of this mod for me was always seeing my satellite constellations zip around the planet. Could this be something like active texture management messing with the flare textures? Or maybe opengl mode failing? Or... I don't know, something else I can fix?

[MOARdV]

I haven't been able to see flares for ships/satellites/debris since ksp 0.25. I tried messing around with dynamic dimming, flare brightness, distant vessel rendering, etc, to no avail. While it's nice to see planets from far out, the coolest part of this mod for me was always seeing my satellite constellations zip around the planet. Could this be something like active texture management messing with the flare textures? Or maybe opengl mode failing? Or... I don't know, something else I can fix?

It's most likely something that I messed up, or something that changed in KSP that I didn't account for when 1.0 came out. I see the vessel flares (sometimes), but they're often in the wrong place, especially when you're close to them. I have not been able to figure out what's gone wrong with it, since the math hasn't changed.

[Motokid600]

I take it the flares are broken on Win32 as well? MOARdv forgive me, but i went ahead and made a thead on addon affairs for what it counts. The broken flares are essential to me so id like to see what others can come up with as to what could be causing it.

[MOARdV]

I take it the flares are broken on Win32 as well? MOARdv forgive me, but i went ahead and made a thead on addon affairs for what it counts. The broken flares are essential to me so id like to see what others can come up with as to what could be causing it.

No forgiveness needed. I don't know Unity / KSP-usage-of-Unity well enough to quickly diagnose and solve the problem. It's possible I broke something while refactoring the code, but I don't see it. I may set RasterPropMonitor aside for a week or two and try some more focused effort on those uncooperative vessel flares, but some outside eyes that know their way around could make the process quicker.