[1.8.1 - 1.9.1] Kopernicus Continued

[crazyduck]

6 minutes ago, Thomas P. said:

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.

I think the way with adding 4 new nodes would be the better solution, not everyone who play KSP has a powerful computer to play with max settings so doing it with the current way it would make the game for many people horrible to play or force them to stay with old kopernicus version and old KSP version or stop using planet packs and Kopernicus.

 

Dont get me wrong i like Kopernicus but forcing Max settings on people sounds more like work around a problem and not solve it or would adding this 4 nodes be some sort of months of work to do?

 

[Thomas P.]

4 minutes ago, crazyduck said:

[...] or would adding this 4 nodes be some sort of months of work to do?

It would be, for all the planet authors who would suddenly have to write and balance four material configs instead of one, to prevent their stuff from breaking.

And yes, not everyone can run the ultra shader. But nothing stops you from writing a Kopernicus config that replaces the ultra quality materials with their lower quality equivalents from earlier versions.

[crazyduck]

11 minutes ago, Thomas P. said:

It would be, for all the planet authors who would suddenly have to write and balance four material configs instead of one, to prevent their stuff from breaking.

And yes, not everyone can run the ultra shader. But nothing stops you from writing a Kopernicus config that replaces the ultra quality materials with their lower quality equivalents from earlier versions.

So you mean people could write own configs for the Planet packs to replace the Materials with lower quality variants?

But woudl that not also cause the same problem as you said before?

The thing i don´t get is, if i install planet pack XYZ modify the config so it use lower quality Materials, why whould that be no problem but setting the Shader to lower qualtiy would be a problem? Or did i miss something?

For me that sounded like

Quality setting not on Max  = Issues wiht Planet Packs

modify config for Planet pack to use lower quality materials = no issues.

 

And as i said before i have it running with spectra mod, to boldy go, scatterer and eve and i can play around with the settings as much as i want i can see no bugs.

 

Edited July 21, 2020 by crazyduck

[Thomas P.]

25 minutes ago, crazyduck said:

Quality setting not on Max  = Issues wiht Planet Packs

modify config for Planet pack to use lower quality materials = no issues.

The issue that is prevented by forcing the shader quality is editing an already existing Material. You rely on values on the template, which can change at random without the forced quality setting. You as the planet author have no control over it, and no way to detect it with just a config.

Changing the shader requires you to provide the entire material config yourself. You dont rely on the material that is copied from the template, so you dont care if it changes. The only issues you can get are mod integration issues (when a mod already edits the material and you overwrite that). But because it happens through a config, mods could detect it, and adapt to it.

Both are different things, so one is not a factor for the decision to force the shader quality, while the other one is.

[crazyduck]

8 minutes ago, Thomas P. said:

The issue that is prevented by forcing the shader quality is editing an already existing Material. You rely on values on the template, which can change at random without the forced quality setting. You as the planet author have no control over it, and no way to detect it with just a config.

Changing the shader requires you to provide the entire material config yourself. You dont rely on the material that is copied from the template, so you dont care if it changes. The only issues you can get are mod integration issues (when a mod already edits the material and you overwrite that). But because it happens through a config, mods could detect it, and adapt to it.

Both are different things, so one is not a factor for the decision to force the shader quality, while the other one is.

Ok thats something i understand, but was it different in 1.8 before Kopernicus added this forced setting?  i mean before had the Planet Autor control over it or what did change in KSP that in 1.8 and before it was not a problem and after 1.8 it become a  problem.

I don´t try to annoy you i only try to understand what had changed so kopernicus changed this one option.

And why would it as example not be a solution to not lock the setting but add a simple warning dialog something like

"changing this Value can cause issues with Planet Packs"

this would still allow people to reduce the setting and run the game without lags and at same time warn that it can cause issues.

 

 

[Entropian]

Hi,

