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

[R-T-B]

release-65

New in this latest version release-65:

1.) Some slightly too agressive masking was rolled back to fix the fact that the KopernicusWatchdog fake-celestial ceased to function. Some mods may break because of this, I will be patching mods and making PRs actively as I can over the next few weeks. Until then, see change #2 if you want an immediate fix for a broken mod.

2.) An optional cfg was added to release to disable the KopernicusWatchdog fake celestial body (at the cost of losing the distant body terrain sinking issue fix). This may help with mod compatibility for out-of-date mods. Simply drop in the Gamedata/Kopernicus/Config folder.

Known Bugs:

1.) The ingame shadows without an external mod like scatterer can be glitchy. It is advisable to use an external mod for best experience at the moment.

2.) At interstellar ranges, heat can sometimes behave strangely, sometimes related to map zoom (be careful zooming out). It is best to turn off part heating when traveling far far away.

3.) When zooming out all the way out in map view at interstellar ranges, the navbal furthermore sometimes behaves oddly. We are working on this and all the interstellar bugs actively.

4.) 1.) Very Old craft files may complain about a missing module. This is a cosmetic error and can be ignored. Reload and re-save the craft to remove the error.
Known Caveats:

1.) The 1.12.x release series works on 1.12.x,1.11.x,1.10.x, and 1.9.x. The 1.8 release is for 1.8.x.

2.) Mutlistar Solar panel support requires an additonal config file, attatched to release.

3.) A fake celestial body is now used to fix the distant sinking bug. This body is called "KopernicusWatchdog" and will a.) intentionally keep it's distance from you at all times and is b.) invisible. The body is usually hidden from in game processes, but this is new territory having to use another moving celestial to correct a bug, so there may be side effects. Also, Principia does not benefit from this fix at this time, unfortunately. Those users may try "MakingLessHistory" mod, the old workaround. Other legacy mods that are broken from this change may use the optional RemoveWatchdog.cfg to bypass this and work again.

4.) When using the ultra/atlas shader, ocean effect customization (color etc) is unreliable. Please use only high shader level (shader level 2) or lower if working with stock ocean effects. This does not effect scatterer or other ocean rendering mods.

 

Take note of the bolded points.  I will be updating some mods and helping other present and available authors to update over the next few weeks, but if you have a mod that is not up to date and broken, the cfg mentioned in the bold points above may be just what you need...  especially if you do not need the distant body fixes.  Thanks for reading.

[Gordon Dry]

8 hours ago, R-T-B said:

see change #2

So now I'm confused.

At https://github.com/Kopernicus/Kopernicus/commit/d647f630a265222ed2303c3884f18bf6af42d4b8#diff-e0b88eafbbc60145dc5494216bb9648fed9042a27dd4dd6b6954f02b710c0abfL18 there is a change at GameData/Kopernicus/Config/SolarPanels.cfg (I know this is outdated, there is the additional MultiStarSolarPanels.cfg nowadays), but:

The old fix changed the name of the module from KopernicusSolarPanel to KopernicusSolarPanels.
Inside MultiStarSolarPanels.cfg it says

//First delete all old "KopernicusSolarPanels" fixers
@PART:HAS[@MODULE[ModuleDeployableSolarPanel]]:FINAL
{
    !MODULE[KopernicusSolarPanels]
}

// Converts all ModuleDeployableSolarPanel modules within a part to KopernicusSolarPanels unless the part has useKopernicusSolarPanels = false
@PART:HAS[@MODULE[ModuleDeployableSolarPanel],~useKopernicusSolarPanels[false]]:FINAL
{
    @MODULE[ModuleDeployableSolarPanel],*
    {
        @name = KopernicusSolarPanel
    }
}

So what is the correct way now?

First it was changed from without "s" to with "s" - now all instances with "s" are removed and new instances without "s" are created by renaming ModuleDeployableSolarPanel.
Then you refer to that old commit.

What?

Edited November 22, 2021 by Gordon Dry

[modus]

