[1.12.x] Kopernicus Stable branch (Last Updated December 21st, 2024)

[R-T-B]

I think the new "collider fix" deserves some explanation.

It's to address the somewhat well known "sinking terrain bug" where at distant worlds, stuff gets weird and kerbals get eaten by the ground, as well as craft landing gear. 

The bug itself is actually a Unity bug, where raycasts fail when the scene gets too big.  It effects anything pretty much past stock Eeloo in game distances (this may be why Squad never added more worlds beyond that point, dunno).

It was introduced between 1.7 and 1.8 with the big Unity upgrade then.

The "fix" disables all colliders on bodies beyond that "stock eeloo" range from your vessel to restore sanity to the scene and attempt to avoid interstellar bugs altogether.  Unfortunately, that's around ~0.6-0.7 AU's in actual distance, so not very far.  This means things using raycasts beyond that distance will fail to detect the bodies out there.  Also, to track the collider states and restore them, there is a small but not undetectable performance penalty.

That's the bad part.  The good part is as far as I can tell, not many stock systems use raycasts at all, and certainly not that far out.  Commnet doesn't, so occulusion of satellites still works.  Solar EC math doesn't, neither in Kopernicus nor stock.  Some mods might, that's the rub.  So the fix is off by default for mod compatibility.  But I do encourage people to try turning it on now and testing it with larger systems.  It should be mostly safe, and even if a mod breaks with it, it should not do so in a DEADLY way.  Plus we need to know what works and what doesn't.

Because short of making a Kopernicus build for 1.7.3 (something I REALLY don't want to do), this is the best answer we have thus far.

Next release is a pretty neat feature update btw, it will feature an in-game settings GUI on the toolbar to tweak Kopernicus_Config.cfg and edit the settings file in game, live.  Hopefully that will help people test features like this in the future.

Edited June 21, 2022 by R-T-B

[Rakete]

@R-T-B Can you tell, when Kopernicus reaches a semi-stable status, when it makes sense to upgrade to this version for some one, two or three weeks? Somehow I don't know if it makes sense for me a simple user to pick every version increment (which is really appreciated, don't get me wrong! I like your fast-paced dev speed!) 

 

Which version is the current go-to-version that simply works stable with some old mod like OPM or so? 

Maybe a sticker to the releases, that it's a release for the end user and not a release for modders to try something out, would be fantastic.

Edited June 21, 2022 by Rakete

[R-T-B]

38 minutes ago, Rakete said:

@R-T-B Can you tell, when Kopernicus reaches a semi-stable status, when it makes sense to upgrade to this version for some one, two or three weeks? Somehow I don't know if it makes sense for me a simple user to pick every version increment (which is really appreciated, don't get me wrong! I like your fast-paced dev speed!) 

 

Which version is the current go-to-version that simply works stable with some old mod like OPM or so? 

Maybe a sticker to the releases, that it's a release for the end user and not a release for modders to try something out, would be fantastic.

I'd say right now you can upgrade to any release.  It's pretty stable.

Most of the time, that'll be the case.  I know there were some "bumps" in the road recently.  Basically, the idea is, you don't have to upgrade unless you have a bug that is fixed or a feature you want is present.  You can stick with a version for a long time and unless something looks or acts wrong, you are fine.

There were some exceptions to that recently, but as you may have noticed, I've slowed down my dev pace a bit since the past 2 days or so...  lol.  From now on, new releases will be in the "bleeding edge" beta branch if they implement something that hasn't underwent at least 2 days of testing.

Speaking of which, something just has.  There may be a release today featuring an ingame settings GUI.  Nothing you can't live without, but you may want to have it, up to you.  But to answer your question:   Release-130 is likely to be the last release for a little bit, and quite stable.  It will be out within the hour.

EDIT:  Here it is!

Kopernicus release-130

New in this latest version release-130:

1.) A ingame GUI has been added to the toolbar to edit Kopernicus_Config.cfg. Not all settings are live, but nearly all take effect with a scene switch. Very handy! Feel free to explore the settings... if you ever mess it up, you can just delete GameData/Kopernicus/Config/Kopernicus_config.cfg to start over.

Known Bugs:

1.) Not exactly a bug, but worth mentioning: The Kopernicus_Config.cfg file is rewritten when the game exits. This means any 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.

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.

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.

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.) 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-119, LandControl createColors is no longer obeyed, it is forced on to avoid another bug. Very few mods to my knowledge use this parameter, but I am open to being proven wrong. You can work around this if affected by setting your LandControl color to be all zeroes.