I'm trying to run RSS version 16.4 with Kopernicus version 1.9.1-5 on KSP 1.9.1.  When the main loading is complete, the "secondary" loading (after the main screen changes) seems to go on indefinitely.  I don't know if this is an RSS issue or a Kopernicus issue though.  I know that RSS is supposed to run on 1.8.1, but I wanted to check if it would run on 1.9.1 and see what issues would come up.

Log: https://www.dropbox.com/s/s4xtehzmbzldrjb/Player.log?dl=0

I've installed all the dependencies as well.

Thanks.

[Pehvbot]

2 hours ago, Entropian said:

Hi,

I'm trying to run RSS version 16.4 with Kopernicus version 1.9.1-5 on KSP 1.9.1.  When the main loading is complete, the "secondary" loading (after the main screen changes) seems to go on indefinitely.  I don't know if this is an RSS issue or a Kopernicus issue though.  I know that RSS is supposed to run on 1.8.1, but I wanted to check if it would run on 1.9.1 and see what issues would come up.

Log: https://www.dropbox.com/s/s4xtehzmbzldrjb/Player.log?dl=0

I've installed all the dependencies as well.

Thanks.

I'm pretty sure you need the latest version (18.0) of RSS.  There were changes to the textures in recent updates.

https://github.com/KSP-RO/RealSolarSystem/releases/tag/v18.0

[Entropian]

8 hours ago, Pehvbot said:

I'm pretty sure you need the latest version (18.0) of RSS.  There were changes to the textures in recent updates.

Thanks.  Seems like the link in the OP was wrong...

 

[Hohmannson]

@R-T-B I saw the PR with russian localization and recommend some fixes.

#Kopernicus_UI_TrackingBody = Отслеживаемое тело

#Kopernicus_UI_AutoTracking = Авто

#Kopernicus_UI_AutoTrackingBodyName = <<1>> (Авто)

#Kopernicus_UI_SelectBody = Выбрать отслеживаемое тело

#Kopernicus_UI_SelectBody_Msg = Пожалуйста выберите тело для отслеживания этой панелью. // Пожалуйста, выберите тело для отслеживания этой панелью

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

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

#Kopernicus_UI_PanelBlocked = Заблокирована <<1>> // Затенена <<1>> or Заслонена <<1>>

#Kopernicus_UI_DirectSunlight = Прямой солнечный свет

#Kopernicus_UI_Underwater = Под водой

Edited July 22, 2020 by Hohmannson

[Thomas P.]

23 hours ago, crazyduck said:

Ok thats something i understand, but was it different in 1.8 before Kopernicus added this forced setting?  i mean before had the Planet Autor control over it or what did change in KSP that in 1.8 and before it was not a problem and after 1.8 it become a  problem.

I don´t try to annoy you i only try to understand what had changed so kopernicus changed this one option.

And why would it as example not be a solution to not lock the setting but add a simple warning dialog something like

"changing this Value can cause issues with Planet Packs"

this would still allow people to reduce the setting and run the game without lags and at same time warn that it can cause issues.

1.8 had the same behaviour, but I tried to do a lot of it within Kopernicus, without changing the settings value. But that code was full of bugs, and since the behaviour was the same anyways, I changed it in preparation for 1.9. This included adding the warning message.

If you only display a warning, instead of locking the value, you don't gain much, if not nothing at all. People just ignore warnings. As a maintainer, you want to prevent people from relying on different behaviours outside of their or your control. For example one planet pack that is based on the values from "Medium", and one that is based on "Ultra". Supporting that is a complete mess. The only reliably way is to expose the same behaviour to everyone, no matter the game settings. And in this case it means you choose one quality level for them. Since the people who can run the ultra shader probably vastly outnumbers those who can't, the choice was easy.

[crazyduck]

2 hours ago, Thomas P. said:

1.8 had the same behaviour, but I tried to do a lot of it within Kopernicus, without changing the settings value. But that code was full of bugs, and since the behaviour was the same anyways, I changed it in preparation for 1.9. This included adding the warning message.