@R-T-Bshall we prepare the old Bleeding Edge thread for your arrival, sir?

[R-T-B]

2 hours ago, Gordon Dry said:

So now I'm confused.

At https://github.com/Kopernicus/Kopernicus/commit/d647f630a265222ed2303c3884f18bf6af42d4b8#diff-e0b88eafbbc60145dc5494216bb9648fed9042a27dd4dd6b6954f02b710c0abfL18 there is a change at GameData/Kopernicus/Config/SolarPanels.cfg (I know this is outdated, there is the additional MultiStarSolarPanels.cfg nowadays), but:

The old fix changed the name of the module from KopernicusSolarPanel to KopernicusSolarPanels.
Inside MultiStarSolarPanels.cfg it says

//First delete all old "KopernicusSolarPanels" fixers
@PART:HAS[@MODULE[ModuleDeployableSolarPanel]]:FINAL
{
    !MODULE[KopernicusSolarPanels]
}

// Converts all ModuleDeployableSolarPanel modules within a part to KopernicusSolarPanels unless the part has useKopernicusSolarPanels = false
@PART:HAS[@MODULE[ModuleDeployableSolarPanel],~useKopernicusSolarPanels[false]]:FINAL
{
    @MODULE[ModuleDeployableSolarPanel],*
    {
        @name = KopernicusSolarPanel
    }
}

So what is the correct way now?

First it was changed from without "s" to with "s" - now all instances with "s" are removed and new instances without "s" are created by renaming ModuleDeployableSolarPanel.
Then you refer to that old commit.

What?

The naming is indeed confusing, because I kept trying to keep from having to run code in individual solar panels (the version without the "s").  In the end, I had to revert to that.  But since it has a slight performance impact, multistar by default is not enabled, it will only be enabled by downloading the additional cfg, which will then remove all the old "s" fixers (that did not work properly) and apply the older, more reliable (but performance hurting) multistar code that runs on a per-panel basis.

I hope that clarifies?  The code lineage is indeed confusing (due to me attempting a dead end method of performance enhancement, and reverting to the old way in the end), but all users need to know is if they want multistar, they should simply download the cfg and it will handle any instance.  If they don't, leave it alone cfg wise, and ditto.

 

By the way, I'm not entirely sure the repos SolarPanels.cfg is up to date...  this is what we are using at the moment for single star scenarios (stock shipping cfg):

