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

[Joontry]

Haven't been able to load my save since installing this latest update via ckan this morning. Running JNSQ with GPP and principia. Was all working fine a couple days ago. Going to try downgrading to v161. When I load the screen is black until I press esc, then there are just stars and no planets and I can't move the camera. If I load a quicksave, I can see the craft but can't go to the map, space center, or tracking station.

 

EDIT: It was Grannus Expansion Pack, not GPP that I have. And the problem went away when I downgraded to v161.

Thank you so much, R-T-B, for your work on this mod, and for addressing this particular concern so quickly!

Edited March 15, 2023 by Joontry

[R-T-B]

18 minutes ago, Joontry said:

Haven't been able to load my save since installing this latest update via ckan this morning. Running JNSQ with GPP and principia. Was all working fine a couple days ago. Going to try downgrading to v161. When I load the screen is black until I press esc, then there are just stars and no planets and I can't move the camera. If I load a quicksave, I can see the craft but can't go to the map, space center, or tracking station.

I finally narrowed the cause of this down, it happens with multiple stars somehow.  Anyhow it should be fixed.  Related issue tracking it: https://github.com/Kopernicus/Kopernicus/issues/577

New in this latest version release-165:

1.) Fixed a bug with the new shadow manager that could cause a infinite loop on loading if used with mainline scatterer and multiple stars.

Known Bugs:

1.) Not exactly a bug, but worth mentioning: The Kopernicus_Config.cfg file is rewritten when the game exits. This means any manual (not in the GUI) edits made while playing the game will not be preserved. Edit the file only with the game exited, please.

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. (I am not sure if this is still releavent as of Release-159, feedback welcome).

3.) When zooming out all the way out in map view at interstellar ranges, the navball furthermore sometimes behaves oddly. We are working on this and monitoring all the interstellar bugs actively. (I am not sure if this is still releavent as of Release-159, feedback welcome).

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

5.) Sometimes when reloading a quicksave to KSC, you will get the KSC sunken into the ground. This is cosmetic only, another reload of the same save will fix it. (This error has been around forever, just now listing it).

6.) When you uninstall a mod that had installed a Terrain Detail preset you were using, it may be listed still in the Graphics settings as "New Text." This is by design. If it bothers you, please reinstall the mod that setup that preset, or delete settings.cfg and let it regenerate.

7.) Some mods that used custom Terrain Presets may require you to delete your settings.cfg file and reset your settings with this release. This is rare, but can happen. See this post for details

Known Caveats:

1.) The 1.12.x release series works on 1.12.x. The 1.11.x,1.10.x,1.9.x and 1.8.x releases are deprecated

2.) Multistar Solar panel support requires an additional config file, attached to release.

3.) As of release-107, scatter density underwent a bugfix on all bodies globally that results in densities acting more dense than before on some select configs. Some mods may need to adjust. Normally we'd not change things like this, but this is technically the correct stock behavior of the node so... if you need the old behavior, see config option UseIncorrectScatterDensityLogic.

4.) As of release-151, polar generation behavior has changed slightly. Though it will be safer overall for new missions, be careful loading existing craft there. This is probably not lethal but I don't want you to be unaware. Maybe make a save just in case?

5.) The "collider fix" as it's called, which fixes the event in which you sink into the terrain on distant bodies, is now on by default. If you really need distant colliders, turn this off, but you'd best have a good reason (I can't think of any).

6.) The particle system was hopelessly broken and has been since sometime past 1.10.x. Few mods used it, so it has been removed completely as of Release-146.

7.) Because we now unpack multipart PQSCity's correctly, you may find some PQSCity structures are in the earth or floating. Report such bugs to your planet pack author as this is an intended change (only cosmetic).

Edited March 15, 2023 by R-T-B

[JoeSheridan]

Thank you for fixing it that soon I can´t play KSP anymore without it.

[R-T-B]

Hello all.  Community feedback time.

The topic for this session will be Kopernicus's release model.  Some people have complained that updates feel "rushed" when they come, or untested.

To be fair, I can see the complaints validity.  The issue is, my testing team these days is basically one guy, and myself.  Also, the fact that Kopernicus operates on a "rolling release" since the "bleeding edge" was closed down doesn't help anything.  At the moment, basically, when I get a day off, I push changes as soon as I dev them after brief test or two in my personal save game.  This obviously has not covered all use cases historically, as some rather significant bugs have slipped through the cracks.