If you only display a warning, instead of locking the value, you don't gain much, if not nothing at all. People just ignore warnings. As a maintainer, you want to prevent people from relying on different behaviours outside of their or your control. For example one planet pack that is based on the values from "Medium", and one that is based on "Ultra". Supporting that is a complete mess. The only reliably way is to expose the same behaviour to everyone, no matter the game settings. And in this case it means you choose one quality level for them. Since the people who can run the ultra shader probably vastly outnumbers those who can't, the choice was easy.

Hmm why would it be such a problem to allow 2 shader settings and let the planet pack creators decide if they support both shaders or only 1 setting? I think Planet PAck Authors would offer Packs for different Shader Settings if people ask for such Packs as long as Kopernicus again support to change Settings.

And i do not think its outside of User control its the User who will decide to change the Setting or not so the User is in Control and yes some People do not read warnigns but a warning popping up the second you try to change shader settings i think most people would read.

So reverting the Commit about forcing highest Terrain and Ocean Quality would be enough to revert the changes with forced Shaders or are there other changes in code hidden somehwere in other commits that must be changed too?

If reverting this 2 commits and removing the TerrainQualitySetter.cs is enough i only see it works fine for me , if not would be great if you could tell me the other commits that needs to be reverted.

 

Edited July 22, 2020 by crazyduck

[Jognt]

8 hours ago, crazyduck said:

Hmm why would it be such a problem to allow 2 shader settings and let the planet pack creators decide if they support both shaders or only 1 setting? I think Planet PAck Authors would offer Packs for different Shader Settings if people ask for such Packs as long as Kopernicus again support to change Settings.

And i do not think its outside of User control its the User who will decide to change the Setting or not so the User is in Control and yes some People do not read warnigns but a warning popping up the second you try to change shader settings i think most people would read.

So reverting the Commit about forcing highest Terrain and Ocean Quality would be enough to revert the changes with forced Shaders or are there other changes in code hidden somehwere in other commits that must be changed too?

If reverting this 2 commits and removing the TerrainQualitySetter.cs is enough i only see it works fine for me , if not would be great if you could tell me the other commits that needs to be reverted.

 

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.  

Edited July 23, 2020 by Jognt

[R-T-B]

On 7/21/2020 at 1:49 PM, Thomas P. said:

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.

That was my understanding then, and it seems correct.  Thanks for backing me up with a "just because it looks right, doesn't mean it is right" confirmation.

To prevent further burden to planet pack authors, I won't be implementing a work around for this.  At least not now.

For right now though, there is a new release.  It's actually that old bugfix that was pulled for solar flux calculations (important to multistar systems and proper solar tracking/power output) but this time, it actually works and has been well bugtested over several days.

Please feel free to download at the OP's link, or here:

EDIT:  Release pulled due to build environment issues.  Expect it tomorrow or the next day.

On 7/22/2020 at 8:58 AM, Hohmannson said:

@R-T-B I saw the PR with russian localization and recommend some fixes.

#Kopernicus_UI_TrackingBody = Отслеживаемое тело

#Kopernicus_UI_AutoTracking = Авто

#Kopernicus_UI_AutoTrackingBodyName = <<1>> (Авто)

#Kopernicus_UI_SelectBody = Выбрать отслеживаемое тело

#Kopernicus_UI_SelectBody_Msg = Пожалуйста выберите тело для отслеживания этой панелью. // Пожалуйста, выберите тело для отслеживания этой панелью

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

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

#Kopernicus_UI_PanelBlocked = Заблокирована <<1>> // Затенена <<1>> or Заслонена <<1>>

#Kopernicus_UI_DirectSunlight = Прямой солнечный свет

#Kopernicus_UI_Underwater = Под водой

My uncle who wrote manuals for a living (and so speaks a ton of languages, but is rather more a jack of all trades, master of none), said it was ok, so sadly, it's already been merged.

