[1.8.1 - 1.9.1] Kopernicus Continued

[Nicky21]

I want to thank you guys for picking up the maintenance ofthis mod. It makes ksp interesting even after you have a few thousands of hours in it.

 

Thank you !

[R-T-B]

1 hour ago, Thomas P. said:

I would also warn you from trying to enable the new shader only for Jool.

The plan, longterm anyways, was to make the new shader available but opt-in with some sort of explicit parameter.  Personally I am still of the opinion that is still the best way forward.

Quote

The example for a gas giant that doesn't use a template is old and outdated.

Ah, that would explain a lot.  Still, some planet packs were identified that do no specify a normal map and do not use the Joolian Template.  While this may be incorrect behavior, I believe having a fallback normal map that at least provides appropriate shadows is not a bad thing going forward.  I won't baby them more than that, though.

1 hour ago, Thomas P. said:

What I found is a script called MaterialBasedOnGraphicsSetting. I guess that the new shader is only used if the shader quality is set to "Ultra", and that that script is responsibly for applying it. Maybe "High" too. But everything else will use to the old 1.9 shader, which is applied by default. This would explain a lot of things:

Oh, so that code tidbit came from you!  Sorry, I thought Sigma wrote it.  I got my attributions wrong.

Long story short, it didn't work.  That script you found, purging it, removing it, it all does nothing and they all still appear to have the same new Jool shader.  It's odd.  I would've thought the same.  Also, I tried a technique in the modders notes of adding a instance of GasGiantMaterialControls and telling it to shutdown via .enabled = false.  Interestingly, it's .enabled property did nothing as well.

Long story short, I'm sure there IS a better way, I've just yet to find it. I'm with you that making Joolian-templated bodies non-template is more of a work around than it should be for retaining retro-compatability.  I've just yet to find that magic better way forward that works.  And yes, the eventual goal is to not do that.

I appreciate your input (and clarifications on your stance).  You are a god amongst men here, programming wise, and I'm just trying to keep pace.

  

1 hour ago, Thomas P. said:

I was just trying to give a more in-depth explanation to the issue. I didn't knew that you used my old example for a gas giant without a template, so I didn't know where the issue on 1.8 and 1.9 came from. So I just assumed it was because of your change, because on 1.10 it actually does have that effect (with every body). I wasn't trying to attack you or anything like that, sorry if it came over that way. I just want to try to help where I can.

PS:  This is as my friends would tell me "probably a personal issue."  Many times when I communicate with Europeans I make this mistake, don't know why, but you guys come across as somewhat... clinical and cold I guess on the internet at times to me?  As I said I'm sure it's my fault, lol.  I do appreciate you clearing the air.

It could be that I am just too silly for reason and anyone else strikes me as being "too serious."
 

2 hours ago, dzin said:

 

Hi,

should I use Kopernicus 1.9.1-5  from prestja/Gihub or KopernicusBE_191_Release1 from R-T-B/github for KSP1.9.1?
What differences?


P.S. THANKS for both of You for maitining this

The bleeding edge branch has more features but is less tested.  In 1.9.1 it has support for particles, which has been missing since 1.8 and may provide extra visuals in older planet packs.

Otherwise, I'd say go with Prestja's build because it is more tested.

Edited July 19, 2020 by R-T-B

[Iodyne]

On 7/17/2020 at 6:02 PM, hemeac said:

@R-T-B, Not sure if this is related, but @Iodyne noticed that 1-P Geito in the Minor Planets Expansion (based off the Gilly template) also has the lighting off by 90 degrees (link: Minor Planets Expansion).  They've linked to their log file.  I can confirm I see it both in the 1.9.1-4 release as well as your 1.10.0 Prelease 4 which is shown below.

 

On 7/17/2020 at 7:35 PM, Iodyne said:

I think it's important to note @hemeac I that the lighting issue is only for the in the map and tracking view but not in flight (unless zoomed out very far). So something to do with the scaled-space representation. I didn't see anything similar for any of the other bodies in OPM & Minor Planets Expansion (MPE).

On 7/17/2020 at 9:05 PM, R-T-B said:

Yep it's scaled space only.  Weird.

Was typo in the body's config. MPE side clearly

[Aerodinamic Potatoe]

guys,please help me,I installed kopernicus and OPM on the version 1.4.5 (kopernicus 1.4.5-3) and this bug happens,i dont know what to do, I do not want to uninstall kopernicus and I need a solution otherwise I will be forced to delete kopernicus, anyway,s...HELP 
the problem is that the ground looks weird

https://imgur.com/5IPgnxK
https://imgur.com/pAWg13k

[OhioBob]

12 minutes ago, Xander el interplanetario said:

I do not want to uninstall kopernicus

I wouldn't uninstall Kopernicus.  I'd uninstall everything else.  If that fixes it, reinstall the other mods incrementally until you figure out which one is causing the problem.