To be honest, I'm not keen on maintaining a separate "Bleeding Edge" branch anymore, but I DO have some ideas.  I'm thinking of using githubs prerelease system to do subreleases (ie "Release-166 RC1") for new fun features (but largely untested ones) BETWEEN stable releases.  These prereleases would be publicly available to anyone on github, but would not propagate to CKAN at all.  Once whatever new feature is proven stable, it would become the "new" release number and go to everyone including CKAN.

Is this a good idea?  Do you have a better one?  Just like it how it is?  Thoughts?  Lets hear it people.

[Grimmas]

I've already gotten used to replacing Kopernicus ten times a day when you are working on it, but the prerelease thing sounds like a good idea. Release early and release often is the mantra to follow. 

[Brigadier]

Firstly, you have done a superlative job in maintaining and developing this mod.  I wish I had half your brains (no, not in a zombie way).  Thank you for the countless hours you've dedicated to this significant contribution to the KSP community.

Second, I use CKAN almost exclusively and I understand GitHub repos (sort of anyway).  I don't update KSP all that often and can, sometimes, pass over a couple of Kopernicus releases.  I've never had a serious problem with any release in my 181-mod install nor any objections to the current release model.  My only issue would be for extended KSP loading times on the first start after each update but that's livable considering the benefits.

That said, all other things being equal, I believe you should create a release candidate repo on GitHub since it:

1.  provides a better opportunity to work out bugs before a CKAN, gen-pop release,
2.  provides a place to experiment to your heart's content without borking the user base (inadvertently or otherwise),
3. potentially offers the chance for others to contribute to maintenance with their own PRs (see 1, and because your release repo will be locked down, right?) , and
4. remains available to those wishing to experiment with/for you and/or test any proposed solution w/o corrupting everyone else (not that your two-person team hasn't done a smashing job in the past).

However, it's not without it's downside.  Some users won't understand the GitHub thing and still want to be on the bleeding edge - just because.  I couldn't guess on what that percentage might be but it's not 0.  Also, regardless of that point, some users won't wish to participate in RC testing or won't provide feedback or provide unhelpful feedback which could add to your workload answering them (the Dear ImGUI repo on GitHub comes to mind).  I may be completely off the mark but getting feedback might be more of a problem than too much.

You, of course, have other, higher, RL priorities, if I recall.  Those come first.

Only you can tell how much time you have to maintain a second public branch, although your main one shouldn't be as onerous. On balance, though, I think your proposal is a good one.  Best of luck either way.

My 5 cents worth (since Canada doesn't have a penny anymore).

[Jacke]

@R-T-B, you may want to talk to @sarbian and find out how he set up a DEV repository with CKAN.  You can add in that via CKAN's Settings > CKAN Settings > Settings window at the top, Metadata Repositories.  That way both the current stable release and DEV RELEASE are both available and can be selected in CKAN to either go with stable or with the testing version within CKAN.

[R-T-B]

1 hour ago, Jacke said:

@R-T-B, you may want to talk to @sarbian and find out how he set up a DEV repository with CKAN.  You can add in that via CKAN's Settings > CKAN Settings > Settings window at the top, Metadata Repositories.  That way both the current stable release and DEV RELEASE are both available and can be selected in CKAN to either go with stable or with the testing version within CKAN.

Oh I know how that's done.  That's what we did with the bleeding edge, back in the day.  Thing is, I'd rather avoid setting up a separate repo, which that sort of requires last time I checked.  We'll be in discussions with CKAN people to make sure there isn't a simpler way though.

[Gotmachine]

I think marking non-patch releases as experimental/pre-release on github (preventing them to be pushed to ckan) is the best solution.
It has been my personal release model for while now, and I think it's the best middle ground.

For that release model to work, however, there are a couple rules to follow :
- You have to advertise as widely as possible the pre-releases, on the same channels where you advertise for the normal releases, because if nobody uses them, nobody will ever report the eventual issues they have, making the whole release model useless.
- They should be clearly advertised as pre-releases, with an emphasis on the changes made and potential issues to look for, with a disclaimer that if users don't intend to check on updates and actively try to troubleshot/report their issues, they should use the stable releases.
- Always sleep for a good while on the pre-releases. You say you have a weekly dev cycle, that's perfect. It's enough so whoever is inclined to use them has had the time to do so, find issues, and report them, and not enough for you to have forgotten what you were doing. And maybe that's not something that happen to everybody, but personally, I often have bad-lightbulb moments one day or two after a release where I realize I did something dumb without even looking at the computer. It's still a relatively fast release pace and you won't end up with multiple new/experimental changes at once (which I agree makes troubleshooting more difficult, it's easier to know where an issue is coming from when you have fewer changes).

A release model with a separate "bleeding edge" branch / distribution channel just doesn't work. People won't actively check it.
The only worthwhile cases are when you're working on big features / changes that  :
- generate enough interest, sustaining a somewhat active "beta-tester" group that actively provide feedback
- are backward-compatibility breaking changes, or just in-progress, unstable features

I indeed think your current release model isn't very nice for the users, especially since Kopernicus is a middleware mod.
Many people grab whatever current release is available at the moment and never update it.
You are viewing changes and issues from your own hyper-aware lens, but most people experiencing bugs won't even know they are coming from Kopernicus, they might not even be aware of what the "Kopernicus" mod they have installed is for, since all they consciously installed is a planet pack.
It's also worth noting that Kopernicus went from the most "release locked, extremely risk-adverse, months between updates" mod in the ecosystem to "push not really tested changes every week to mainstream". There is probably a middle-ground.

All this being said, I fully acknowledge that modding is a personal act, that it's perfectly reasonable to do things in the way that is the most convenient for you, and that users are entitled to nothing. Do what works best for you.

[R-T-B]

6 hours ago, Gotmachine said:

It's also worth noting that Kopernicus went from the most "release locked, extremely risk-adverse, months between updates" mod in the ecosystem to "push not really tested changes every week to mainstream". There is probably a middle-ground.

To my credit (or lack thereof, you decide), a lot of this had to do with "learning the ropes."  To some extent even that is still going on.  But yes I agree there is a middle ground.

I won't be able to do a release for at least another week or two, so the current release can be considered "stable" on that alone.  But I do think weekly stable releases with a opt-in branch for prereleases in between is the way to go going forward.

I talked with the CKAN folks and they said we can do this through the old bleeding edge opt-in system rather simply, far easier than I was thinking, so I'll probably just use that.

I'll update you all when that time comes.

In the interim, feel free to comment on any features or ideas you'd like to see.  One thing I've wanted to look into but looks almost terrifyingly hard is below and above sea level water bodies.  We had that feature once, but it was buggy.  Maybe we should revisit it?

More realistically, proper comet support should probably be looked at, despite my last run-in with the the things.  I'm much better prepped now, I hope.

Feedback welcome, as always.

Edited March 18, 2023 by R-T-B

[Krazy1]

Hi @R-T-B From discussion on JNSQ... with JNSQ_high setting and 100% scatter density, I don't see any scatters on Minmus but I do see a few with "high" setting, <10 even on 100% density setting. The BG ROCs are working now with both JNSQ_high and high settings. 

Also seeing some texture issues on Minmus with either setting... looks like z-fighting. 

Logs (JNSQ_high and 100% density)

KSP log

player log

settings

[R-T-B]

5 minutes ago, Krazy1 said:

Hi @R-T-B From discussion on JNSQ... with JNSQ_high setting and 100% scatter density, I don't see any scatters on Minmus but I do see a few with "high" setting, <10 even on 100% density setting. The BG ROCs are working now with both JNSQ_high and high settings. 

Also seeing some texture issues on Minmus with either setting... looks like z-fighting. 

Logs (JNSQ_high and 100% density)

KSP log

player log

settings

Thanks. I'll investigate this and see about it for next patch if it's a bug, or offer a solution if it's some sort of config issue.  Will update.

[R-T-B]

On 2/9/2021 at 5:19 PM, SpacedInvader said:

I'm running into a serious issue with Kopernicus and I've got no idea how to fix it. Things were working fine until last night, running the most recent stable version of Kopernicus on KSP 1.11.1. Then after an 8 hour session the game crashed... hard... I got some blank error messages with progress bars that did nothing except show that they were from Unity and one notification that there had been an overflow of some type before finally forcing me to alt-f4 / end processes to get rid of the messages. Anyway, ever since then, whenever I try to load a save from within the game, this is what I'm presented with:

  Reveal hidden contents

  Reveal hidden contents

The first image where KSC is underground is what always happens on the first reload, the second is usually what happens if I try to reload a second time, though sometimes the terrain is so low that you can see water below the floating space center.

Anyway, these are from a bare bones install with just Kopernicus, ModularFlightIntegrator, and Module Manager and KSP installed. I've tried reinstalling all of them, including KSP more than once, always with the same result. Additionally, I get the same results if I try to roll back Kopernicus and MFI to the bleeding edge version I'd been using before the stable release. That all said, whats more interesting / frustrating about this is that it doesn't seem to be restricted to my main KSP install, but instead it affects all KSP installs on my system, even a completely fresh install made after all of this started with freshly downloaded KSP and Kopernicus archives. And that's where I'm fresh out of ideas on how to fix this... I'm not familiar with anything other than logs that KSP stores outside of its home directory and I don't know of anything at all that Kopernicus might store elsewhere that could have become corrupted, so I'm really hoping someone who knows more about the way Kopernicus / KSP works can help me sort out what might be going wrong here because its preventing me from playing my main save as I'm both afraid it could further corrupt if I try to press forward and the mission I was about to launch was a rover to drive around KSC...

Logs

Kopernicus Generated Logs

EDIT: Just to be clear, I only get these results when Kopernicus is installed

Unfortunately I no longer offer support for 1.11.x.  But since it is so obsolete, and you are encountering issues that honestly, are most likely fixed in latest, I will offer you a trick that might work for loading the latest 1.12.x release on 1.11/10/9.x. (this won't work on 1.8.x).

Download latest Kopernicus zip from here for 1.12.x:

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

Install as per usual, manually.

Replace the "GameData/Kopernicus/shaders" folder with the same folder from the last supported 1.11.x release.

You may find it will run and possibly fix your bug.

Beyond that, you are sadly in unsupported territory nowadays.

EDIT:  You've deleted your post but leaving this up in case it is useful.  Bear in mind this "trick" is completely unsupported.

Edited March 19, 2023 by R-T-B

[R-T-B]

48 minutes ago, Krazy1 said:

Hi @R-T-B From discussion on JNSQ... with JNSQ_high setting and 100% scatter density, I don't see any scatters on Minmus but I do see a few with "high" setting, <10 even on 100% density setting. The BG ROCs are working now with both JNSQ_high and high settings. 

Also seeing some texture issues on Minmus with either setting... looks like z-fighting. 

Logs (JNSQ_high and 100% density)

KSP log

player log

settings

@Krazy1, I am seeing the same behavior on Minmus when I test.  Was it ever very different?  Less than 10 rocks (seems to be the only scatter) there even on high densities.  What I'm asking is is it possible this is by design, or did something actually break?

I don't see the z-fighting behaviour but I have heard reports of it before...  usually on old saves.  Not sure what causes it.

EDIT:  Wait, it's possible what I'm seeing are BG ROCs, they look rather similar, stand by while I sort that out.

Edited March 19, 2023 by R-T-B

[R-T-B]

I think what we are dealing with is either a config issue with Minmus, or artistic choice on the devs part of JNSQ.  I am finding behavior the same across release-157 (before these changes) and the modern release, @Krazy1.  If you'd like advice on how to make more scatters on Minmus given their config, I can certainly help with that, of course.

I will admit it does seem so sparse as to be an error.  Even I think it does appear odd, but it almost seems intentional and I don't see a behavioral change here.  It may be they designed this pack when scatters cost a ton of performance to implement.

To be completely transparent, with ROCs off, this is what I am seeing with 100% scatter density.  Identical in both release-157 and 165.

Edited March 19, 2023 by R-T-B

[Krazy1]

Thanks @R-T-B <10 objects with the "high" setting may be normal, I'm new to JNSQ so not sure. What seems broken is the "JNSQ_high" setting, where I don't see any scatter at all on Minmus. I'm not seeing much other difference so far between "high" and "JNSQ_high" so I think I'll just use "high" for now. I assumed the terrain detail setting and scatter settings are totally independent but it seems not.

The z-fighting (maybe that's not the right description) is some color banding on the terrain that changes as the camera moves. Relatively close distance maybe <100m. It's not terrible but noticeable. I'll get a video if it keeps bugging me. Thanks.

[R-T-B]

2 hours ago, Krazy1 said:

Thanks @R-T-B <10 objects with the "high" setting may be normal, I'm new to JNSQ so not sure. What seems broken is the "JNSQ_high" setting, where I don't see any scatter at all on Minmus. I'm not seeing much other difference so far between "high" and "JNSQ_high" so I think I'll just use "high" for now. I assumed the terrain detail setting and scatter settings are totally independent but it seems not.

The z-fighting (maybe that's not the right description) is some color banding on the terrain that changes as the camera moves. Relatively close distance maybe <100m. It's not terrible but noticeable. I'll get a video if it keeps bugging me. Thanks.

I'd use JNSQ_High as the custom bodies may need it.  You aren't getting any scatters on JNSQ_High though?  That doesn't sound right, the above screenshot was taken in JNSQ_High preset.  Hmmm....

Would it be possible for you to post screenshots of the difference between High and JNSQ_High?  Remember to completely quit the game between changes, BTW.

Edited March 19, 2023 by R-T-B

[Krazy1]

7 hours ago, R-T-B said:

You aren't getting any scatters on JNSQ_High though? 

OK... now I am seeing them. I guess I only went back to the main menu to change the setting without restarting KSP? There's a vague warning about that - it should say you MUST restart KSP. So I do see the Minmus scatters and there are at least 100 of them at 100% density setting. It's interesting that the colliders are enabled - they're vapor in stock. And the BG ROCs are there too- only see 4 of those but I guess that's normal. So all good for scatter. 

However, the texture z-fighting issue is pretty annoying. It's constantly changing even without moving the camera. It does it on Kerbin too. Here's a few screenshots. I'll try some different mod changes tomorrow. I know I'm using the newest Scatterer which isn't officially compatible. 

Spoiler

[R-T-B]

11 hours ago, Krazy1 said:

OK... now I am seeing them. I guess I only went back to the main menu to change the setting without restarting KSP? There's a vague warning about that - it should say you MUST restart KSP. So I do see the Minmus scatters and there are at least 100 of them at 100% density setting. It's interesting that the colliders are enabled - they're vapor in stock. And the BG ROCs are there too- only see 4 of those but I guess that's normal. So all good for scatter. 

However, the texture z-fighting issue is pretty annoying. It's constantly changing even without moving the camera. It does it on Kerbin too. Here's a few screenshots. I'll try some different mod changes tomorrow. I know I'm using the newest Scatterer which isn't officially compatible. 

  Hide contents

Ah, that!  The z-fighting thing is...  I'd describe it as banding.  But yeah I ran into it on Minmus on my last JNSQ playthrough.

Things that may/may not help, I forget which actually worked in practice:

1.) Try the "High" rather than the "Ultra" Shader, or maybe vice-versa, but I think that's right.

2.) If you can afford the perf penalty, maybe try scatterer shadows over the Kopernicus shadow manager (I'm doubtful this is the origin though).

If neither of those work, I'll look into what's going on.

Edited March 20, 2023 by R-T-B

[Krazy1]

14 hours ago, R-T-B said:

Ah, that!  The z-fighting thing is...  I'd describe it as banding

So that is all good now... all I did was install Scatterer V0.0772 (was latest 0.0838) which is officially compatible with JNSQ. I'm still using Kopernicus long distance shadows, which I must say I much prefer because the Scatterer shadow cascades are very abrupt and noticeable on ships and ship shadows on the surface. Kopernicus shadows look like stock... a bit too soft on the edges when viewed close up but it's hard to notice shadow cascades zooming in/ out. 

There's one more thing... KSC is almost completely vanishing sometimes, only at night so far. The buildings are still functional but not visible. Maybe this is KK, but it's just normal stock KSC.

Spoiler

One other thought... getting off topic a bit. It always bothered me how terrain "snaps" between geometry detail levels. It's so unnatural to see a mountain suddenly spasm and morph into a different shape as you approach it in orbit. "the real world is analog" Is there any way to smooth out these geometry steps or at least push them further into the distance? Is it's pretty fundamental in the core code?

[R-T-B]

23 hours ago, Krazy1 said:

Maybe this is KK, but it's just normal stock KSC.

If you have the "ResetFloatingOriginOnKSCReturn" enabled, it can mess with KK.  Disable it if you are experiencing issues and it's on, for some reason (it should be off by default but there was like one release with it on by default that could have toggled it on by accident).

As for this: 

23 hours ago, Krazy1 said:

One other thought... getting off topic a bit. It always bothered me how terrain "snaps" between geometry detail levels. It's so unnatural to see a mountain suddenly spasm and morph into a different shape as you approach it in orbit. "the real world is analog" Is there any way to smooth out these geometry steps or at least push them further into the distance? Is it's pretty fundamental in the core code?

I agree with you that it's visually jarring and kind of annoying, but it's also pretty fundemental to how KSP enables these huge worlds to load.  I have some "far flung" ideas for improving it (far flung because they may just as likely make it worse, only way to find out is to try) but those'll certainly be tried as a beta/prerelease before I make them mainstream, as we discussed above.  No CKAN users need worry this time around, or stable release users for that matter.

For what we have right now?  Parallax helps a bit I feel, with the transition of loading in of fine details.  But there is a performance cost and it does nothing for large objects like mountains, sadly.

EDIT:  Just saw the part about the KSC vanishing at night, IIRC that's an old scatterer setting, something in the GUI turns it off, it's basically setting nights to pitch black like rl but in Kerbal that's pretty harsh for navigating...  well anything.

Edited March 22, 2023 by R-T-B

[R-T-B]

We have a new reported bug I'd like to look into in our new prerelease system (in addition to experimenting with the above at some point):

Original issue was described at KSPCF github here.  The issue was agreed best handled by Kopernicus, and we are now tracking it here.

Could anyone see the last post on the second issue, and try to replicate the issue with the posted config file?  I'm away from my machine for this evening but if someone could confirm/deny if my suspicion that this bug is located in OnDemand by testing the config file I posted, I'd be most thankful.  It'd give me a headstart when I get back.

Edited March 23, 2023 by R-T-B

[Krazy1]

19 hours ago, R-T-B said:

If you have the "ResetFloatingOriginOnKSCReturn" enabled, it can mess with KK.

It was off. 

19 hours ago, R-T-B said:

EDIT:  Just saw the part about the KSC vanishing at night, IIRC that's an old scatterer setting, something in the GUI turns it off, it's basically setting nights to pitch black like rl but in Kerbal that's pretty harsh for navigating...  well anything.

I think you mean "disable scaled space ambient light" I had that off so the stock map ambient light boost works.  This is something else. From the KSC overview, the KSC buildings and runway lights are completely off sometimes but usually they work. Both cases are possible without changing any setting. 

For asteroids, it's set to default True to use Kopernicus system... but should I turn it off to allow JNSQ to handle them? Haven't upgraded my tracking station to see them yet.

Suggestion for the option menu: avoid using negative logic. It can be confusing. Make every option enable something, regardless of what the stock behavior is.  Like this one:

Should I disable disabling? or enable disabling? Disable the input (button) or the output (colliders)? I think I should leave the button enabled for JNSQ. Maybe I could take a stab at editing the UI a little. 

[R-T-B]

On 3/23/2023 at 1:00 AM, Krazy1 said:

For asteroids, it's set to default True to use Kopernicus system... but should I turn it off to allow JNSQ to handle them? Haven't upgraded my tracking station to see them yet.

JNSQ uses Kopernicus generator so leave it on that.

As for this:

On 3/23/2023 at 1:00 AM, Krazy1 said:

Suggestion for the option menu: avoid using negative logic. It can be confusing. Make every option enable something, regardless of what the stock behavior is.  Like this one:

Should I disable disabling? or enable disabling? Disable the input (button) or the output (colliders)? I think I should leave the button enabled for JNSQ. Maybe I could take a stab at editing the UI a little. 

This is a great point and I'll change that next release to remove all those confusing negatives.  Until then, yeah, for JNSQ leave that box checked (DisableFarWayColliders=Checked)

On 3/23/2023 at 1:00 AM, Krazy1 said:

I think you mean "disable scaled space ambient light" I had that off so the stock map ambient light boost works.  This is something else. From the KSC overview, the KSC buildings and runway lights are completely off sometimes but usually they work. Both cases are possible without changing any setting. 

I think this might have been an old scatterer or Kronometer bug or something but I'm not completely certain.  I remember it being a thing once upon a time but the bug wasn't originating in Kopernicus, was my recollection.  I hope that vagueness of a memory helps you some, lol.

Edited March 24, 2023 by R-T-B

[R-T-B]

One of our first prereleases just dropped, basically just some small bugfixes I am testing.  See the changelog here:

https://github.com/Kopernicus/Kopernicus/releases/tag/release-166_RC1

These will be dropped with much less fanfare than full releases, download only if you want a particular fix in them, or want to help test.  You can get them via CKAN by opting into the bleeding edge (instructions at that thread still work).

@Krazy1this release might fix your "time of day" animation issues you noted.

 

EDIT:  More bugfixes for the same bug in this one (this is why they are prereleases):

https://github.com/Kopernicus/Kopernicus/releases/tag/release-166_RC2

Edited March 27, 2023 by R-T-B