Was anything glaringly wrong or was it just minor stuff?  I may make corrections in next release.

Edited July 23, 2020 by R-T-B

[rukhafi]

As a native speaker, I can confirm that it's minor stuff, but the corrections will make the text more literary

[StoneWolfPC]

Never mind, it's another mod:  Still testing:  I'm in the middle of moving an install to test one particular thing but I'm tossing this out preemptively in case it's been noticed.  Has anyone tested the science equipment from the DLC?  The parts that take the container, like the go-eb, experiment controller, etc.?  Because I was playing through my 1.9.1 career and realized you can't place them anywhere.  It may be a different mod, but I am going to double check that an report back.  I'm sorry if this ends up being a dud of a thought.  lol.  Everything else, including the heat seems in my opinion to be perfect btw.  I'll run a couple more tests on that today and with any luck have enough data to give a proper statement to it.

Edited July 23, 2020 by StoneWolfPC
I oopsed an assumption

[Hohmannson]

4 hours ago, R-T-B said:

minor stuff

Minor stuff. "Заблокирована" means more "locked" than "blocked", my suggestion was to use words meaning "shadowed" or "obstructed". And a comma is needed after "пожалуйста", but its absense doesn`t make things less understandable, so it`s OK.

[OhioBob]

4 hours ago, R-T-B said:

For right now though, there is a new release.  It's actually that old bugfix that was pulled for solar flux calculations (important to multistar systems and proper solar tracking/power output) but this time, it actually works and has been well bugtested over several days.

Please feel free to download at the OP's link, or here:

https://github.com/prestja/Kopernicus/releases/tag/1.9.1-6

Something is very wrong.  My planet pack (GEP) won't load with 1.9.1-6.  Loads fine with 1.9.1-5.  Apparently some issue with the gas giant planet Sirona...

Spoiler

Kopernicus.log
--------------
[LOG 11:35:33]: [Kopernicus]: Configuration.Loader: Failed to load Body: Sirona: Object reference not set to an instance of an object

KSP.log
-------
[EXC 11:35:33.137] Exception: Failed to load Body: Sirona

    Kopernicus.Configuration.Loader.Kopernicus.ConfigParser.Interfaces.IParserEventSubscriber.PostApply (ConfigNode node) (at <3e955723fbbf4f499595052b045d8d0d>:0)
    Kopernicus.ConfigParser.Parser.LoadObjectFromConfigurationNode (System.Object o, ConfigNode node, System.String configName, System.Boolean getChildren) (at <395892e8bc6a43f7a7ef20a5d37d4d79>:0)
    Kopernicus.ConfigParser.Parser.CreateObjectFromConfigNode[T] (ConfigNode node, System.String configName, System.Boolean getChildren) (at <395892e8bc6a43f7a7ef20a5d37d4d79>:0)
    Kopernicus.Injector.Awake () (at <3e955723fbbf4f499595052b045d8d0d>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:LogException(Exception)
    Kopernicus.Injector:Awake()
    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)

 

Edited July 23, 2020 by OhioBob

[R-T-B]

19 minutes ago, OhioBob said:

Something is very wrong.  My planet pack (GEP) won't load with 1.9.1-6.  Loads fine with 1.9.1-5.  Apparently some issue with the gas giant planet Sirona...

  Reveal hidden contents

Kopernicus.log

[LOG 11:35:33]: [Kopernicus]: Configuration.Loader: Failed to load Body: Sirona: Object reference not set to an instance of an object

KSP.log

