[1.8.1 - 1.9.1] Kopernicus Continued

[R-T-B]

1 hour ago, Souptime said:

Playing with 1.10.1 and works with OPM! i haven't found any glitches yet but i'll keep updated

The biggest known glitch right now is the last dev push had a glitch which has charge rate either way higher, or way lower than reported, depending on how far from Kerbin you are it may or may not be an issue.  It's most noticable at far or near solar orbits.

Anyhow, it's being fixed now.  A hotfix will be out for stable and my bleeding edge in a few minutes here, we are just doing final tests.

EDIT:  Hotfix is done, please see below.  It will drop also in public bleeding edge in a few seconds.

Edited July 30, 2020 by R-T-B

[R-T-B]

Kopernicus 1.9.1-8

R-T-B released this now

This release fixes a few multistar panel tracking bugs. In the previous release, the displayed math was right, but internally, it was incorrectly calculated.

Also, this release is now aware of the home stars luminosity and can do calculations based off of it, in cases it changes from the stock 1360.

You can now use multistar packs without hesitation, even ones that change the main star.

This has been well-tested in the bleeding edge branch before being used here. Download with confidence.

[R-T-B]

Final bit of post spam here, relating to the status of CKAN support, which I know many of you have been waiting for.

CKAN is nearly here.  I know, I've been saying that for a while, but really, it is.  We're at the point where we are fixing old 1.8 bugs and such more often than new ones, frankly.  I'd say the builds in the stable tree at this point are actually more stable and fucntional than the last 1.8.1 release, which was perfectly usable as it stood.  So if you've been waiting to download, we are pretty much there, go ahead.

Still, CKAN is considered our gold standard, hence the delay, but we are down to only one relatively minor issue blocking it's release!  Hopefully, provided no others crop up, that'll be knocked out in the next few days (you can help by testing bleeding edge, it already has a test fix).  Then, following a testing period of a day or so, we'll probably drop it to the CKAN network.  You can keep abreast as to CKAN's status here:

https://github.com/prestja/Kopernicus/issues/29

Thanks for reading, even if you just skimmed the bold bits!  The issue above is also a great way to know a summary of the stable branch's big issues, btw.

Edited July 30, 2020 by R-T-B

[etmoonshade]

Looking forward to this. I just got CKAN working for myself, and I'm surprised at how few mods I needed to manually install - and this was one of them.

[R-T-B]

9 minutes ago, etmoonshade said:

Looking forward to this. I just got CKAN working for myself, and I'm surprised at how few mods I needed to manually install - and this was one of them.

We've really been holding ourselves to a high standard for that, so yeah.  When it gets there it'll be trustworthy for sure.

We possess control of the original CKAN repo that Kopernicus uses, so the release process will be integrated natively and simple.

To be clear though, I'm a code monkey (/frog).  @prestja calls the shots by virtue of being a better project manager, so it's up to him when the lever gets pulled.

Edited July 31, 2020 by R-T-B

[Black-Two-]

This is probably the wrong place to post this, but it's still kind of important so, yeah. Here goes!

What's up with Jool?

There's the discussion on the previous page about how Joolian moons (and moons based on them) seem to be more prone to weird graphical glitches, and now Steven Mading (the guy who maintains kOS) as well as several others (including Matt Lowne through one of his videos) say in the 1.10.1 release thread that maneuver nodes causes the game to crash if the maneuver path goes through the Jool system.

Again, this might be the wrong place for this, but given that the Joolian problems have already been discussed in this thread I hope it's alright. And it could be the case that the maneuver node problem carries over into planet packs with Jool-based bodies, or some other horrible problem, in which case there won't be much rejoicing at all.

[R-T-B]

50 minutes ago, Black-Two- said:

This is probably the wrong place to post this, but it's still kind of important so, yeah. Here goes!

What's up with Jool?

There's the discussion on the previous page about how Joolian moons (and moons based on them) seem to be more prone to weird graphical glitches, and now Steven Mading (the guy who maintains kOS) as well as several others (including Matt Lowne through one of his videos) say in the 1.10.1 release thread that maneuver nodes causes the game to crash if the maneuver path goes through the Jool system.

