[1.12.x] Kopernicus Stable branch (Last Updated August 29th, 2024)

[R-T-B]

37 minutes ago, OrbitalManeuvers said:

With scatterer having a lot of "shadow" settings too, is there any chance you could give some sort of hint what belongs to Kopernicus and what belongs to scatterer? Do both of these mods draw their own custom shadows, or are they both setting global Unity options? 

 

Scatterer shadows always take precedence.  Kopernicus on it's own really just tries to emulate stock look, which for various reasons, it can't do perfectly (Stock actually dynamically calculates the shadow settings, we set a static per scene value for various reasons that are both boring and very very hardcoded at this point).

Edited October 30, 2021 by R-T-B

[OrbitalManeuvers]

52 minutes ago, R-T-B said:

Scatterer shadows always take precedence.

Sorry to be a pain. Can you say something about this mechanism? Is this code detecting that scatterer is installed and then skipping other code? I'm curious because these settings that KSP has, like AA, that are singular and global, are addressed by multiple mods, and figuring out who is king of the hill can be challenging. E.g. TUFX, scatterer and KSP all have an AA setting, and if I'm not mistaken, Unity has one value to set. This begs the question which mod is the last one to make the Unity call to set this value, and what does that do to the other mods who thought the value had been set to something different? 

Am I thinking about this all wrong, or does Kopernicus have to actively detect and yield to scatterer to accomplish the end result of scatterer settings taking preference? And conversely, if Kopernicus didn't actively detect scatterer, they could be stepping on each other for some Unity settings?

[R-T-B]

20 hours ago, OrbitalManeuvers said:

Sorry to be a pain. Can you say something about this mechanism? Is this code detecting that scatterer is installed and then skipping other code

No detection happens.  They both run, in truth.  Scatterer simply adjusts later in the scene, so its settings take precedence by virtue of l being the "last thing that happened."

Since we are adjusting the same base unity setting, the last to load wins.

Edited October 31, 2021 by R-T-B

[dave1904]

On 10/30/2021 at 4:04 PM, R-T-B said:

3.) Before 1.12.0, the mission creator module in Making History is somehow, amazingly, is bugged in such a way as to make landing at bodies more distant than say, Stock Eeloo, impossible, due to sinking landing gear and lethal-to-kerbalkind terrain. The general work around for this is to a.) stay within the standard solar system distance, or b.) install another mod: "MakingLessHistory."

Am I reading this wrong or did you formulate this wrong? Even after 1.12.0 this is still the case. I'm playing on 1.12.2 and MakingLessHistory still fixed the lethal terrain. Has makingless history always been a sollution to this problem? I cannot believe I only saw the fix to this problem today......... 

Edited November 3, 2021 by dave1904

[R-T-B]

1 hour ago, dave1904 said:

Am I reading this wrong or did you formulate this wrong? Even after 1.12.0 this is still the case. I'm playing on 1.12.2 and MakingLessHistory still fixed the lethal terrain. Has makingless history always been a sollution to this problem? I cannot believe I only saw the fix to this problem today......... 

I forgot to edit the text there.  Initially we assumed the new landing legs in 1.12.x fixed this issue, but upon further analysis, they only improve it's operating distance, do not fix it.

This is something we are looking into for an external fix with KSPCommunityFixes but for now the workaround listed works.  I will edit the text to our modern understanding of the problem.

MakingLessHistory also is not a complete fix, but it gives you exponentially more range to work with.  The exact origin of the problem and its confusing relationship to the mission creator remains elusive.

Edited November 3, 2021 by R-T-B

[Interplanet Janet]

Hi, I just had a quick question that may not have been asked before and may seem rather off-kilter.

How would you go about marking a Barycenter object? Does it need radius, description, or anything of the sort, or does it only allow for orbital information and nothing else? I ask because of a binary body that I'm making that I want to have a circumbinary ring, but also be an invisible body when viewed through the Tarsier Space Technology telescopes.

[Grimmas]

You can look at how Galaxies Unbound does it, they have quite a few binary systems with invisible barycenters.

[Interplanet Janet]

I noticed how it does it, but those barycenters are only around stars. These are binary minor bodies. I can't have the barycenter be so prohibitively large because then it would envelop these binary pairs completely and render them unlandable. But at tiny sizes (i.e. 500m radius), the spacecraft loses its lighting due to the invisible ScaledVersion (and/or the tiny size of the body), and ends up flickering terribly as well.

I don't know if this is a bug with the rendering engine or what, but I think that small invisible bodies should be able to not have a major lighting bug all the time.

[SpaceODY]

Would it ever be possible to allow for cubemap textures?

[Georgecosmos]

I am trying to install KSRSS on 1.12 and I keep receiving the message "Kopernicus was not able to load the custom planetary system" I have the latest Kopernicus but still doesn't work. Any suggestions?

[OhioBob]

48 minutes ago, Georgecosmos said:

I am trying to install KSRSS on 1.12 and I keep receiving the message "Kopernicus was not able to load the custom planetary system" I have the latest Kopernicus but still doesn't work. Any suggestions?

I suggest you go talk to the KSRSS people.  Kopernicus being unable to load a planet pack is not a Kopernicus problem, it's a planet pack problem.

[Georgecosmos]

6 minutes ago, OhioBob said:

I suggest you go talk to the KSRSS people.  Kopernicus being unable to load a planet pack is not a Kopernicus problem, it's a planet pack problem.

But it does this for every planet pack I have tried, JNSQ and RSS.

[Pehvbot]

17 minutes ago, Georgecosmos said:

But it does this for every planet pack I have tried, JNSQ and RSS.