// If any modder adds useKopernicusSolarPanels = false to a module instead of a part, add it to the part:
@PART:HAS[@MODULE:HAS[#useKopernicusSolarPanels[?alse]]]:FINAL
{
	%useKopernicusSolarPanels = false
}

// Uses regular expressions to convert any case variants like FalSe to false
@PART:HAS[#useKopernicusSolarPanels[*]]:FINAL
{
    // This cfg will enable KopernicusSolarPanels
    // to allow support for multiple lightsources
    // 
    // If you want to avoid this, add "useKopernicusSolarPanels = false" to the PART node
    // That will stop Kopernicus from changing the behaviour of SolarPanel
    @useKopernicusSolarPanels,* ^= :F:f:
    @useKopernicusSolarPanels,* ^= :A:a:
    @useKopernicusSolarPanels,* ^= :L:l:
    @useKopernicusSolarPanels,* ^= :S:s:
    @useKopernicusSolarPanels,* ^= :E:e:
}

//First delete all old "KopernicusSolarPanels" fixers
@PART:HAS[@MODULE[ModuleDeployableSolarPanel]]:FINAL
{
	!MODULE[KopernicusSolarPanels]
}

  

1 hour ago, modus said:

@R-T-Bshall we prepare the old Bleeding Edge thread for your arrival, sir?

You know they say hindsight is 20/20...  I probably should've awoken that for this.  Unfortunately, we're already through the worst.  I certainly will for future experiments though.

Edited November 22, 2021 by R-T-B

[dave1904]

On 11/16/2021 at 10:03 PM, R-T-B said:

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.

I finally got around to this but all it does is decrease draw distance of terrain. The floating rocks are still there but fewer because there is obviously a smaller area with less draw distance. If anything performance was better at 0

[R-T-B]

1 hour ago, dave1904 said:

I finally got around to this but all it does is decrease draw distance of terrain. The floating rocks are still there but fewer because there is obviously a smaller area with less draw distance. If anything performance was better at 0

Try setting it to 1 (maybe the code does not like 0).  Either way, that config option should have no connection to draw distance.

The variable is ScatterCleanupDelta, btw, not ScatterCullDistance.

[dave1904]

15 minutes ago, R-T-B said:

Try setting it to 1 (maybe the code does not like 0).  Either way, that config option should have no connection to draw distance.

The variable is ScatterCleanupDelta, btw, not ScatterCullDistance.

1 made no difference either. I know that because I accidentally put it to 1 at first. Just as you said. I will try it again on 1 for. Im not sure if I will get results today because I know from past versions of KSP that teleporting to orbit causes this issue too so I want to travel there by rocket.  

My current settings but I put it back to 1 to make sure I am 100% right. Again to make it clear I am using rescale 3.5 incase you missed that. Could it be caused by rescale? I have honestly not tested it without rescale. If you need any test results I can do them.  

Kopernicus_config
{
    EnforceShaders = false
    WarnShaders = false
    EnforcedShaderLevel = 2
    ScatterCullDistance = 5000
    ScatterCleanupDelta = 0
    UsePureStockScatters = False
    UseKopernicusAsteroidSystem = True
    SolarRefreshRate = 1
}

Edit: I'll do some test runs now with infinite fuel to get more consistent data. 

Edited November 22, 2021 by dave1904

[dave1904]

After some testing I can tell you for certain that ScatterCleanupDelta has no effect on floating bodies. I have figured out how to consistently make bodies float. At first I sent a really high TWR rocket to the mun on stock scale and rescale 3.5 and basically did a suicide burn to stop and bodies did not float. So then I did it the normal way. Went into a 10kmx10km orbit and then landed. I noticed that when you land on a shallow angle that more bodies float. The longer the burn across the surface the more terrain you load and the more rocks float. BTW. Making less history is not installed in this case. Would that have an effect?

I also don't notice any difference between ScatterCleanupDelta 1 and ScatterCleanupDelta 4. Was not using FPS counter but wanted to make sure I could consistently recreate the floating bodies. 

If you want to test without going to the mun over and over again you can quicksave and quickload. All you need to do is travel across the surface of the mun and cover enough distance until bodies float. 

Edited November 22, 2021 by dave1904

[R-T-B]

 

2 hours ago, dave1904 said:

After some testing I can tell you for certain that ScatterCleanupDelta has no effect on floating bodies. I have figured out how to consistently make bodies float. At first I sent a really high TWR rocket to the mun on stock scale and rescale 3.5 and basically did a suicide burn to stop and bodies did not float. So then I did it the normal way. Went into a 10kmx10km orbit and then landed. I noticed that when you land on a shallow angle that more bodies float. The longer the burn across the surface the more terrain you load and the more rocks float. BTW. Making less history is not installed in this case. Would that have an effect?

I also don't notice any difference between ScatterCleanupDelta 1 and ScatterCleanupDelta 4. Was not using FPS counter but wanted to make sure I could consistently recreate the floating bodies. 

If you want to test without going to the mun over and over again you can quicksave and quickload. All you need to do is travel across the surface of the mun and cover enough distance until bodies float. 

I appreciate the feedback.  I'll list it as a bug and look into it.  Darn, I thought we had that one more or less under control.  Oh well.

It's possible this is a regression as well (as in, an old bug that was fixed and somehow came back).  Either way I'll try to fix it next release.  I hope that will be within the week.

Edit:  The issue for it is created, here.

Edited November 22, 2021 by R-T-B

[Jason Kerman]

Hi R-T-B! I installed release 65 but I still experience sinking land gear bug occasionally in my planet pack. It's hard to tell when it will happen. 

Log: https://drive.google.com/file/d/1vvBllVRK8N-FH1aM9KpBF94cEPwun8W_/view?usp=sharing

 

[dave1904]

13 hours ago, R-T-B said:

 

I appreciate the feedback.  I'll list it as a bug and look into it.  Darn, I thought we had that one more or less under control.  Oh well.

It's possible this is a regression as well (as in, an old bug that was fixed and somehow came back).  Either way I'll try to fix it next release.  I hope that will be within the week.

Edit:  The issue for it is created, here.

You make me feel bad about reporting things because you always try fixing things ASAP.  Take your time. 

Edited November 23, 2021 by dave1904

[fragtzack]

 "KopernicusWatchdog" is showing up in Kerbal Alarm Clock mod "transfer windows" selection. Not causing any crashes that I can tell though. Rel 65

Edit: Rel65 seems to have re-introduced the breakage of Strategia mod. Going back to Rel 64 works for Strategia.

Edited November 23, 2021 by fragtzack

[Nantares]

On 11/22/2021 at 10:53 AM, R-T-B said:

Mutlistar Solar panel support requires an additonal config file

how I can install this config file, just put it in Gamedata folder?

[Brigadier]

13 hours ago, Nantares said:

how I can install this config file, just put it in Gamedata folder?

Yes, that would work since a .cfg file anywhere in GameData will be processed by MM.

However, I would recommend placing it in either the Kopnericus folder, since it's related to that mod, or a folder you create in GameData specifically for your unique .cfg files, i.e. zz_MyConfigs.  If you chose the former, realize that reinstalling the mod may overwrite or delete your config file and you might need to reinstall it.  If you chose the latter, you'll need to remember to update or delete it if the multistar config changes or is subsumed by the mod (more likely a update would occur).

[tmccreight651]

Hi, im getting a really weird error on startup

"Kopernicus was not able to load the custom planetary system due to an exception in the loading process. Loading your savegame is NOT recomended because the missing planets could corrupt it and delete your progress.

Please contact the planet pack author or the Kopernicus Team about the issue and send them a valid bug report incluiding your KSP.log your Modulemanager .Configcache file and the folder Logs/Kopernicus/ from your KSP directory" 

As far as im aware all of the mods relating to the planet packs (Rescale x2.5 and OPM) are up to date.

Here's a link to the requested logs

Many thanks!

 https://www.dropbox.com/s/o419jlc4710gphu/Error Logs 22-11-2021.rar?dl=0

[R-T-B]

On 11/22/2021 at 1:42 PM, Jason Kerman said:

Hi R-T-B! I installed release 65 but I still experience sinking land gear bug occasionally in my planet pack. It's hard to tell when it will happen. 

Log: https://drive.google.com/file/d/1vvBllVRK8N-FH1aM9KpBF94cEPwun8W_/view?usp=sharing

 

Most appreciated.  I wonder if the masking can't be used at all?  Maybe the "fake- planet" needs to be visible to the game.  Odd.

If that's the case a lot of mods will need to update.  That would be painful.  Can you do me a favor and test Release-62 and see if it helps you?  It has less of the masking and will interfere with mods worse, but may confirm my theory.

  

On 11/23/2021 at 3:47 AM, fragtzack said:

 "KopernicusWatchdog" is showing up in Kerbal Alarm Clock mod "transfer windows" selection. Not causing any crashes that I can tell though. Rel 65

Edit: Rel65 seems to have re-introduced the breakage of Strategia mod. Going back to Rel 64 works for Strategia.

Strategia will need to be manually updated, but for now there is no need to revert.  Just download "RemoveWatchdog.cfg" in the release notes to your config folder and it will turn that change off until some mods update.

Linky.

On 11/23/2021 at 2:28 AM, dave1904 said:

You make me feel bad about reporting things because you always try fixing things ASAP.  Take your time. 

Oh don't worry, I never work when I shouldn't (as evidenced by my sometimes long work-related abscenes).  You should never feel guilty for reporting a bug.  Better you experience it than me in my playthrough, is how I look at it...  lol.

2 hours ago, tmccreight651 said:

Hi, im getting a really weird error on startup

"Kopernicus was not able to load the custom planetary system due to an exception in the loading process. Loading your savegame is NOT recomended because the missing planets could corrupt it and delete your progress.

Please contact the planet pack author or the Kopernicus Team about the issue and send them a valid bug report incluiding your KSP.log your Modulemanager .Configcache file and the folder Logs/Kopernicus/ from your KSP directory" 

As far as im aware all of the mods relating to the planet packs (Rescale x2.5 and OPM) are up to date.

Here's a link to the requested logs

Many thanks!

 https://www.dropbox.com/s/o419jlc4710gphu/Error Logs 22-11-2021.rar?dl=0

That is an odd one.  It claims it can't load the sun, hmmm....  what was the last version you used that worked (if any?)

Screenshot of GameData folder, maybe?

Edited November 25, 2021 by R-T-B

[R-T-B]

Heads up that I am taking votes on the next project after the watchdog fixes are complete (est. by December).

 

[Jason Kerman]

3 hours ago, R-T-B said:

Most appreciated.  I wonder if the masking can't be used at all?  Maybe the "fake- planet" needs to be visible to the game.  Odd.

If that's the case a lot of mods will need to update.  That would be painful.  Can you do me a favor and test Release-62 and see if it helps you?  It has less of the masking and will interfere with mods worse, but may confirm my theory.

I tested with release 62 but the bug is still there. I have sent my mod through discord. Thank you so much!

[R-T-B]

2 hours ago, Jason Kerman said:

I tested with release 62 but the bug is still there. I have sent my mod through discord. Thank you so much!

The latest release should patch this, I also sent you a dev build that is "inbetween" fix wise.

The only thing different about the release is you'll need to add the "AddWatchdog.cfg" to your mod manually to get the fix (not on by default anymore because broken mods).

Here is the release notes:

Kopernicus release-66

New in this latest version release-66:

1.) Turned off the "sinking landing gear on distant bodies" -fix by default because of mod incompatabilites. You can still get this fix (see change #2) it just isn't on by default because of how much it broke certain types of mods.

2.) If you need the fix for landing gear sinking on distant bodies and are ok with the side-effects of it, Simply download attatched "AddWatchdog.cfg" and drop in the Gamedata/Kopernicus/Config folder.

Known Bugs:

1.) The ingame shadows without an external mod like scatterer can be glitchy. It is advisable to use an external mod for best experience at the moment.

2.) Land scatters can appear at incorrect elevations if you don't use Kopernicus option "UsePureStockSCatters," which sadly, only works on pure stock systems.

