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

[OrbitalManeuvers]

I'm able to confirm that without any planet pack, the sky is black in the daytime. But this same build works fine with JNSQ. Here's the log from the black sky install:

https://drive.google.com/drive/folders/1wz1LdB-o3NgSrWF_pZWCZW2eC87czhMI?usp=sharing

[Juba]

1 hour ago, OrbitalManeuvers said:

I'm able to confirm that without any planet pack, the sky is black in the daytime. But this same build works fine with JNSQ. Here's the log from the black sky install:

https://drive.google.com/drive/folders/1wz1LdB-o3NgSrWF_pZWCZW2eC87czhMI?usp=sharing

This explains why I don't have the black sky issue since I have a Planet pack installed.

But you still got the KSC lights issue ?

[R-T-B]

I found the bug.  It was introduced by small error in casts in last release.  Oops.

@Juba @emiliofloris

Here is the fix.  Unfortunately hazbod is still broken but hey, at least the sky and day/night is working again.:

Kopernicus release-40

R-T-B released this now

New in this latest version (release-40):

1.) Fixed a day/night cycle/KSP lights on/off bug caused by faulty star detection code, introduced in last release.

Known Bugs:

1.) 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.

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.) Hazardous Body object is presently broken, and has been for some time aparently. We are working on this for a near future release. Don't go driving in lava you shouldn't drive in, now...

Edited June 3, 2021 by R-T-B

[oniontrain]

KSP was running fine yesterday, today all I did was update Kopernicus and now I'm getting a b9 part switch error on load. I have no idea why this could be related but that's literally the only thing I did. If anybody could tell me where to start troubleshooting that would be helpful

Error as follows:

 

B9PartSwitch has encountered a fatal error and KSP needs to close.

Fatal exception while loading tank type LiquidFuel

  Exception while loading field resources on type B9PartSwitch.TankType

  Exception while loading field resourceDefinition on type B9PartSwitch.TankResource

 No resource definition named 'LiquidFuel' could be found

Please see KSP's log for addtional  details

KSP then force quits.

Pastebin won't let me upload my log as it's longer than 512k, but I think this is the relevant part:

 