[cukkoo]

Why it require Ultra shader

[The Tenth Avenger]

7 hours ago, cukkoo said:

Why it require Ultra shader

Yes! When I try to lower the shader setting of the game Kopernicus doesn't let me and says it needs shader on ultra setting or something like that. My pc is pretty garbage so maybe lowering that would help raise fps when when landed on a body with shaders. Is it really necessary for Kp. to keep that setting that way?

[R-T-B]

1 hour ago, The Tenth Avenger said:

Yes! When I try to lower the shader setting of the game Kopernicus doesn't let me and says it needs shader on ultra setting or something like that. My pc is pretty garbage so maybe lowering that would help raise fps when when landed on a body with shaders. Is it really necessary for Kp. to keep that setting that way?

For ease of maintanence, that decision was made by the old Kopernicus team in their source.  As of now, given the workload in front of us, I have no plan to reverse it, sorry.

You might try reverting to 1.8 if performance is important.  Not much besides graphics is really missing, just the comets and stuff, but you still get asteroids and "Moar boasters' etc.

Edited July 20, 2020 by R-T-B

[R-T-B]

19 hours ago, Iodyne said:

Was typo in the body's config. MPE side clearly

Technically all the packs that were having issues were due to declaring the gas giants as not templates of Jool, which is really a mistake.  I've worked around it for now, but as I said, I do not plan on babying it anymore than I already have.  Planet pack authors need to do their packs right, at a certain point.

[Hpl]

MPE doesnt have gas giants though

[ra4nd0m]

Actually, MPE is currently quite broken on 1.9.1. All of the non-spherical bodies suffer from really awful terrain glitch where it appears like terrain is moving with your ship. It also causes svere fps drops at least for me.

[R-T-B]

On 7/20/2020 at 11:31 AM, Hpl said:

MPE doesnt have gas giants though

It could still happen if they just fail to specify a normal map.  It was just more common with gas giants because I guess people did not assume you'd need one.

Maybe we are talking a different bug and I got my issues crossed too, lol.

 

Anyhow, new stable release everyone.  This is a small bugfix release for a heat calculation issue in multistar planet packs.  It won't even affect people with only one star, but it's probably advisable to download it if you have a multistar pack so your atmospheric temps are right:

https://github.com/prestja/Kopernicus/releases

This release is considered a sort of "release candidate" to CKAN.  I hope it can be the one that finally gets us there.

Edited August 15, 2020 by R-T-B

[OHara]

51 minutes ago, R-T-B said:

This is a small bugfix release for a heat calculation issue in multistar planet packs. 