Again, this might be the wrong place for this, but given that the Joolian problems have already been discussed in this thread I hope it's alright. And it could be the case that the maneuver node problem carries over into planet packs with Jool-based bodies, or some other horrible problem, in which case there won't be much rejoicing at all.

They've been messing with it a lot, so new bugs, is the short vesrion.  Presumably so they could add pretty shaders and cool laythe beaches.

But yeah, it's definitely been above usual buggy, even in stock.  Poor green giant.

Kopernicus works around some of the Jool bugs in a novel way right now (at least, the manuaver node ones, I think).  It doesn't actually template Jool when told to do so, but build a new Jool from scratch with Joolian properties (sans new shader in 1.10).  Wonder if that helps at all.

Sadly the original Jool is still well...  Jool, and buggy as ever.  Wonder if I should rebuild it as well.  We'd lose the new shader in the shortterm, though.

Edited July 31, 2020 by R-T-B

[R-T-B]

We are presently advising stable branch users to revert to release 6, and just not use multistar packs if you care about proper ECs.  Release 7 and 8 have been officially pulled due to outrageously wrong EC production.  The bleeding edge branch will be testing fixes for multistar further, if that interests you.  The old releases were just too buggy, and though the ECs displayed were correct, the ECs produced were not.  The fix for this is diffilcult because it is KSP attempting erronously to correct our actually correct math.  I will update when we have it fixed and tested properly, but it may take a few days.  We don't want a repeat of something like this slipping through the cracks to stable.

Edited August 1, 2020 by R-T-B

[Shawn Kerman]

question, can Multistar be dumped entirely or moved to a separate branch?, Most people these days use stock system with planet packs and system replacers, and IC failed awhile ago.

Edited August 1, 2020 by Shawn Kerman

[R-T-B]

1 minute ago, Shawn Kerman said:

question, can Multistar be dumped entirely or moved to a separate branch?, Most people these days use stock system with planet packs and system replacers, and IC failed awhile ago.

That's what we are doing for right now.  Stable won't get multistar until it's proven in bleeding edge, where I'll be testing it, but this stable build will exclude it for now.

If anyone wants a multistar-free bleeding edge version that is mostly reliable for 1.10.1 support, Release 6 is for you.  It does not do multistar at all, locks light to one star, but works fine and mostly bug free:

https://github.com/R-T-B/Kopernicus/releases/tag/UBE-release-6

[kubi]

9 hours ago, R-T-B said:

We are presently advising stable branch users to revert to release 6, and just not use multistar packs if you care about proper ECs.  Release 7 and 8 have been officially pulled due to outrageously wrong EC production.

Thanks!

I assume that the above is only for the stable branch users as BE seems to be faulty both on rel6 and rel8, but differently

In rel8 at the display info is correct, but the charging rate it totally off. In rel6 both are incorrect.

 

KopernicusBE_1101_Release8.zip with Kerbol Origins 0.4.9 and Snarkiverse 1.2

No multiple stars, Kerbin orbit and the Sun are unchanged.

Launched a tiny probe to Kerbin orbit with two OX-STAT solar panels (opposite side of the craft):

#1 Sun exposure 1.00, Energy flow 0.358, Direct sunlight, Tracking body: The Sun (auto).

#2 Sun exposure 0.00, Energy flow 0.000, Blocked by Probodobodyne OKTO, Tracking body: The Sun (auto).

On the resources panel the Electric Charge shows -1.26 charging rate.

Full light: 1.00 / 0.358 / -1.26

Half light (30deg) 0.50 / 0.178 / -0.62.

The only consumer is the OKTO (1.20 / min = 0.02/sec).

-----------------------------------

KopernicusBE_1101_Release6.zip with Kerbol Origins 0.4.9 and Snarkiverse 1.2

No multiple stars, Kerbin orbit and the Sun are unchanged.

Full light: 1.00 / 0.428 / -0.84