[EXC 21:27:17.392] [ModuleManager] Exception while calling B9PartSwitch.B9TankSettings.ModuleManagerPostLoad(): System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Exception: Fatal exception while loading tank type LiquidFuel ---> System.Exception: Exception while loading field resources on type B9PartSwitch.TankType ---> System.Exception: Exception while loading field resourceDefinition on type B9PartSwitch.TankResource ---> B9PartSwitch.Fishbones.Parsers.PartResourceDefinitionValueParser+PartResourceNotFoundException: No resource definition named 'LiquidFuel' could be found
  at B9PartSwitch.Fishbones.Parsers.PartResourceDefinitionValueParser.FindResourceDefinition (System.String name) [0x00024] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.Fishbones.Parsers.ValueParser`1[T].Parse (System.String value) [0x0000b] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.Fishbones.NodeDataMappers.ValueScalarMapper.Load (System.Object& fieldValue, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00022] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.Fishbones.NodeDataField.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00043] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00025] in <2aacd5f344de4b4cbd0690767697fdd6>:0
   --- End of inner exception stack trace ---
  at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00058] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.Fishbones.NodeDataObjectExtensions.LoadFields (System.Object obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00033] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.TankResource.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.Fishbones.Parsers.NodeObjectWrapperIContextualNode.Load (System.Object& obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00038] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.Fishbones.NodeDataMappers.NodeListMapper.Load (System.Object& fieldValue, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x0009e] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.Fishbones.NodeDataField.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00043] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00025] in <2aacd5f344de4b4cbd0690767697fdd6>:0
   --- End of inner exception stack trace ---
  at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00058] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.Fishbones.NodeDataObjectExtensions.LoadFields (System.Object obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00033] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.TankType.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.B9TankSettings.ReloadTankDefs () [0x0004c] in <2aacd5f344de4b4cbd0690767697fdd6>:0
   --- End of inner exception stack trace ---
  at B9PartSwitch.B9TankSettings.ReloadTankDefs () [0x0007f] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at B9PartSwitch.B9TankSettings.ModuleManagerPostLoad () [0x00000] in <2aacd5f344de4b4cbd0690767697fdd6>:0
  at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0
   --- End of inner exception stack trace ---
  at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00048] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0
  at ModuleManager.PostPatchLoader+<Run>d__16.MoveNext () [0x0060b] in <410b7909691747c78c895491c954d2a4>:0

[LOG 21:27:17.411] [ModuleManager] Post patch ran in 0.188s
[LOG 21:27:17.436] PartLoader: Loading part database
[LOG 21:27:17.438] PartLoader: Compiling Part 'AviationLights/Parts/aviation_light/light_aviation'
[LOG 21:27:17.464] EffectList: Created 15 effect types
[EXC 21:27:17.511] NullReferenceException: Object reference not set to an instance of an object
    AviationLights.ModuleNavLight.GetInfo () (at <58ace71ce5fd40dcb7d91808d90fe47b>:0)
    PartLoader.CompilePartInfo (AvailablePart newPartInfo, Part part) (at <06f13185617646e5bc801baeab53ab75>:0)
    PartLoader+<CompileParts>d__56.MoveNext () (at <06f13185617646e5bc801baeab53ab75>:0)
    UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <5aeafee3fea24f37abd1315553f2cfa6>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

 

Edited June 4, 2021 by oniontrain

[R-T-B]

Nothing should have changed with regards to b9partswitch for quite some time.  How long did you have between updates?  It is possible if you had not updated for some time that the new solar math deployed around Febuaryish is interacting badly with something.  Do you happen to know the last version that worked?

[Techercizer]

As a heads up, I'm pretty sure the *.39 and *.40 patch combo introduced a new crash into my RSS game. I had an issue where after updating, I would load into my autosave with a craft heading away from earth on an impact course for the moon, timewarp to just above the moon, start a suicide burn (and run some tests for contracts while burning), and consistently freeze/crash as I neared the moon's surface. This happened about 8 load-crash-retry cycles in a row, until I rolled back Kopernicus to *.38  and it worked just fine the very next try.

I still have the autosave if you want any logs (player.log? others?) to look into this, but I've got a lot of mods in this install so it's likely not as simple as some easily testable conflict with stock.

[AVaughan]

7 hours ago, Techercizer said:

As a heads up, I'm pretty sure the *.39 and *.40 patch combo introduced a new crash into my RSS game. I had an issue where after updating, I would load into my autosave with a craft heading away from earth on an impact course for the moon, timewarp to just above the moon, start a suicide burn (and run some tests for contracts while burning), and consistently freeze/crash as I neared the moon's surface. This happened about 8 load-crash-retry cycles in a row, until I rolled back Kopernicus to *.38  and it worked just fine the very next try.

I still have the autosave if you want any logs (player.log? others?) to look into this, but I've got a lot of mods in this install so it's likely not as simple as some easily testable conflict with stock.

Around 3-4 months ago there was a similar repeatable KSP crash or freeze reported on the RO discord during someone's Moon landing.  From memory that was traced to KER's landing prediction.  Disabling that allowed the de-orbit and landing burns to proceed.    

 

Edit:  Found the conversation.  It wasn't the Moon, it was Vesta.  https://discord.com/channels/319857228905447436/331813459417235457/822357256292794388

Quote

I've got a probe doing a fly-by of Vesta; its periapsis is positive but inside the terrain. When I perform a burn that lifts the periapsis above the terrain, the game locks up (CPU pegs at 100%, screen stops updating). Repro'd three times now. Is this a known issue?

 

Edited June 5, 2021 by AVaughan

[Techercizer]

Hmm, well I don't have KER installed and was doing a manual burn (no guidance), but I did have mechjeb in which does have landing guidance capabilities. Despite being an RSS install,  I've actually forgone RO in favor of individually installing most RO mods (Real Fuels, FAR, and such) and using SMURFF instead.

 

Regardless, I rolled back to Kopernicus *.38 and haven't had a crash since, so for now I'm just chilling on that version.

[oniontrain]

On 6/3/2021 at 11:47 PM, R-T-B said:

Nothing should have changed with regards to b9partswitch for quite some time.  How long did you have between updates?  It is possible if you had not updated for some time that the new solar math deployed around Febuaryish is interacting badly with something.  Do you happen to know the last version that worked?

Not sure what the last version was but it should have been current. I have been getting them off of CKAN, I'm not sure if there's a way to roll back to previous versions or not

 

edit: i went from 1.11.1-39 to 1.11.1-40

Edit again: It's not Kopernicus, it must be another mod. Disregard everything.

Edited June 5, 2021 by oniontrain

[Gordon Fecyk]

ROC / Breaking Ground object configuration question

So Kopernicus Continued was supposed to include the features from JNSQ's MyRocksAreBiggerThanYours.dll but I'm having trouble placing ROCs on a customized home world in Alien Space Programs.

ASP works by re-creating Kerbin using the template of a different place, but internally it's still named "Kerbin." The uninhabited Kerbin is named "Bin" internally but shows up as "Kerbin" due to localization features. 

What I don't know, is when a ROC_DEFINITION's CELESTIALBODY information is parsed, does it use the internal name, the "cbNameLater" name, the localized name / displayName, or some other value? 

[dave1904]

I really hope KSP2 allows you to mod planets in a far simpler way. Kopernicus seems to be the most annoying mod to work on there is. 

[Snark]

On 6/6/2021 at 11:02 AM, dave1904 said:

I really hope KSP2 allows you to mod planets in a far simpler way.

I suspect a lot of folks hope that, too.  The fact that Kopernicus is effectively mandatory for solar system modding puts an unreasonable pressure on the Kopernicus maintainers to keep it running-- and my impression is that it's a lot of work for them.

On 6/6/2021 at 11:02 AM, dave1904 said:

Kopernicus seems to be the most annoying mod to work on there is.

Not sure how "annoying" it is for the mod's maintainers to work on it, but it sounds like a big job.  I've always been extremely grateful to all the folks putting in hard work on Kopernicus to make life easier for the rest of us.  Without their efforts, solar system modding would be... perhaps not impossible... but much more difficult and likely much less common.

(And I've always been very impressed at how easy it is to use Kopernicus to mod the solar system.)

[dave1904]

3 minutes ago, Snark said:

I suspect a lot of folks hope that, too.  The fact that Kopernicus is effectively mandatory for solar system modding puts an unreasonable pressure on the Kopernicus maintainers to keep it running-- and my impression is that it's a lot of work for them.

Not sure how "annoying" it is for the mod's maintainers to work on it, but it sounds like a big job.  I've always been extremely grateful to all the folks putting in hard work on Kopernicus to make life easier for the rest of us.  Without their efforts, solar system modding would be... perhaps not impossible... but much more difficult and likely much less common.

(And I've always been very impressed at how easy it is to use Kopernicus to mod the solar system.)

Without kopernicus I would have been done with KSP years ago and I honestly suspect alot of other players. There is only so much you can do with the stock solar system but Kopernicus makes it infinite. 

[GuessingEveryDay]

I'm not able to use KSRSS, it says that there is an error with loading the sun, and then after I uninstall it, it doesn't allow me to play the stock game anymore, because the sun is gone from there too!

[Al2Me6]

Turns out the checkerboard bug is still around... This is RSS with Kopernicus release 40, on KSP 1.10.1.

[R-T-B]

On 6/8/2021 at 2:51 PM, GuessingEveryDay said:

I'm not able to use KSRSS, it says that there is an error with loading the sun, and then after I uninstall it, it doesn't allow me to play the stock game anymore, because the sun is gone from there too!

I would suggest a reinstall as something in your game must be corrupted.

 

2 hours ago, Al2Me6 said:

Turns out the checkerboard bug is still around... This is RSS with Kopernicus release 40, on KSP 1.10.1.

The checkerboard bug is caused by a config issue, not really a bug.  It happens when you use the 1.8+ shader on a planet without support for it.  That said I don't really see it that strongly in your screenshot.

On 6/5/2021 at 10:34 AM, Gordon Fecyk said:

ROC / Breaking Ground object configuration question

So Kopernicus Continued was supposed to include the features from JNSQ's MyRocksAreBiggerThanYours.dll but I'm having trouble placing ROCs on a customized home world in Alien Space Programs.

ASP works by re-creating Kerbin using the template of a different place, but internally it's still named "Kerbin." The uninhabited Kerbin is named "Bin" internally but shows up as "Kerbin" due to localization features. 

What I don't know, is when a ROC_DEFINITION's CELESTIALBODY information is parsed, does it use the internal name, the "cbNameLater" name, the localized name / displayName, or some other value? 

I honestly am unsure on this, and would suggest experimentation.  I literally just imported MyRocksAreBiggerThanYours code with the help of it's author, and it should behave identically.

On 6/7/2021 at 11:46 AM, Snark said:

Not sure how "annoying" it is for the mod's maintainers to work on it, but it sounds like a big job.  I

Nah, he's kind of right frankly.  But a lot of this is squad syntax we are just exposing.  Thus, not my fault... lol.

Plus at this point my main aim is to keep it running, that's really the big goal here.  It's annoying but worth it.

Of course, it COULD BE much worse.  Trust me.  We have it easy compared to some systems I've seen.  Humanity can come up with truly awful things sometimes when too many programmers try to get clever in their own secret code/language...

On 6/7/2021 at 11:46 AM, Snark said:

and my impression is that it's a lot of work for them.

Kopernicus itself is an amazing and terrifying project, so for that part, yes.  It's very time consuming AND very hard to fit in with a real life job.  But we try.

Edited June 12, 2021 by R-T-B

[Al2Me6]

9 minutes ago, R-T-B said:

The checkerboard bug is caused by a config issue, not really a bug.  It happens when you use the 1.8+ shader on a planet without support for it.  That said I don't really see it that strongly in your screenshot.

Would there be a way to fix it? I understanding there's some kind of templating system involved.

It is indeed not too obvious in this screenshot, just a few squares near the Cape. I believe it might be more frequent/severe for other bodies, though (Mars's moons are affected, I think).

[R-T-B]

3 hours ago, Al2Me6 said:

Would there be a way to fix it? I understanding there's some kind of templating system involved.

It is indeed not too obvious in this screenshot, just a few squares near the Cape. I believe it might be more frequent/severe for other bodies, though (Mars's moons are affected, I think).

I described it on Kopernicus Discord.  Copying it here for reference:

"Anouncement:  I have cracked the issue with square tiles on Joolian Moon templates.  It is not a Kopernicus bug so much as an improper use of configs.  Most configs (JNSQ included) are using AtmosphericTriplanarZoomRotation as their PQS material.  This DOES NOT WORK on the following bodies as they don't implement that shader:  Laythe (1.9.1 only), Tylo, Bop, Pol, Eeloo.  You must use AtmosphericBasic/AtmosphericOptimized or Vacuum on these bodies or you will get the tile bug!  It's that simple!"

 

Note some of those moons gained that material since I posted that, but it depends on which KSP you are running.  1.11 has it on a lot more moons.

Edited June 13, 2021 by R-T-B

[Al2Me6]

2 hours ago, R-T-B said:

"Anouncement:  I have cracked the issue with square tiles on Joolian Moon templates.  It is not a Kopernicus bug so much as an improper use of configs.  Most configs (JNSQ included) are using AtmosphericTriplanarZoomRotation as their PQS material.  This DOES NOT WORK on the following bodies as they don't implement that shader:  Laythe (1.9.1 only), Tylo, Bop, Pol, Eeloo.  You must use AtmosphericBasic/AtmosphericOptimized or Vacuum on these bodies or you will get the tile bug!  It's that simple!"

Hmm, Earth uses the Kerbin template: https://github.com/KSP-RO/RealSolarSystem/blob/f527765729f0ba0e1c671ba151566dea31063a4a/GameData/RealSolarSystem/RSSKopernicus/Earth/Earth.cfg#L11-L13

[R-T-B]

21 minutes ago, Al2Me6 said:

Hmm, Earth uses the Kerbin template: https://github.com/KSP-RO/RealSolarSystem/blob/f527765729f0ba0e1c671ba151566dea31063a4a/GameData/RealSolarSystem/RSSKopernicus/Earth/Earth.cfg#L11-L13

Then I honestly don't know what would cause that.  That's very odd.   Are you using scatterer or anything else that may be playing with the scenery in some way?

I have seen some behavior like that with scatterer but usually disabling distant shadows will fix it.

Edited June 13, 2021 by R-T-B

[R-T-B]

Kopernicus release-41

R-T-B released this now

New in this latest version (release-41):

1.) Hazbod is now functional. It has been for a bit actually. Note: Kerbal stock game parts are extermely heat tolerant and may take time to burn!

2.) Experimental fixes for landing gear sinking in distant bodies, worth testing. May/may not work but won't hurt either way.

Known Bugs:

1.) 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.

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.

Edited June 17, 2021 by R-T-B

[R-T-B]

Kopernicus release-42

R-T-B released this 1 minute ago

New in this latest version (release-42):

1.) Hopefully the final, proper fix for incorrectly vertically elevated land scatters. Will have a performance impact, but should not be more than the culler can handle for most configs.

Known Bugs:

1.) 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.

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.

Edited June 17, 2021 by R-T-B

[Cruesoe]

These releases are coming so quick that you've gone into the future!

Latest release July 2021!

[R-T-B]

8 hours ago, Cruesoe said:

These releases are coming so quick that you've gone into the future!

Latest release July 2021!

Oops.  Fixed, lol.

[Mike J]

When I tried to load ksp with rss I got this issue with Kopernicus. I'm not sure why I have gotten this issue as I installed both Kopernicus and RSS correctly. 

Image of the warning: https://imgur.com/a/l5mKBMw

My ksp.log: https://www.dropbox.com/s/n9c0jv980myffen/KSP.log?dl=0