5.) The "collider fix" as it's called, which fixes the event in which you sink into the terrain on distant bodies, is off by default. If you have a system larger than stock, please see Kopernicus_Config.cfg option DisableFarAwayColliders, read about the fix/workaround, and set it as you feel appropriate.

Edited June 21, 2022 by R-T-B

[Rakete]

How hard does enabling the collider fix hit the performance, as you write in UI ? Which side effects are to be expected?

[R-T-B]

3 hours ago, Rakete said:

How hard does enabling the collider fix hit the performance, as you write in UI ? Which side effects are to be expected?

The performance hit is minor, probably in the range of 1-10 FPS depending on hardware, usually less than 5.  It is caused by having to keep track of the disabled collider states, which adds some minor overhead. 

The side effects would be with other mods using raycasts to far away bodies (they would not "see" them)  I can't say for sure what that means as I have not tested every mod scenario, but logically it should not effect much as the most distant worlds aren't usually very relevant to your vessel/game scene.  I would expect things like telescope mods, etc to be the most likely place to hit an issue, if anywhere.  In that case they may say, fail to realize you have targeted a body more distant than stock Eeloo.

tl;dr: It's a pretty low performance penalty, probably works fine with most everything but I can't promise EVERYTHING without further testing.  For those reasons its off by default, but I do not expect many issues with it really.

Edited June 22, 2022 by R-T-B

[Rakete]

6 hours ago, R-T-B said:

  For those reasons its off by default, but I do not expect many issues with it real

Okay... what happens, if I land on... lets say one of the OPM's outer planet without it enabled (feature off by default)? What will happen? Will the planets be unplayable, or frustrating due to often happening sinking into the ground?

 

When do the fps drops with activated feature kick in? Only when I am near the SOI of such distant planets or does the whole game take a hit (e.g. even when launching stuff from kerbin? This is usually the part where low FPS are the most annoying due to the highest part counts upon launch) Haven't got any telescope mods installed (except from spacedust, but this is a completely different thing).

 

As for the CPU. I'm using a i7 9700K... should I worry? (Think, it's just a cpu-thing performancewise, right?)

Edited June 22, 2022 by Rakete

[modus]

I really shouldn't worry too much, @Rakete. It think it will definitely be playable.

I've encountered the sinking bug (a long time ago, before there even was a fix) and I mostly thought it was weird. And now that there is a fix, I really don't see why you wouldn't use it.

My CPU is worse than yours, and I'm not worried at all.

[R-T-B]

10 hours ago, Rakete said:

Will the planets be unplayable, or frustrating due to often happening sinking into the ground?

Depending on it's orientation to the other planets and how the scene is set up, you may experience one of three things: 1.) Nothing at all, 2.) Mild sinking affecting only landing gear or 3.) major sinking that affects both landing gears and kills kerbals.

I'd advise the fix on in your instance. 

10 hours ago, Rakete said:

When do the fps drops with activated feature kick in?

Anytime in flight scene.

10 hours ago, Rakete said:

As for the CPU. I'm using a i7 9700K... should I worry? (Think, it's just a cpu-thing performancewise, right?)

You probably won't even notice it.

[Rakete]

4 hours ago, R-T-B said:

1.) Nothing at all, 2.) Mild sinking affecting only landing gear or 3.) major sinking that affects both landing gears and kills kerbals

Heheee, so all planets beyond Eeloo's orbit are made of pudding. Delicious! 

Will try the new Kopernicus version with fix, as soon as I am back on my PC to play KSP.

[R-T-B]

4 hours ago, Rakete said:

Heheee, so all planets beyond Eeloo's orbit are made of pudding. Delicious! 

Will try the new Kopernicus version with fix, as soon as I am back on my PC to play KSP.

I always knew Lindor was suspicious... (from JNSQ)

Either way, you picked a great build to start a game on, as release-130 is likely to be the last stable branch build for a few weeks if not months.  After discussion on discord, the roadmap for the Summer with regards to Kopernicus has been decided!  I thought I'd share that with you all here.  Here is the final roadmap agreed upon as posted in discord:

Quote

