[1.12.5] Grannus Expansion Pack [v1.2.8] [10 May 2022]

[OhioBob]

2 hours ago, Spartan125 said:

Solar panels are not generating power and are instead tracking Grannus. This only seemed to happen after switching away from the vessel and I am using GEP with JNSQ and the required configs in 1.8.1.

I have checked previous issues on the Kopernicus Github but there isn't info for situations involving multiple star systems and the only fix is to disable the Kopernicus solar panels config, which I would imagine would stop solar panels from working around Grannus.

There's a bug in the Kopernicus solar panel module for 1.8.1.  I suspect that's probably the source of your problem.  I reported the issue to the Kopernicus devs and they fixed for the next Kopernius release.  No idea when that will be.

JNSQ actually deactivates the Koperniucs solar panel module, but GEP_JNSQ reactivates it.  If you want it deactivated, find and open the file GEP_forJNSQ.cfg.  Scroll all the way to the bottom and delete the following bit:

// ============================================================================
//  Use Kopernicus solar panel module.
// ============================================================================

@PART:HAS[#useKopernicusSolarPanels[*]]:FINAL
{
    !useKopernicusSolarPanels,* = DEL
}

Hopefully that will solve your solar panel issue around the sun, but as you surmise, panels won't work around Grannus.
 

Edited April 23, 2020 by OhioBob

[DeadJohn]

3 hours ago, Spartan125 said:

Solar panels are not generating power and are instead tracking Grannus. This only seemed to happen after switching away from the vessel and I am using GEP with JNSQ and the required configs in 1.8.1.

I have checked previous issues on the Kopernicus Github but there isn't info for situations involving multiple star systems and the only fix is to disable the Kopernicus solar panels config, which I would imagine would stop solar panels from working around Grannus.

1 hour ago, OhioBob said:

Hopefully that will solve your solar panel issue around the sun, but as you surmise, panels won't work around Grannus.

My experience with JNSQ+GEP on 1.8.1 was a little different. I didn't change any configs and thought the solar power worked okay, with only some minor glitches at Grannus.

Moho through Duna: Solar seemed perfect. Panels tracked the sun and gave a reasonable amount of power.

Dres through Nara: I didn't test solar power this far out. I used Near Future RTGs or nuke reactors for the distant JNSQ planets.

Grannus: I sent one ship to Grannus the hard way (100+ year timewarp), then used FTL Continued to teleport more ships. I noticed these glitches:

• At the edge of Grannus' SOI, panels would sometimes track the sun, sometimes Grannus, but generated too much electricity regardless of which body they tracked.
• Closer to Grannus, maybe at Epona or Nodens, solar output seemed better. I still needed to manually select Grannus sometimes but when the JNSQ Sun was being tracked the panels no longer generated too much electricity.

 

[OhioBob]

14 hours ago, DeadJohn said:

My experience with JNSQ+GEP on 1.8.1 was a little different.

My experience was different too, but I don't recall now specifically what it was.  I know I had issues with the panels tracking the wrong star and power output not being what it should be.  Whatever the case, it is definitely bugged.  I tested the fix that the Kopernicus devs came up with and it seemed to rectify all the problems.  So if and when Kopernicus updates, we should be in good shape.

Since @Spartan125's symptoms are a little different than ours, it's possible his problem could be related to something else.  But as long as the bug exists in Kopernicus, we can't diagnose the problem any further.  We must eliminate Kopernicus as a potential source before we can see if something else is at fault.
 

[HansonKerman]

both this, GPP, and IC bookmarked for the computer

[OhioBob]

UPDATE

Version 1.1.5

Changelog

• Upgraded to use shader introduced in KSP v1.8.
• New and improved terrain textures for all celestial bodies.
• Bundled Sigma TweakChutes and HeatShifter.

See opening post for download link and instructions.

This release works only with KSP v1.8.1 and later.  Continue using GEP 1.1.3 for KSP 1.7.3 and earlier.
 

[GEPEG_Unconscious]

Jumping over to this thread to bring up an issue with the new update and what appears to be KS3P.

Spoiler

With GEP 1.1.5 and @clusta's 1.8.1 KS3P setup, the ground appears to have some transparency to it and there is some weird dark shading around the edge of the bottom half of the screen. Had no issue in GEP 1.1.4, and the transparency is only seen when close to the surface.

Same scene with KS3P disabled

 

[OhioBob]

58 minutes ago, GEPEG_Unconscious said:

Jumping over to this thread to bring up an issue with the new update and what appears to be KS3P.

I've never used KS3P so I know nothing about it.

GEP is using the same shader and textures used on the stock bodies.  I just repurposed them and used them on the GEP bodies.  I wonder if the issue you are seeing occurs in stock?

[JadeOfMaar]

@GEPEG_Unconscious The KS3P issue is an effect of how the alpha channel is used differently in body textures supporting the new terrain shaders. You'll have to go to the KS3P config writers or their threads for an answer.

[GEPEG_Unconscious]

Yep, was a KS3P issue. Got it taken care if I believe, Apologies for jumping the gun.

 

[OhioBob]

Here are some screenshots highlighting some of the terrain updates from v1.1.5.

 

Edited May 5, 2020 by OhioBob

[Space Nerd]

12 hours ago, OhioBob said:

Here are some screenshots highlighting some of the terrain updates from v1.1.5.

 

What's this planet/moon?

Didn't remember anything that has an atmosphere this far from grannus. (Except for brovo, which is reddish, unlike the object in the picture.)

[OhioBob]

2 hours ago, Space Nerd said:

What's this planet/moon?

Epona - first planet past the gas giant Sirona.

[Drupegod02]

Does Sirona have solid ground?

[OhioBob]

1 minute ago, Drupegod02 said:

Does Sirona have solid ground?

No it doesn't.  It's a gas giant.

[OhioBob]

Grannus Expansion Pack appears to be working OK with Kopernicus Continued, a fork of the original Kopernicus recompiled for KSP 1.9.1.  If anyone discovers problems, please report them here and I'll try to determine whether the issue is with GEP or Kopernicus.
 

Edited June 23, 2020 by OhioBob

[OhioBob]

UPDATE

Version 1.1.6

Changelog

• Revised asteroids (now more reliable with shorter untracked lifetimes).
• Added Changelog.md.

See opening post for download link and instructions.

[OhioBob]

UPDATE

Version 1.2.0

Changelog

• Added support for Minor Planets Expansion.
• Added Breaking Ground surface features.
• Added anomalies using Kerbal Konstructs for GEP_Primary.
• Enabled Randoliths on all celestial bodies.
• Revised stock asteroids to work better with GEP.
• Updated TweakChutes to work with FAR.
• Fixed some discrepancies between GEP and GEP_Primary.
• Added NEEDS to items specific to Making History.

See opening post for download link and instructions.

 

Minor Planets Expansion is a nice little mod that I recently discovered.  Since GEP already supports the addition of OPM, I thought it would be nice to also support MPE.  However, there are some orbital interferences between GEP and MPE that makes for a poor fit if neither is modified.  This issue has been resolved by editing some of the orbits to make a nice seamless fit.  MPE can be installed with GEP as either a primary or secondary system.  If primary, the MPE bodies (and the OPM bodies if installed) are integrated into the GEP solar system to greatly increase the body count.

Breaking Ground surface features are now a part of GEP.  Most of the surface features found in the stock game have been repurposed and distributed among the GEP celestial bodies.  There are stones, boulders, ice chunks, geysers, and other geological formations waiting for you to discover and sample.  (Applicable to GEP_Primary only starting with v1.2.1.)

Anomalies are now available for GEP_Primary with the installation of Kerbal Konstructs.  There’s no new models here, just repurposing of the stock anomalies, like monoliths, rock arches, etc.  These features have been spread about in far flung places, giving you additional incentive to explorer.  Furthermore, Randoliths, which had been previously removed, are now back and present on all GEP celestial bodies.  While the KK anomalies are a feature of GEP_Primary only, Randoliths are present in both primary and secondary installations.

 

Edited July 6, 2020 by OhioBob

[OhioBob]

UPDATE

Version 1.2.1

Changelog

• Moved Breaking Ground surface features to GEP_Primary only.
• Revised Breaking Ground science definitions.

See opening post for download link and instructions.

 

Regrettably I didn't test the Breaking Ground part of v1.2.0 rigorously enough.  Installing GEP alongside stock KSP caused conflicts between the surface features found on the stock celestial bodies and those on the GEP bodies.  The only way to fix those conflicts was to make compromises I didn't want to make.  Therefore, the Breaking Ground surface features are now a part of GEP_Primary only.  I also forgot to customize the Breaking Ground science definitions for the GEP bodies.  That is now fixed, so the science definitions make much more sense and are planet specific.
 

Edited July 6, 2020 by OhioBob

[OHara]

On 6/22/2020 at 6:55 AM, OhioBob said:

Grannus Expansion Pack appears to be working OK with Kopernicus Continued, a fork of the original Kopernicus recompiled for KSP 1.9.1.  If anyone discovers problems,

There is still a problem with atmospheric temperatures, isn't there ?

For example, with Kopernicus-Continued 1.9.1-5, at the equator on tidally-locked Toutatis the alt-F12 aero-Gui shows a seasonal variation of air temperature from 100K to 440K depending on whether the ground faces Kerbol.   think the temperature variation was intended to be relative to the local star Grannus.

The PanelsFix2 branch of Kopernicus had an off-by-one error in its search for the local star for purposes of heating the atmosphere, failing to find any star, which Kopernicus-Continued-1.9.1-4 avoided by using Kerbol as star the for every atmosphere.  I commented on the GitHub but am confused because this aspect of 1.9.1-4 was reported working on that thread --- maybe it was working in the sense of a stopped clock being correct twice a day. 

I'm not set up to compile and make a pull-request, but if anyone can confirm the problem remains, I can try to set up.  It seems a shame to leave it almost fixed.

[OhioBob]

3 hours ago, OHara said:

There is still a problem with atmospheric temperatures, isn't there ?

For example, with Kopernicus-Continued 1.9.1-5, at the equator on tidally-locked Toutatis the alt-F12 aero-Gui shows a seasonal variation of air temperature from 100K to 440K depending on whether the ground faces Kerbol.   think the temperature variation was intended to be relative to the local star Grannus.

Yep, you're right.  I don't think the problem is Kopernicus, however.  I believe it's Sigma HeatShifter.  Apparently I only ever tested HeatShifter in GEP_Primary mode, in which case it works correctly.  When GEP is secondary, the temperatures align to the Sun.  It's this way in 1.8.1 as well.  The problem has likely always existed and I just never noticed it.  Thanks for bringing it to my attention.  I'll ask @Sigma88 to look into it.

(edit)  The problem is apparently in Kopernicus, not HeatShifter.  Please read ahead.
 

Edited July 20, 2020 by OhioBob

[OHara]

31 minutes ago, OhioBob said:

  I don't think the problem is Kopernicus, however.  I believe it's Sigma HeatShifter. 

I tested, though, with only Kopernicus and GrannusExpansionPack, and saw the atmospheric temperatures follow Kerbol rather than the local star.  (I checked that you did not include HeatShifter's dll your released mod.)

@Sigma88's work in Kopernicus to restore the proper effect of multiple stars had a routine (in pseudocode because the name-mangling of C# makes all of this much less obvious)

localStar(body)
  while  NOT isStar(body)  AND  exists(body.parent)
      body := body.parent
  return body

but his code accidentally tested for isStar(body.parent) so it stopped just short of the localStar, failing to return any star from which to figure atmospheric temperatures.

Current Kopernicus Continued has localStar always return Kerbol, which works on lots of planet packs, but makes the code look rather pointless.  

Edited July 19, 2020 by OHara
localStar() is actually named getBodyReferencing() in KopernicusStar.cs

[OhioBob]

3 minutes ago, OHara said:

I tested, though, with only Kopernicus and GrannusExpansionPack, and saw the atmospheric temperatures follow Kerbol rather than the local star.  (I checked that you did not include HeatShifter's dll your released mod.)

HeatShifter is bundled with GEP.  It's in the GEP_Plugins folder.

[OHara]

Oops. There it is. 

The HeatShifter mod calls the Kopernicus routine GetBodyReferencing()  that contains the code I paraphrased above,
so I still think the problem is in Kopernicus' KopernicusStar.cs

[OhioBob]

You're right, it is a Kopernicus issue.  I removed HeatShifter and the planet temperatures are still aligned with the Sun (though with the 45 degree offset that stock KSP adds, and that HeatShifter removes).  We'll have to make a Kopernicus bug report.

[OHara]

13 minutes ago, OhioBob said:

We'll have to make a Kopernicus bug report.

I added https://github.com/prestja/Kopernicus/issues/19 
but have not set up to compile and test C#, so hope @Sigma88 might still be in position to confirm if this was his original intent, and motivated to make a pull request.