If you are installing manually check to make sure the planet pack folders are in the right spot and for RSS and KSRSS that you also have the RSS textures. 

[OhioBob]

1 hour ago, Georgecosmos said:

But it does this for every planet pack I have tried, JNSQ and RSS.

Then it is most likely an installation error.  When installing Kopernicus, did you also install ModularFlightIntegrator and ModuleManager?  And as Pehvbot said, make sure you have all the required pieces of the planet pack installed, and installed correctly.  If any folder is out of place, it won't work.

A screenshot of your GameData folder might be helpful.
 

Edited November 13, 2021 by OhioBob

[Georgecosmos]

Don't worry it's solved now thanks for your help.

[Grond]

I'm having an issue where kerbals clip into the ground on Kopernicus planets. This isn't GU related, I'm just using a GU planet to showcase it. It happens on every planet added by Kopernicus

[Grimmas]

Are you using Parallax? This is a common issue with Parallax which adds extra visual details but does not (any longer) add  collision geometry for that detail.

[R-T-B]

12 hours ago, Grimmas said:

Are you using Parallax? This is a common issue with Parallax which adds extra visual details but does not (any longer) add  collision geometry for that detail.

It also happens on bodies more distant than say, a little past stock eeloo.  Workarounds are listed in the release notes.

[dave1904]

13 hours ago, R-T-B said:

It also happens on bodies more distant than say, a little past stock eeloo.  Workarounds are listed in the release notes.

Is it actually eeloo no matter how the system is scalled or at a fixed distance after eeloo in the stock kerbal size? I also was wondering if you happen to know if there is a fix/workaround for floating terrain scatters with rescaled systems? Reloading a quicksave works once the terrain is loaded but that is not ideal. 

Edited November 16, 2021 by dave1904

[R-T-B]

4 hours ago, dave1904 said:

Is it actually eeloo no matter how the system is scalled or at a fixed distance after eeloo in the stock kerbal size? I also was wondering if you happen to know if there is a fix/workaround for floating terrain scatters with rescaled systems? Reloading a quicksave works once the terrain is loaded but that is not ideal. 

I think it's actually a little farther, say like up to 2x the distance from the sun than eeloo is at stock scaling.

The best thing to do is just install MakingLessHistory if you experience it.

4 hours ago, dave1904 said:

I also was wondering if you happen to know if there is a fix/workaround for floating terrain scatters with rescaled systems? Reloading a quicksave works once the terrain is loaded but that is not ideal. 

Yes, there is a Kopernicus_config.cfg variable that controls detection/removal of the floating scatters...  I am at work and forget the exact name but it is the one with the word "Delta" in it. I think it needs to be set to 0 to work with 100% perfection but that does impact performance.  You may find it acceptable though.  Lower values = less floaties.

Edited November 16, 2021 by R-T-B

[Grond]

On 11/16/2021 at 5:14 AM, R-T-B said:

It also happens on bodies more distant than say, a little past stock eeloo.  Workarounds are listed in the release notes.

Yeah at first I thought it was this, but I talked to the GU dev and some other people and none of them experienced this bug before. Could it be a version thing? Maybe it only happens in certain game versions?

[dave1904]

13 hours ago, R-T-B said:

I think it's actually a little farther, say like up to 2x the distance from the sun than eeloo is at stock scaling.

The best thing to do is just install MakingLessHistory if you experience it.

Yes, there is a Kopernicus_config.cfg variable that controls detection/removal of the floating scatters...  I am at work and forget the exact name but it is the one with the word "Delta" in it. I think it needs to be set to 0 to work with 100% perfection but that does impact performance.  You may find it acceptable though.  Lower values = less floaties.

Cheers, once corsair send the 4 lga 1700 screws I can install my 12900K :p

[R-T-B]

12 hours ago, Grond said:

Yeah at first I thought it was this, but I talked to the GU dev and some other people and none of them experienced this bug before. Could it be a version thing? Maybe it only happens in certain game versions?

It's highly inconsistent with when and where it decides to present itself, but it does seem related somehow to distance.  I've never seen it on normal-distance bodies (like stock kerbal distances).

It's been a bug since past version 1.7.3 of KSP, AFAIK.

Edited November 17, 2021 by R-T-B

[Grond]

11 hours ago, R-T-B said:

It's highly inconsistent with when and where it decides to present itself, but it does seem related somehow to distance.  I've never seen it on normal-distance bodies (like stock kerbal distances).

It's been a bug since past version 1.7.3 of KSP, AFAIK.

After more testing, it seems that it's a bug somehow related to GU. I decided to test the distance theory, so I did GU homeswitch, and tested it in the new home system. Still happened, only difference was that now the kerbals would get pushed out more often (probably because the physics engine has a better time correcting itself at lower distances). But it seems to not be distance related when it comes to GU

[Gotmachine]

1 hour ago, Grond said:

I decided to test the distance theory, so I did GU homeswitch, and tested it in the new home system.

Changing the home system has no effect on how coordinates are computed, what matters is the distance from the original KSP sun.
This being said, the real cause of that issue remains a mystery for everyone.
All we know is that it happen more frequently the further you are from the original sun, and that preventing some of the MakingHistory DLC functionality to be active seems to further reduce the probability of that issue.

Edit : I might be wrong, actually. Does the GU home switch work by replacing the Kerbol system with a custom one ? In which case you are right, distance has nothing to do with it, and the issue is caused by something Kopernicus is doing (or not doing).
Which would make at lot of sense. The whole issue seems to be caused by the Unity collision ignore matrix becoming somehow messed up.

Edited November 18, 2021 by Gotmachine