OhioBob Posted April 23, 2020 Author Share Posted April 23, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
DeadJohn Posted April 24, 2020 Share Posted April 24, 2020 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. Quote Link to comment Share on other sites More sharing options...
OhioBob Posted April 24, 2020 Author Share Posted April 24, 2020 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. Quote Link to comment Share on other sites More sharing options...
HansonKerman Posted April 24, 2020 Share Posted April 24, 2020 both this, GPP, and IC bookmarked for the computer Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 4, 2020 Author Share Posted May 4, 2020 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. Quote Link to comment Share on other sites More sharing options...
GEPEG_Unconscious Posted May 4, 2020 Share Posted May 4, 2020 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 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 4, 2020 Author Share Posted May 4, 2020 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? Quote Link to comment Share on other sites More sharing options...
JadeOfMaar Posted May 4, 2020 Share Posted May 4, 2020 @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. Quote Link to comment Share on other sites More sharing options...
GEPEG_Unconscious Posted May 4, 2020 Share Posted May 4, 2020 Yep, was a KS3P issue. Got it taken care if I believe, Apologies for jumping the gun. Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 5, 2020 Author Share Posted May 5, 2020 (edited) Here are some screenshots highlighting some of the terrain updates from v1.1.5. Edited May 5, 2020 by OhioBob Quote Link to comment Share on other sites More sharing options...
Space Nerd Posted May 5, 2020 Share Posted May 5, 2020 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.) Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 5, 2020 Author Share Posted May 5, 2020 2 hours ago, Space Nerd said: What's this planet/moon? Epona - first planet past the gas giant Sirona. Quote Link to comment Share on other sites More sharing options...
Drupegod02 Posted June 14, 2020 Share Posted June 14, 2020 Does Sirona have solid ground? Quote Link to comment Share on other sites More sharing options...
OhioBob Posted June 14, 2020 Author Share Posted June 14, 2020 1 minute ago, Drupegod02 said: Does Sirona have solid ground? No it doesn't. It's a gas giant. Quote Link to comment Share on other sites More sharing options...
OhioBob Posted June 22, 2020 Author Share Posted June 22, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted June 25, 2020 Author Share Posted June 25, 2020 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. Quote Link to comment Share on other sites More sharing options...
OhioBob Posted July 4, 2020 Author Share Posted July 4, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted July 6, 2020 Author Share Posted July 6, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
OHara Posted July 19, 2020 Share Posted July 19, 2020 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. Quote Link to comment Share on other sites More sharing options...
OhioBob Posted July 19, 2020 Author Share Posted July 19, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
OHara Posted July 19, 2020 Share Posted July 19, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted July 19, 2020 Author Share Posted July 19, 2020 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. Quote Link to comment Share on other sites More sharing options...
OHara Posted July 19, 2020 Share Posted July 19, 2020 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 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted July 19, 2020 Author Share Posted July 19, 2020 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. Quote Link to comment Share on other sites More sharing options...
OHara Posted July 20, 2020 Share Posted July 20, 2020 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.