2.) At interstellar ranges, heat can sometimes behave strangely, sometimes related to map zoom (be careful zooming out). It is best to turn off part heating when traveling far far away.

3.) When zooming out all the way out in map view at interstellar ranges, the navbal furthermore sometimes behaves oddly. We are working on this and nmonitoring all the interstellar bugs actively.

4.) 1.) Very Old craft files may complain about a missing module. This is a cosmetic error and can be ignored. Reload and re-save the craft to remove the error.
Known Caveats:

1.) The 1.12.x release series works on 1.12.x,1.11.x,1.10.x, and 1.9.x. The 1.8 release is for 1.8.x.

2.) Mutlistar Solar panel support requires an additonal config file, attatched to release.

3.) If you use the "AddWatchdog.cfg" file, A fake celestial body isthen used to fix the distant landing-gear sinking bug. This body is called "KopernicusWatchdog" and will a.) intentionally keep it's distance from you at all times and is b.) invisible. The body is usually hidden from in game processes, but this is new territory having to use another moving celestial to correct a bug, so there may be side effects. Also, Principia does not benefit from this fix at this time, unfortunately. Those users may try "MakingLessHistory" mod, the old workaround.

4.) When using the ultra/atlas shader, ocean effect customization (color etc) is unreliable. Please use only high shader level (shader level 2) or lower if working with stock ocean effects. This does not effect scatterer or other ocean rendering mods.

