[1.8.1 - 1.9.1] Kopernicus Continued

[ra4nd0m]

I think there were some nasty bugs with black ocean in GPP when installed as secondary system. Investigating.

Nevermind. Clean install fixed the issue

11 hours ago, R-T-B said:

#Kopernicus_UI_AbsoluteExposure = Абсолютная освещенность // Используется абсолютная освещенность

#Kopernicus_UI_RelativeExposure = Относительная освещенность // Используется относительная освещенность

This won't work the window is not large enough. The word Используется can be safely removed i think. Исходя из контекста можно это слово опустить. Кнопка все равно переключатель. In many software in that context this word is not used. So I think there will be no misunderstanding.

Edited July 23, 2020 by ra4nd0m

[crazyduck]

11 hours ago, Jognt said:

Sounds like you’re saying both “It works with just reverting these two commits!” and asking “Do I need to revert more to make it work?” at the same time?

I’m sure it’s ‘technically’ possible to support all levels of detail. From the sound of it, that would be a pretty big unpaid time investment for very little gain.

If you want to thoroughly test the code on differing detail settings with all planet packs & possible config settings: Go for it.

If not: Please don’t assume others should want to either.  

Possible you did not understand me or i asked wrong.

I know it work like i can change shader settings and i do not get any bugs with that.

Question is more if there are other commits that still set somethign in background to max shaders .

and sure i could dig through the code and check that, btu i thougth asking the peopel who added the new forced settings  is easier cause this people should know that .

Oh and do not assume others should want anything , but as i said, i reverted 2 commits and it seems to work without issues,.

But since Thomas said it would be much work to support different shader settings again , i´m not sure if this commits are everything that must be changed to really remove any forced shader settings in background.

And the unpaid time investment for little gain , really not sure about the little gain but also if it does not support it why block the settings? Its a simple thing to remove the blocked setting and let the users decide, that would not be big unpaid time investment that would be few minutes to change that and changing the text telling you you cannot change the setting into something like a warnign also does not take that much time.

Edited July 23, 2020 by crazyduck

[Beetlecat]

2 hours ago, MashAndBangers said:

"We fixed the fix that fixed the fix when fixing the fix that fixed that other fix that fixed the bug that's actually a feature."  ~developers

 

"please revert to the latest update by updating the revision that reverts the update to the revision"

Mind you, moose bites can be nasti!

[R-T-B]

On 7/23/2020 at 11:38 AM, ra4nd0m said:

This won't work the window is not large enough. The word Используется can be safely removed i think. Исходя из контекста можно это слово опустить. Кнопка все равно переключатель. In many software in that context this word is not used. So I think there will be no misunderstanding.

Thanks, I will revert that bit of the change.

[etmoonshade]

Okay, so I downloaded Kopernicus Continued a few weeks ago, and used it with Sigma Dimensions/RESCALE! with no issues. I downloaded the most recent version, and suddenly I'm getting NyanCat and a bunch of warnings all over the place? Did a version check get re-enabled somewhere? :V

Edit: I'm on 1.10, hence the assumption that a version check got re-enabled. Last version I downloaded was 1.9.1-3.

Second Edit: Yup, reverting to 1.9.1-3 gives me no warnings.

Edited July 25, 2020 by etmoonshade

[R-T-B]

Yeah, we version check now.  It was always supposed to be on.

True ready and proper 1.10 is available though, in my bleeding edge branch.  It's not as scary as it sounds, it's basically the same features as here with just an occasional experimental patch for a bug here and there:

We are waiting to officially support 1.10 until patch 1 or whatever comes out.

Edited July 26, 2020 by R-T-B

[Black-Two-]

10 hours ago, R-T-B said:

We are waiting to officially support 1.10 until patch 1 or whatever comes out.

By the way, has there been any word from Squad on this yet? The 1.10.1 patch seems like it's taking longer than the .1 patches usually do. 

Edited July 26, 2020 by Black-Two-

[Shawn Kerman]

5 hours ago, Black-Two- said:

By the way, has there been any word from Squad on this yet? The 1.10.1 patch seems like it's taking longer than the .1 patches usually do. 