[EXC 11:35:33.137] Exception: Failed to load Body: Sirona

    Kopernicus.Configuration.Loader.Kopernicus.ConfigParser.Interfaces.IParserEventSubscriber.PostApply (ConfigNode node) (at <3e955723fbbf4f499595052b045d8d0d>:0)
    Kopernicus.ConfigParser.Parser.LoadObjectFromConfigurationNode (System.Object o, ConfigNode node, System.String configName, System.Boolean getChildren) (at <395892e8bc6a43f7a7ef20a5d37d4d79>:0)
    Kopernicus.ConfigParser.Parser.CreateObjectFromConfigNode[T] (ConfigNode node, System.String configName, System.Boolean getChildren) (at <395892e8bc6a43f7a7ef20a5d37d4d79>:0)
    Kopernicus.Injector.Awake () (at <3e955723fbbf4f499595052b045d8d0d>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:LogException(Exception)
    Kopernicus.Injector:Awake()
    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)

 

I heard reports of this last release but assumed I had just botched the bundling process due to lack of sleep or something...

Does it load ok with my bleeding edge?  That'd be a good place to start comparing and see what's different (other than particles, which I know aren't causing it) if so.

EDIT:  Nevermind, I am 99% certain I know what's going on here.  I will reupload in a moment.  If you are having issues, just wait a few minutes and redownload.  It's my build environment, not the source.  Easy fix.

Edited July 23, 2020 by R-T-B

[OhioBob]

10 minutes ago, R-T-B said:

Does it load ok with my bleeding edge?

It loads using release 4.

[R-T-B]

2 minutes ago, OhioBob said:

It loads using release 4.

Good.

Try redownloading now (same releaase link), I think I fixed the bug in our build system but need a test.  Is there a link to your planet pack i can get btw, for testing to avoid things like this.

Edited July 23, 2020 by R-T-B

[R-T-B]

I actually found a few residual files (from 1.10 builds no less) in my local tree that were causing havoc.  If your file for release 6 you downloaded was downloaded earlier than this post (approx 9:20am PST), please redownload the release 6.   It had a few things broken, as noted above.

EDIT:  Release pulled due to build environment issues.  Expect it tomorrow or the next day.

Now the work for me is to find out how that happened, friggin ghosts in the machine I swear...

Edited July 23, 2020 by R-T-B

[OhioBob]

16 minutes ago, R-T-B said:

If your file for release 6 you downloaded was downloaded earlier than this post (approx 9:20am PST), please redownload the release 6.   It had a few things broken, as noted above.

https://github.com/prestja/Kopernicus/releases/tag/1.9.1-6

GEP still won't load. 

[R-T-B]

On 7/23/2020 at 9:40 AM, OhioBob said:

GEP still won't load. 

That's...  really weird.  Especially considering this release is using the same code as my bleeding edge in the section the error occurs, and you told me it loads fine on bleeding edge.

I will fix this, but I need more time.  I'd advise you to stay a release back for now, as you are dealing with some new bug seperate from my build bugs (not that cleaning my environment was bad, needed to happen anyways).

I will make a bug for you and get to work on it.

If you could PM me SIrona's config, that would probably help.

EDIT:  Wow that's a pretty plain gas giant as far as config...  um, I'm going to pull this build.  Sorry guys, but my build environment or something, is all out of whack and we need to determine what before making another release.

EDIT AGAIN:  WE FIXED IT!

Please redownload if you downloaded this morning before 10:30ish PST.  No more redownloading though, I promise.  This one works.  Appologies, I'll keep my build environment less messy in the future.  Special Shoutout to @OhioBob for debugging through starvation at lunchtime...

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

Edited August 15, 2020 by R-T-B

[MashAndBangers]

1 hour ago, R-T-B said:

EDIT AGAIN:  WE FIXED IT!

"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"

Edited July 23, 2020 by MashAndBangers

[R-T-B]

12 minutes 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"

Pretty much.  This is why it's important to "clean your room" as a coder.  Basically, not updating a comment led to all of this.  I must admit it really could've been avoided, and it was my fault.

The bottom line is though, the one that's up now, works, and this won't happen again, because I have a good list of testers now to run it by first...  (thanks guinea pigs!)

Serious thanks to @OhioBob too, guy almost sacrificed lunch-break to get this fixed.  The horror!

Edited July 23, 2020 by R-T-B