Edited November 26, 2021 by R-T-B

[modus]

So is there any difference between this release (in its default setting) and release 60?

Edited November 26, 2021 by modus

[R-T-B]

6 minutes ago, modus said:

So is there any difference between this release (in its default setting) and release 60?

Honestly, no, other than the fact it can spawn and manage/mask the additonal-fake-celestial fix thingy if asked to do so via a cfg, it is identical to release-60.  I do hope to fix some other bugs soon though.

Edited November 26, 2021 by R-T-B

[tmccreight651]

19 hours ago, R-T-B said:

Most appreciated.  I wonder if the masking can't be used at all?  Maybe the "fake- planet" needs to be visible to the game.  Odd.

If that's the case a lot of mods will need to update.  That would be painful.  Can you do me a favor and test Release-62 and see if it helps you?  It has less of the masking and will interfere with mods worse, but may confirm my theory.

  

Strategia will need to be manually updated, but for now there is no need to revert.  Just download "RemoveWatchdog.cfg" in the release notes to your config folder and it will turn that change off until some mods update.

Linky.

Oh don't worry, I never work when I shouldn't (as evidenced by my sometimes long work-related abscenes).  You should never feel guilty for reporting a bug.  Better you experience it than me in my playthrough, is how I look at it...  lol.

That is an odd one.  It claims it can't load the sun, hmmm....  what was the last version you used that worked (if any?)