For all we know they won't do one.

[R-T-B]

8 hours ago, Black-Two- said:

By the way, has there been any word from Squad on this yet? The 1.10.1 patch seems like it's taking longer than the .1 patches usually do. 

Not that I know of.  But there are a lot of bugs, so almost certainly has to be one.

2 hours ago, Shawn Kerman said:

For all we know they won't do one.

Don't say things like that...  It's not like we are dealing with a real monkey squad.

*laughs nervously*

[AlphaMensae]

1.10.1 was confirmed on the KSPTV stream.

[R-T-B]

3 hours ago, AlphaMensae said:

1.10.1 was confirmed on the KSPTV stream.

Good.  The monkey squad did the right thing, I appreciate.

Squad tends to need one good bugfix as of late, IMO.  Unlike us...  uh, we try, ok?

Edited July 27, 2020 by R-T-B

[AlphaMensae]

They also said that 1.11 is being worked on as well, but no details were given. So get ready!  

Edited July 27, 2020 by AlphaMensae

[R-T-B]

1 minute ago, AlphaMensae said:

They also said that 1.11 is being worked on as well, but no details were given. So get ready!  

If they release them at the same time just to mess with us...  lol.

Seriously, that's what bleeding edge is for.  We'll have 1.11 working...  sorta/kinda probably within one day.  Just be careful, it may bite.

Edited July 27, 2020 by R-T-B

[Hohmannson]

Well, i was blaming Scatterer or pack makers but it seems to be related to Kopernicus, currently this is a problem on JNSQ Jool moons and BH Armstrong. Logs with Pol lithobraking are attached. Reproduction note - may require to go space center and back(not f5 f9) for glitches to appear. https://yadi.sk/d/TKG8o0OA3sjjtA

 

[R-T-B]

5 hours ago, Hohmannson said:

Well, i was blaming Scatterer or pack makers but it seems to be related to Kopernicus, currently this is a problem on JNSQ Jool moons and BH Armstrong. Logs with Pol lithobraking are attached. Reproduction note - may require to go space center and back(not f5 f9) for glitches to appear. https://yadi.sk/d/TKG8o0OA3sjjtA

 

I appreciate the detailed write up, with an easy to use means to reproduce this.

Unfortunately, I have no idea what this is...  have not seen it in my personal save either.  I feel it could actually be a stock 1.9 issue with shadow tiling (they reduced shadow precision in 1.9) and it relates to the new shadows distance clipping issues some have reported.  A few things you can try to fix:

1.)Install scatterer and use it's terrain shadow system in the interim (this is probably why I haven't seen it, I use scatterer).

or

2.)You could try turning off "celestial bodies cast shadows" in settings.

3.)  If it really is a stock bug, running in OpenGL mode (google how) will fix it by forcing the old shadow precision, albeit at a large performance cost.

 

I have a feeling when squad finally fixes this, this bug will dissapear, and it won't end up being on Kopernicus's end.  Still, we are aware and investigating, and your reproducible case helps.

 

Edited July 27, 2020 by R-T-B

[Hohmannson]

Sadly, those 3 not helped. Yes, even openGL. After some scene changes I saw that the checkers closer to my vessel are smaller, at any angle. And it seems to not affect BUILTIN surface textures and some custom too. Will try to investigate those cursed materials tomorrow.

[OhioBob]

1 hour ago, R-T-B said:

Unfortunately, I have no idea what this is...  have not seen it in my personal save either.  I feel it could actually be a stock 1.9 issue with shadow tiling (they reduced shadow precision in 1.9) and it relates to the new shadows distance clipping issues some have reported.

This is a pretty common problem.  I think it started in KSP 1.8.1, so I suspect it might be related to the terrain shader introduced in that version.  It's not specifically a JNSQ problem, it occurs in other planet packs as well.  I've heard the problem can also be seen occasionally in stock, though I haven't witnessed that myself.  I have no firm evidence of this, but from my own observations it seems to happen more frequently on larger celestial bodies.  This would explain why the problem is seen more often in JNSQ, since it is build to a larger scale than other planet packs.