Half light (30 deg): 0.5 / 0.212 / -0.41

**** Numbers might be off due to sunlight in the room

 

More detailed google spreadsheet with hopefully correct numbers:

https://docs.google.com/spreadsheets/d/1DWq3RpRZXtFjIuFRLOAmozwTNdtcuutAPAD-nxmaFdc/edit?usp=sharing

 

 

Edited August 1, 2020 by kubi

[R-T-B]

Yes, the bleeding edge is awaiting a set of fixes that will probably come tomorrow, as it's EC is ever worse off than here.  There is pretty much a total overhaul needed of the EC system there.  I don't think there is a release there right now with EC working for 1.10.1. 

It will be a good place to test them though, and it won't be long, promise.

Edited August 1, 2020 by R-T-B

[SynX]

I installed Kop for 1.8.1, and the planet packs, putting them under the GameData directory like any other mods. However, neither of these planet packs I expect shows up. Is there any dependencies for Kopernicus?

[hemeac]

51 minutes ago, SynX said:

I installed Kop for 1.8.1, and the planet packs, putting them under the GameData directory like any other mods. However, neither of these planet packs I expect shows up. Is there any dependencies for Kopernicus?

What version of KSP are you using? The version of Kopernicus needs to match the version of KSP you are using.

[OhioBob]

6 hours ago, SynX said:

Is there any dependencies for Kopernicus?

Yes, but they're included in the Kopernicus download.  Make sure you have ModularFlightIntegrator and ModuleManager installed.  Also make sure the version number is correct.  If you're using Kopernicus 1.8.1-1, then you should be playing on KSP 1.8.1.

[OhioBob]

I have to report another multi-star issue.  In ScaledVersion it is possible to use either a Gradient or rimColorRamp to add an atmospheric glow around the rim of a planet.  When a planet orbits a secondary star, the rim glow points in the direction of the Sun (Kerbol) rather than the brighter nearby star that it orbits.

Below is a screenshot illustrating this problem.  This is a planet from GEP that orbits the secondary star Grannus.  You can see that the planet is lit from above from the direction of nearby Grannus.  However, the rimColorRamp (the blue glow around the edge of the planet) is pointed to the right in the direction of Kerbol.  The rimColorRamp should point in the direction of the brightest light source, which in this case is Grannus in the upward direction.

I've tested this in multiple versions and the result has been the same in each case - 1.8.1-1, 1.9.1-8, 1.10.1-8 and 1.10.1-9.  Although the example in the screenshot uses a rimColorRamp, the problem is the same when using a Gradient.  The issue also occurs with both planets and moons.

 

 

Edited August 4, 2020 by OhioBob

[prestja]

14 minutes ago, OhioBob said:

I have to report another multi-star issue.  In ScaledVersion it is possible to use either a Gradient or rimColorRamp to add an atmospheric glow around the rim of a planet.  When a planet orbits a secondary star, the rim glow points in the direction of the Sun (Kerbol) rather than the brighter nearby star that it orbits

Just to make sure I'm understanding this correctly, I've labeled the two sources of lighting. If the atmospheric glow effect was working properly, the blue rim would cover the northern hemisphere in the same direction as the Grannus label.

[OhioBob]

53 minutes ago, prestja said:

Just to make sure I'm understanding this correctly, I've labeled the two sources of lighting. If the atmospheric glow effect was working properly, the blue rim would cover the northern hemisphere in the same direction as the Grannus label.

That's correct.

The rim glow should probably be pointed in the direction of the brightest light source, as determined by ScaledIntensityCurve.  ScaledIntensityCurve is a float curve defines how light intensity varies with distance.  If a celestial body is X distance from star A and its ScaledIntensityCurve returns a value of 0.8, and Y distance from star B and its ScaledIntensityCurve returns a value of 0.1, then the rim glow should point to star A in this case.

If ScaledIntensityCurve isn't used (unlikely for a multi-star system), then it should probably point to the star with the greatest scaledSunlightIntensity.  ScaledIntensityCurve and scaledSunlightIntensity are either/or.  One is a curve and the other is a static value (no change with distance).