Screenshot of GameData folder, maybe?

The last Kopernicus version that worked was 1.12.1-61

[R-T-B]

6 hours ago, tmccreight651 said:

The last Kopernicus version that worked was 1.12.1-61

I appreciate that.  That is nearly exactly when some new experimental changes I made that are now rolled back were pushed out.  Try the latest, you may find it works.  Otherwise I'll need a screenshot of gamedata to diagnose further.

And on that note....  I am happy to announce that with the help of @Gotmachine, we have cracked the reason why this whole "distant bodies tend to have landing gear sink" bug happens and it is indeed a bug in the stock code.  KSPCommunityFixes is applying a third party patch, and I advise all who need this to download that.  It's all good stuff, anyways.

The "fake celestial" work around we were using is being removed next release and will no longer function even with the cfg, so please delete that from your config folder if you have it (if you didn't explicitly turn it on by downloading the cfg you don't).  This means that yes, we all get the fix with no broken mods...  You don't even need to update Kopernicus.  Just grab the latest KSPCommunityFixes when it comes out, which should be very soon. 

While the fake celestial worked, it was janky, broke a lot of mods, and only fixed bodies that did not orbit another star over the stock sun.  In short it had a lot of drawbacks, and this fix has none of them.  The range we have to work with now is measurably around 1/10th of a yottameter in my testing, and that is INSANELY big.

Huzzah!

Edited November 26, 2021 by R-T-B

[R-T-B]

Unforunately, I just discovered that the fix we have discovered is much more complicated than just a "implement and fix" type situation.  It had side effects, and doesn't entirely work for all scenarios either.  Frustrating, but we are still working on this, just may be a bit longer.  I don't want to push out a half-working fix again.

Edited November 28, 2021 by R-T-B

[dave1904]

On 11/22/2021 at 9:41 PM, R-T-B said:

I appreciate the feedback.  I'll list it as a bug and look into it.  Darn, I thought we had that one more or less under control.  Oh well.

It's possible this is a regression as well (as in, an old bug that was fixed and somehow came back).  Either way I'll try to fix it next release.  I hope that will be within the week.

I forgot to mention that FPS takes a horrible hit too when the terrain loads. Kerbin is not effected at all but the mun, minmus and ike. I remember you fixed the performance issue. With all my mods I play at around 50-60fps. Once I get into low orbit and start loading assets fps tanks to 10. Once I land and reload FPS is back at 60. Stock game wtih kopernicus(and rescale) is the same thing but not as extreme. FPS goes from 60 to 130 after I reload.