[R-T-B]

17 minutes ago, Hohmannson said:

Sadly, those 3 not helped. Yes, even openGL. After some scene changes I saw that the checkers closer to my vessel are smaller, at any angle. And it seems to not affect BUILTIN surface textures and some custom too. Will try to investigate those cursed materials tomorrow.

  

7 minutes ago, OhioBob said:

This is a pretty common problem.  I think it started in KSP 1.8.1, so I suspect it might be related to the terrain shader introduced in that version.  It's not specifically a JNSQ problem, it occurs in other planet packs as well.  I've heard the problem can also be seen occasionally in stock, though I haven't witnessed that myself.  I have no firm evidence of this, but from my own observations it seems to happen more frequently on larger celestial bodies.  This would explain why the problem is seen more often in JNSQ, since it is build to a larger scale than other planet packs.

It is odd I have never witnessed it with scatterer installed.  That's what leads me towards shadows.

If you are attempting to fix this with scatterer (Option #2), it appears JNSQ does not allow scatterer to take control of shadows, so you may be getting a bad result there if you don't couple scatterer with the following fix to JNSQ:

GameData\JNSQ\JNSQ_Configs\Scatterer\config.cfg, replace:

@Scatterer_config:AFTER[scatterer]
{
    @m_fourierGridSize = 64
    @terrainShadows = False
    @shadowsDistance = 5000
}

 

With this instead:

 

@Scatterer_config:AFTER[scatterer]
{
    @m_fourierGridSize = 64
    @terrainShadows = True
    @shadowsDistance = 50000
}

Note the extra zero on shadow distance (they set it pretty darn low to disable it)

Note there is a performance impact, but it does seem to work on my hardware.  The issue is certainly odd.

Edited July 27, 2020 by R-T-B

[Al2Me6]

20 minutes ago, R-T-B said:

  It is odd I have never witnessed it with scatterer installed.  That's what leads me towards shadows.

I actually have. 1.8.1, JNSQ, the entire suite of graphics mods (Scatterer, EVE, TUFX, etc.).

Spoiler

 

[Hpl]

Im pretty sure this is due to the terrain shader, as ohiobob pointed out

[Hohmannson]

1 hour ago, R-T-B said:

Note the extra zero on shadow distance

Noted, I was aware of the patch. Not helped, sadly. And i don`t catch that bug on Kerbin, like in case above, in no configuration. A very interesting bug indeed.

[Vabien]

Very strange bug. I suspect that the terrain shadows are broken for the PQS system (how terrain renders up close). What exactly causes the issue is a mystery to me, but I suspect either there's an issue with the shading system, or the PQS mod system (how you make better close up detail without manual work) has an issue. I've seen it before in beyond home's ash moon, and I've also seen the pattern that appears over it. If that photo is of JNSQ and not BH, that could imply something to do with that texture is screwing with it.

In any case, it definitely has SOMETHING to do with PQS, because when rendering terrain, more geometry is added to closer terrain, leading to smaller and more numerous squares. Scatterer probably doesn't fix it because the issue is on the PQS side, perhaps some bad normal/bump mapping, or maybe bad UV unwrapping (how textures are mapped on to geometry).

Anyway gtg, theres a tornado warning in the Northeast US. God knows how that works.

[Vabien]

Looking at the photos closer, it appears there might be shadows facing the wrong way. If anyone can provide evidence of shadows facing away from the sun, that would be great

[R-T-B]

Makes me wonder if it's GPU-specific then (I use AMD GPU, but usually, we have the bugs, not vice versa).  Either way, odd, and it doesn't help that I as a dev can't reproduce of course.  It's a very real bug I am sure though.

[OhioBob]

18 minutes ago, R-T-B said:

Makes me wonder if it's GPU-specific then (I use AMD GPU, but usually, we have the bugs, not vice versa).  Either way, odd, and it doesn't help that I as a dev can't reproduce of course.  It's a very real bug I am sure though.

I get the bug all the time.  It's not every planet, however.  When it occurs, the only way I've been able to get rid of it is to close KSP and restart.  And that's usually just a temporary fix.