FYI, Kerbol is actually almost due right.  It just looks bottom-right because there's more contrast between the blue and the darker planet in that direction.
 

Edited August 4, 2020 by OhioBob

[prestja]

5 minutes ago, OhioBob said:

That's correct.

The rim glow should probably be pointed in the direction of the brightest light source, as determined by ScaledIntensityCurve.  ScaledIntensityCurve is a float curve defines how light intensity varies with distance.  If a celestial body is X distance from star A and its ScaledIntensityCurve returns a value of 0.8, and Y distance from star B and its ScaledIntensityCurve returns a value of 0.1, then the rim glow should point to star A in this case.

If ScaledIntensityCurve isn't used (unlikely for a multi-star system), then it should probably point to the star with the greatest scaledSunlightIntensity.  ScaledIntensityCurve and scaledSunlightIntensity are either/or.  One is a curve and the other is a static value (no change with distance).

Thank you for the thorough bug reports as always. I've opened an issue on GitHub and will be taking a look shortly.

[Shawn Kerman]

Looking into kittopia tech for 1.10.1

It dosen't work, neither a recompile for 1.10.1 or the 1.8.1 release. 

I don't have the error for the recompile but for the release it is.

Exception: The shader 'Terrain/Gas Giant' is not supported.
	Kopernicus.Configuration.ScaledVersionLoader.get_Type () (at <a92cb4ee9de24bdeb38bb496b181e688>:0)
	Kopernicus.Configuration.ScaledVersionLoader..ctor (CelestialBody body) (at <a92cb4ee9de24bdeb38bb496b181e688>:0)
	Kopernicus.Configuration.Body..ctor (CelestialBody celestialBody) (at <a92cb4ee9de24bdeb38bb496b181e688>:0)
	KittopiaTech.UI.PlanetSelector.Init () (at <1d0325712f294fedb9f563bd3aec4d38>:0)
	KittopiaTech.KittopiaTech.Update () (at <1d0325712f294fedb9f563bd3aec4d38>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

when ever you try to open up the UI that happens, the game doesn't crash and the error isn't spammed.

Edited August 4, 2020 by Shawn Kerman

[OhioBob]

23 minutes ago, Shawn Kerman said:

Looking into kittopia tech for 1.10.1

It dosen't work, neither a recompile for 1.10.1 or the 1.8.1 release. 

I haven't been able to get KittopiaTech to work since 1.8.1.  The UI opens in later versions, but I can't seem to be able to apply any changes.

[prestja]

1 hour ago, OhioBob said:

I haven't been able to get KittopiaTech to work since 1.8.1.  The UI opens in later versions, but I can't seem to be able to apply any changes.

I've been able to with simple recompiles. What planet packs, if any, are you folks using @OhioBob @Shawn Kerman

[R-T-B]

3 hours ago, prestja said:

I've been able to with simple recompiles. What planet packs, if any, are you folks using @OhioBob @Shawn Kerman

It's most likely the gas giant re-templating code misbehaving in Kittopiatech's case.  I'll need to look at the errors later to properly support that.

In the meantime, a very early release of Prestja's branch might work (try like release 1).

[OhioBob]

4 hours ago, prestja said:

I've been able to with simple recompiles. What planet packs, if any, are you folks using @OhioBob @Shawn Kerman

I've probably tried it with all the planet packs I've been a part of - GPP, GEP, JNSQ and Tidally Locked Kerbin.  I pretty much gave up on Kittopia months ago after I couldn't get it to work.  Though just a few days ago I decided to give it another try and it still didn't work.  I have no ability to recompile, so I've been using v1.8.1-1, which is the last official release.

[Shawn Kerman]

5 hours ago, prestja said:

I've been able to with simple recompiles. What planet packs, if any, are you folks using @OhioBob @Shawn Kerman

For 1.10.1? pure stock, kittopia won't accept the gas gaint shader. my compile might not have have been the best as I updated all of kittopia's 'packages' to 1.10.1. and the release IS dated...