FYI my direction with Kopernicus is now as follows roadmap wise:
[3:29 PM]
I plan on first experimenting with the old Buoyancy ocean height map idea in the Bleeding Edge.  We can test things there without affecting the main user base
[3:29 PM]
then, the next step is actually not Kopernicus but a major rework of the KittopiaTech tool
[3:30 PM]
I want to make it have a few more functions (adding a body in game, better ability to export) as well as more importantly, fixing some bugs
[3:31 PM]
I picture between those two things, we probably will have absorbed most of the summer.  Those are not light duty tasks, either of them.  But it'll be interesting

To clarify on the "Buoyancy ocean height map idea," this is an old section of code from long ago that worked, but never quite worked RIGHT, that allowed for non 0 altitidue lakes and bodies of water.  It also allowed PQSMods to be applied to oceans, something that could be very cool!  (Whirlpools anyone?)  We want to revisit that idea.  The main bug was splashdown not working right, but we can look at it again, as I'm pretty sure that's fixable.  At least the idea of non-zero altitude lakes and bodies of water would be very cool!

The KittopiaTech part is self explanatory.  Planet pack authors have long complained the tool is lacking, and I will be spending some time on it.

After those things are done, I'll probably begrudgingly admit comets need help, and implement them.

All this will be done in the old "Bleeding Edge" branch first and foremost (which is finally being reactivated, and only migrated to stable once it has been well tested there.  I don't advise players to test that branch with important save games, but, that's not to say the code there is COMPLETELY UNTESTED.  It does generally get a small amount of playtest...  but not enough to ensure stablilty like the stable branch you have here.  So caveat emptor and all that, but testers are still always welcome.

I expect the above to absorb most of the Summertime.  But the benefits will be real and tangible for all users.  Hope this helps you understand where Kopernicus is heading, and thanks for reading!

Edited June 23, 2022 by R-T-B

[Rodger]

10 minutes ago, R-T-B said:

After those things are done, I'll probably begrudgingly admit comets need help, and implement them.

And there was much rejoicing! (at least from me lol)

[R-T-B]

Kopernicus release-131

New in this latest version release-131:

1.) Improvements to the PQS flicker fix.

2.) Removed the JNSQ-specific workarounds (they have a official release fixing the issue). Please ensure you grab their fix from the thread if playing JNSQ (or any mod with color issues). https://forum.kerbalspaceprogram.com/index.php?/topic/184880-1121-jnsq-0100-23-sept-2021/&do=findComment&comment=4148035

3.) Prevented the experimental "disableCollider" fix from automatically turning on in some situations.

Known Bugs:

1.) Not exactly a bug, but worth mentioning: The Kopernicus_Config.cfg file is rewritten when the game exits. This means any 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.

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.

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.

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.) 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-119, LandControl createColors is no longer obeyed, it is forced on to avoid another bug. Very few mods to my knowledge use this parameter, but I am open to being proven wrong. You can work around this if affected by setting your LandControl color to be all zeroes.

5.) The "collider fix" as it's called, which fixes the event in which you sink into the terrain on distant bodies, is off by default. If you have a system larger than stock, please see Kopernicus_Config.cfg option DisableFarAwayColliders, read about the fix/workaround, and set it as you feel appropriate.

Edited June 24, 2022 by R-T-B

[Rakete]