Something has gone wrong in the release process.  The source code is back in the state where no atmosphere-heating star is ever found, and some change (that I don't see in the source) gives a null reference when it tries to load 'Sirona' from the Grannus Expansion Pack.

It looks like neither the github code nor the released dll matches what you tested, if you saw the multistar heat fix.  Slow down; it will be fine.

[R-T-B]

 

1 hour ago, OHara said:

Something has gone wrong in the release process.  The source code is back in the state where no atmosphere-heating star is ever found, and some change (that I don't see in the source) gives a null reference when it tries to load 'Sirona' from the Grannus Expansion Pack.

It looks like neither the github code nor the released dll matches what you tested, if you saw the multistar heat fix.  Slow down; it will be fine.

Yeah, I'm waiting a moment so I have time to think.  Work being at your back never helps a release, so when I get home and have actual freedom, I will fix the issue properly.

I'd advise waiting to download a new release until then.  Also, please revert if you did download it as the math is all wrong.  Apologies all.  Should be home in a few hours.  I am pulling that last release in the meantime, as it's only bad changes.

Quote

Slow down; it will be fine.

More like "don't do things at work, it's a bad idea" but I get you.

Edited July 20, 2020 by R-T-B

[R-T-B]

So, I've made the decision to hold off on stable branch having this "release 5" fix until we can test it first, with more than just one person.

If you wish to test this new fix, see my bleeding edge branch.  It just dropped there.  Release 3 (or higher, if there are bugs) is what you are after.

For the record, short of really extreme scenarios in multistar packs, I don't see this fix as having a major impact on the majority of Kopernicus users, and not really any impact on gameplay (only statistical data) in most situations.  You should be fine using release 4 here if you don't want to play Guinea pig.

Edited July 21, 2020 by R-T-B

[crazyduck]

So i recompiled Kopernicus and removed forcing Ultra Settings , i do not see anything different , no bugs as far as i can tell.

So can anyone explain me why forcing Ultra Settings is needed?

Not a Problem on my computer but i did read at R-T-B´s Git from a user having issues with Ultra Settings and a response that its easier with only ultra settings and somethign about Texture Pack authors.

So to be honest, i think its a bad idea to force something like Quality Settings to Users and its even more a bad idea i think if its such a Mod like Kopernicus .

 

So @R-T-B would be really great if you could explain me why you think forcing ultra settings is needed m cause as i said removing it does ot cause any bugs for me.

[linuxgurugamer]

49 minutes ago, crazyduck said:

So i recompiled Kopernicus and removed forcing Ultra Settings , i do not see anything different , no bugs as far as i can tell.

How much testing did you do? 

• Did you go to every planet with a ship? 
• Did you land on all of them (that are landable)? 
• Did you test near and far distances? 
• Did you test in MapView, & Tracking station?

 

[crazyduck]

7 minutes ago, linuxgurugamer said:

How much testing did you do? 

• Did you go to every planet with a ship? 
• Did you land on all of them (that are landable)? 
• Did you test near and far distances? 
• Did you test in MapView, & Tracking station?

 

 

I teleportet with Ship to each planet orbit and Surface and did not see any issues, i set quality to medium.

Did see planets from far and near from orbit

ok Tracking Station i did not test but will do now.

 

[R-T-B]

1 hour ago, crazyduck said:

Not a Problem on my computer but i did read at R-T-B´s Git from a user having issues with Ultra Settings and a response that its easier with only ultra settings and somethign about Texture Pack authors.

I mean, that’s just how I had it explained to me.  I am learning here too and could very well be wrong.

The issue I see is, if you download a texture pack using the new atlas shader going forward, and are set to high or low or something, it really won’t render right I think.  I guess I could remove the forced thing and replace it with just a warning about this though, if there is user demand, and since it seemingly works.

We would test at my bleeding edge branch, of course.

2 minutes ago, crazyduck said:

 

I teleportet with Ship to each planet orbit and Surface and did not see any issues, i set quality to medium.

Did see planets from far and near from orbit

ok Tracking Station i did not test but will do now.

 

I would appreciate that.  If you would open a PR upon confirmation of this working, I may accept it in my bleeding edge branch.  Whether or not it ever makes it to stable is up in the air though, pending more tests.

Understand, I did not enforce this decision to be mean or anything.  I just assume Sigma and Thomas probably had their reasons, but maybe we can at least let bleeding edge users skirt this a bit.

[crazyduck]

4 minutes ago, R-T-B said:

I mean, that’s just how I had it explained to me.  I am learning here too and could very well be wrong.

The issue I see is, if you download a texture pack using the new atlas shader going forward, and are set to high or low or something, it really won’t render right I think.  I guess I could remove the forced thing and replace it with just a warning about this though, if there is user demand, and since it seemingly works.

We would test at my bleeding edge branch, of course.

Ok for me i now testet it with Tracking Station too and no Problems for me. All Planets work no Texture issues for me .

I use the modified Kopernicus, with Spectra and EVE (from your git) and to boldly go for universe creation.

Sure will do, will test it a little bit more today and if i do not find any bugs will do the PR.

 

Edited July 21, 2020 by crazyduck

[R-T-B]

2 minutes ago, crazyduck said:

Ok for me i now testet it with Tracking Station too and no Problems for me. All Planets work no Texture issues for me .

I use the modified Kopernicus, with Spectra and EVE (from your git) and to boldly go for universe creation.

 

 

I appreciate you going the extra mile to compile and test this.

Do you have a git repo I can check out myself just to be sure results match?
Again, no promises yet.  But I never turn away hard data like this.

Edited July 21, 2020 by R-T-B

[crazyduck]

Just now, R-T-B said:

I appreciate you going the extra mile to compile and test this.

Do you have a git repo I can check out myself just to be sure results match?

sure give me a moment will upload it to git.

[crazyduck]

19 minutes ago, R-T-B said:

I appreciate you going the extra mile to compile and test this.

Do you have a git repo I can check out myself just to be sure results match?
Again, no promises yet.  But I never turn away hard data like this.

Link for Gitlab

https://gitlab.com/crazyduck33/ksp-kopernicustest

[R-T-B]

2 hours ago, crazyduck said:

Link for Gitlab

https://gitlab.com/crazyduck33/ksp-kopernicustest

Ok, I will test it out later today, thanks.

[Thomas P.]

7 hours ago, crazyduck said:

So can anyone explain me why forcing Ultra Settings is needed?

Most Kopernicus configs are overlays over a stock body template. You want them to consistently produce the same result on every installation, no matter the game settings.

With the new shader quality setting, it is impossible for the planet author to know, which material their changes will be applied to. Since the values are different, one config might work fine on one installation, and fail horribly on another one, just because the shader quality is set to a different value.

Thats why Kopernicus forces the highest shader quality (and thus the ultra shader on Kerbin). It's the only sane way to solve this problem. There is another option, but it requires removing the current Material node, adding four new nodes for the different shader qualities, and then forcing every planet author to implement this because it would break every config, on every install.