a very humble proposal: How about only offering the Kopernicus setuo toolbar, when in KSC-external view (like E.V.E. Redux does - it does not show it's toolbar in Flight scene or VAB/SPH.). This way Kopernicus doesn't clutter the toolbar area in Flightscene or VAB/SPH, where many other Toolbars kick in.

 

In my ideal thinking, in KSC-view you get to see the toolbars for visual-stuff, in VAB/SPH those relevant for construction (e.g. Nertea's Systemheat), and in Flight you get to see the toolbars for flight (e.g. Trajectories).

[modus]

Doesn't bother me at all. Even saw the button on the main menu after closing my save. Kopernicus be everywhere yo.

But I get what you're saying about the different buttons for different scenes, makes sense. 

Edited June 24, 2022 by modus

[Rakete]

Especially If you have a while multitude of mods installed, the toolbar area gets really really full. And there are toolbars, that you regularly use (e.g. trajectories for setting up for a prograde or retrograde entry) and those, you never use after setting up... e.g. Waterfall's toolbar. e.g. Nertea's Spacedust handles it well. It is only there in map view, where you would use it. 

It would be usefull to have a global mod, that lets you select, which toolbars are shown in which game mode (KSC-View, Map view, Flight scene, Construction) or not at all... There I would deactivate some toolbars, which I never use after being done with configuring a mod. E.g. i never touch E.V.E. toolbar in the KSC view, cause it simply works.

@Gotmachine may be something for a QOL-Tweak for Community Fix pack?!

Edited June 25, 2022 by Rakete

[Gotmachine]

11 minutes ago, Rakete said:

It would be usefull to have a global mod, that lets you select, which toolbars are shown in which game mode (KSC-View, Map view, Flight scene, Construction) or not at all...

Aside from being a bit out of scope for KSPCF, this is something I won't touch as the omnipresent ToolbarController mod is already somewhat taking ownership of the stock toolbar. I suggest you ask for such a feature in that mod instead.

[Rakete]

1 hour ago, Gotmachine said:

Aside from being a bit out of scope for KSPCF, this is something I won't touch as the omnipresent ToolbarController mod is already somewhat taking ownership of the stock toolbar. I suggest you ask for such a feature in that mod instead.

Yeah, it was just a thought. Maybe @linuxgurugamer is interessted in that idea... if not, also alright. It was just a humble idea

[modus]

2 hours ago, Rakete said:

It would be usefull to have a global mod, that lets you select, which toolbars are shown in which game mode (KSC-View, Map view, Flight scene, Construction) or not at all... 

Iirc there is a mod that lets you select which buttons you want to see, but I don't know if it lets you do it in different scenes.

[Aelfhe1m]

21 minutes ago, modus said:

Iirc there is a mod that lets you select which buttons you want to see, but I don't know if it lets you do it in different scenes.

Both The Janitors Closet and Kerbal Adjustable Mod Panel can be used to hide buttons from the Stock toolbar but don't try to use that feature on both of them at the same time.

 

[R-T-B]

I'm open to limiting to to KSC-scene if that is preferable.  Thoughts?  I could do a minor release to stable branch for that.

Edited June 25, 2022 by R-T-B

[Aelfhe1m]

2 minutes ago, R-T-B said:

I'm open to limiting to to KSC-scene if that is preferable.  Thoughts?  I could do a minor release to stable branch for that.

It's probably the only place it's needed but I'm not bothered by it showing up in other scenes.

[G'th]

What would cause a planet's colormap to not be  at the same altitude with the terrain generated by the heightmap? I'm running into this issue where it'll look great at high orbit but as you get lower you can see a "ghost" of the terrain along the horizon and once you cross into being able to see the terrain it clearly shows that the color map was being projected some distance below the actual terrain. 

I hazard a guess its because something in the planets config isn't lining up with the height map, but I don't know that for certain, and there's just, a lot of different settings that look like it could affect this in the config, so I'm not really certain what to go for without just going through one by one and guessing, which doesn't seem like an efficient use of time to be frank.

[Rakete]

Maybe it does not justify a seperate release... but next time you put hands on it, why not? But don't stress yourself.  it was just an idea and not a need-to-have-feature-request 

[linuxgurugamer]

11 hours ago, Rakete said:

It would be usefull to have a global mod, that lets you select, which toolbars are shown in which game mode (KSC-View, Map view, Flight scene, Construction) or not at all... There I would deactivate some toolbars, which I never use after being done with configuring a mod. E.g. i never touch E.V.E. toolbar in the KSC view, cause it simply works.

@Aelfhe1m  @modus FYI,  This is exactly what AMP is doing.

What I may do is add something to Janitor's Closet to NOT manage buttons if AMP is installed.

ToolbarController simply has the ability to put buttons on either the Blizzy toolbar or the Stock toolbar (or both), it doesn't do anything about different scenes.  Blizzy toolbar allows you to define toolbars for each scene

[OhioBob]

3 hours ago, G'th said:

What would cause a planet's colormap to not be  at the same altitude with the terrain generated by the heightmap? I'm running into this issue where it'll look great at high orbit but as you get lower you can see a "ghost" of the terrain along the horizon and once you cross into being able to see the terrain it clearly shows that the color map was being projected some distance below the actual terrain. 

Are you sure it's not just loading an outdated mesh from cache?  If you haven't already done so, delete the .bin files for the planet pack you are running.  These are typically in a cache folder inside the planet pack folder, or if not there, inside the Kopernicus folder.