[1.8.1 - 1.9.1] Kopernicus Continued

[BTAxis]

 

1 hour ago, Morphisor said:

The contract pack was never updated to adjust for it. The fix is easy however, simply change the syntax in the .cfg file as already discussed above.

Yep, got it. Thanks.

Edited August 18, 2020 by BTAxis
Added quote

[R-T-B]

On 8/17/2020 at 11:14 AM, BTAxis said:

One thing I've noticed after installing the latest RC is an issue with the Bases and Stations contract pack for Contract Configurator:

If I remove Kopernicus, that contract works correctly, so it seems to me the problem is on Kopernicus' side.

It's probably our contract scrubber interferring with the code for whatever COntract Configurator is trying to do.  You can fix this by setting UseStockAsteroidGenerator = false in Kopernicus_config.cfg, but then the stock asteroid generator will turn on.  We need a more granular way to turn off the contract scrubber.  I'll add an option and make another hotfix.  I don't consider this a major issue so it should not slow down release much.

EDIT:  Nevermind, you guys figured it out and I need more caffiene.  Yep, it was KopernicusSolarPanels.  A few mods need to be aware of that change, sadly.  I wish we could've handled it better but as of now this is the only way.

On 8/17/2020 at 1:05 PM, ra4nd0m said:

Well. It was an attempt. New issue posted on github. This one is our favorite: gas gaint shadows! It seems that this big boss of bugs is ready for round 2!

Oh...  my.  not again.  Let's take a look.

EDIT:  Actually, that one is an easy fix I think.  I'll get on it in a few minutes.

Edited August 19, 2020 by R-T-B

[R-T-B]

Kopernicus 1.9.1-1 CKAN Release Candidate Hotfix 4

R-T-B released this 13 seconds ago

This release is a CKAN release candidate. It has been well tested in bleeding edge, and barring new bug reports, will probably be on CKAN in a few days.

Besides the base features (listed below), it has the following small bugfixes:

1.) Fix for gas giant shadows-angle regression bug.

2.) Fix for Kopernicus panels failing to completely disable when requested to do so in some instances.

3.) Fixed doubled asteroid spawns when stock generator was enabled (it is by default).

4.) A fix for near future solar support/compatability.

5.) Fixed a texture path bug that caused slightly desaturated gas giants.

That's all, it also has all the old new features, including:

1.) Particle support restored.

2.) All 1.9.1 bugs that are known fixed. Full support for 1.9.1

3.) Multistar support. The math on ECs in single star may be slightly different than stock in some situations, but it should be similar in most and not enough to matter.

4.) Stock asteroid generation enabled for Sentinel contracts (can be shutdown for planetpacks or by user, see below)

5.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable stock asteroid generation. Easy to edit, just look inside!

 

Please replace the entire Kopernicus folder in this version, as it includes a new normal map (you should always do this anyways, and remember to reapply any config customizations).  As this was a simple bugfix, I still see us as being on target for a Wednesday release (yep, that means tomororow!).

Yes, bleeding edge got the same updates.  Look for release 20, in that branch.

Edited August 19, 2020 by R-T-B

[R-T-B]

Kopernicus has been submitted to CKAN.  We are awaiting the bot grabbing it to index it.

Here are the final release notes:

New in this version (1.9.1-1)

1.) Particle support restored.

2.) All 1.9.1 bugs that are known fixed. Full support for 1.9.1

3.) Multistar support. The math on ECs in single star may be slightly different than stock in some situations, but it should be similar in most and not enough to matter.

4.) Stock asteroid generation enabled for SENTINEL contracts (can be shutdown for planetpacks or by user, see below)

5.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable stock asteroid generation. Easy to edit, just look inside!

 

If you want it NOW and not later, you can grab what the bot will eventually index here:

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

Edited August 19, 2020 by R-T-B

[Hpl]

its happening

[R-T-B]

Also, someone tell KopernicusExpansion that they do not work past 1.7, silly people.

Edited August 19, 2020 by R-T-B

[Jognt]

3 hours ago, R-T-B said:

Kopernicus has been submitted to CKAN.  We are awaiting the bot grabbing it to index it.

Here are the final release notes:

New in this version (1.9.1-1)

1.) Particle support restored.

2.) All 1.9.1 bugs that are known fixed. Full support for 1.9.1

3.) Multistar support. The math on ECs in single star may be slightly different than stock in some situations, but it should be similar in most and not enough to matter.

4.) Stock asteroid generation enabled for SENTINEL contracts (can be shutdown for planetpacks or by user, see below)

5.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable stock asteroid generation. Easy to edit, just look inside!

 

If you want it NOW and not later, you can grab what the bot will eventually index here:

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

You guys are rockstars 

[HebaruSan]

3 hours ago, R-T-B said:

Also, someone tell KopernicusExpansion that they do not work past 1.7, silly people.

Oops, compatibility apparently slipped my mind completely in https://github.com/KSP-CKAN/NetKAN/pull/8104. I should probably create a more formal checklist to prevent this sort of thing.

What are the right versions? And is "Kopernicus Expansion Continued-er" ready for prime time?

[R-T-B]

7 hours ago, HebaruSan said:

What are the right versions? And is "Kopernicus Expansion Continued-er" ready for prime time?

It's pretty beta right now.  Only two packages of the whole thing work.  I'd say it's a manual download-grade at this point.

The old one does not work past 1.7.3.

Edited August 20, 2020 by R-T-B

[hemeac]

Congrats on the CKAN release @R-T-B and @prestja! 

[Shawn Kerman]

6 hours ago, R-T-B said:

 

The old one does not work past 1.7.3.

That's debatable, the 1.7.3 Release footprints I know are good for 1.8.1.  Someone made a Regional PQS for 1.8.1 ( I don't know If I can post it their i'll let them decide). !.7.3 Comet tails and Emissive FX are not good for Ckan but they work. and the rest I don't really know the status of.

Edited August 20, 2020 by Shawn Kerman
Added 1.7.3 to Footprints, Comet and FX

[R-T-B]

16 hours ago, Shawn Kerman said:

That's debatable, the footprints I know are good for 1.8.1.  Someone made a Regional PQS for 1.8.1 ( I don't know If I can post it their i'll let them decide). Comet tails and Emissive FX are not good for Ckan but they work. and the rest I don't really know the status of.

That's why I said "the old one" as in, the 1.7.3 release we are discussing that is listed on CKAN.

I know about the recompiles/updates, but that's not what CKAN is indexing.  Sorry for not making myself clear.

EDIT: Oh, the footprints ARE good for 1.8?  Interesting, thanks for letting us know!

 

Edited August 20, 2020 by R-T-B

[R-T-B]

Just an update on Kopernicus teams plans moving forward.

We are currently on the tail end of a three day break (for me at least) following our big release.  After that, we have a big list todo, as always, but 1.10.1 is not at the top of it just yet.  We have decided that that is functioning well enough in bleeding edge to be basically usable (if lacking some customization) and that the most important project going forward is KittopiaTech, which we will attempt to get working properly again.  Planet pack authors really depend on KittopiaTech so it's semibroken/mostly broken state right now is really not ideal.

After that, we may see about one bugfix release for 1.9.1, but that'd be the only release in the CKAN branch if it even happens (depends on whether or not big bugs get reported).  Then, we start work on 1.10.x branch being CKAN-upgraded with full Jool shader and comet control.

So that's our roadmap for probably, oh I'd say the next month.  I have no idea when we'll reach each target within the roadmap, but will update when I start work.  I suspect KittopiaTech is going to be the hardest part though, so it might take a few days or even a week just to get through step one.

EDIT: Each roadmap step bolded for tl;dr types.

For the immediate term, if you know of bugs while using KittopiaTech in 1.9.1 (not 1.10.x that is a separate target), please report them at my github fork here:

https://github.com/R-T-B/KittopiaTech/issues

Edited August 20, 2020 by R-T-B

[KraterKreator]

@prestja I tested Better Duna and no problems found.

[GDorn]

Did a recent change cause solar panels to be retracted on all unloaded ships?  I'm trying to track down why TAC Life Support is suddenly deciding all of my vessels are running out of EC; when I switch to said vessels, their panels are all retracted.

[lordcirth]

3 minutes ago, GDorn said:

Did a recent change cause solar panels to be retracted on all unloaded ships?  I'm trying to track down why TAC Life Support is suddenly deciding all of my vessels are running out of EC; when I switch to said vessels, their panels are all retracted.

Swapping the stock solar panel module for a Kopernicus one could do that, yeah.

[GDorn]

2 hours ago, lordcirth said:

Swapping the stock solar panel module for a Kopernicus one could do that, yeah.

I've been running Kopernicus for many months now; this would be a change between one of the earlier 1.9.1 builds and the most recent one on CKAN.  A bunch of the star flux calculation code touches solar panels, so I wondered if something there shifted enough to reset all panels...

It turns out the solar panels being retracted is a red herring; even when I extend them again, my Kerbals die of air toxicity due to running out of electricity.  I suspect an incompatibility with TACLS's BackgroundResources code and the new changes here regarding the solar panel hacks.

Digging through my log, I see a bunch of this:

[EXC 17:57:46.558] NullReferenceException: Object reference not set to an instance of an object
	BackgroundResources.SolarPanel.ProcessHandler () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	BackgroundResources.UnloadedResources.ProcessInterestedModules (BackgroundResources.InterestedVessel vessel) (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	BackgroundResources.UnloadedResources.FixedUpdate () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
[EXC 17:57:46.581] NullReferenceException: Object reference not set to an instance of an object
	BackgroundResources.SolarPanel.ProcessHandler () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	BackgroundResources.UnloadedResources.ProcessInterestedModules (BackgroundResources.InterestedVessel vessel) (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	BackgroundResources.UnloadedResources.FixedUpdate () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
[EXC 17:57:46.607] NullReferenceException: Object reference not set to an instance of an object
	BackgroundResources.SolarPanel.ProcessHandler () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	BackgroundResources.UnloadedResources.ProcessInterestedModules (BackgroundResources.InterestedVessel vessel) (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	BackgroundResources.UnloadedResources.FixedUpdate () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
[LOG 17:57:46.609] -INFO- Tac.LifeSupportController[FFDFE940][2220.50]: Mun Triple - Electricity is running out!

 

Edited August 21, 2020 by GDorn
Log snippet

[R-T-B]

3 hours ago, GDorn said:

Did a recent change cause solar panels to be retracted on all unloaded ships?  I'm trying to track down why TAC Life Support is suddenly deciding all of my vessels are running out of EC; when I switch to said vessels, their panels are all retracted.

 

3 hours ago, GDorn said:

I've been running Kopernicus for many months now; this would be a change between one of the earlier 1.9.1 builds and the most recent one on CKAN.  A bunch of the star flux calculation code touches solar panels, so I wondered if something there shifted enough to reset all panels...

It turns out the solar panels being retracted is a red herring; even when I extend them again, my Kerbals die of air toxicity due to running out of electricity.  I suspect an incompatibility with TACLS's BackgroundResources code and the new changes here regarding the solar panel hacks.

Digging through my log, I see a bunch of this:

[EXC 17:57:46.558] NullReferenceException: Object reference not set to an instance of an object
	BackgroundResources.SolarPanel.ProcessHandler () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	BackgroundResources.UnloadedResources.ProcessInterestedModules (BackgroundResources.InterestedVessel vessel) (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	BackgroundResources.UnloadedResources.FixedUpdate () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
[EXC 17:57:46.581] NullReferenceException: Object reference not set to an instance of an object
	BackgroundResources.SolarPanel.ProcessHandler () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	BackgroundResources.UnloadedResources.ProcessInterestedModules (BackgroundResources.InterestedVessel vessel) (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	BackgroundResources.UnloadedResources.FixedUpdate () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
[EXC 17:57:46.607] NullReferenceException: Object reference not set to an instance of an object
	BackgroundResources.SolarPanel.ProcessHandler () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	BackgroundResources.UnloadedResources.ProcessInterestedModules (BackgroundResources.InterestedVessel vessel) (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	BackgroundResources.UnloadedResources.FixedUpdate () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
[LOG 17:57:46.609] -INFO- Tac.LifeSupportController[FFDFE940][2220.50]: Mun Triple - Electricity is running out!

 

Yeah, in short this release is going to be hell on some mods that touch the solar panels.  And yes it was changed in the middle of 1.9.1 development, so you could've had an old build without it.  Unfortunately, though we did cause the breakage, we can't fix it in all cases (we shipped modulemanager configs when we could), it's up to mod authors to be aware of our changes if they can't be fixed with a ModuleManager config or something.  We are more than willing to provide advice and code assistance to understanding what's going on of course, but we just can't edit other peoples projects for them.  That'd be unmanageable and also possibly look like plagerism.

The reasoning for this is proper multistar required a full hijakc of the solar panel subsystem, whereas before we used to use a new module called "SolarPanelFixer."  SolarPanelFixer is no more, and KopernicusSolarPanels is now on it's own, handling everything.

There really wasn't another way to override the method we needed, so it had to be done for multistar.  If you are in a single star system, you can always turn off Kopernicus solar panels and likely fix issues like this, with a modulemanager patch, like this in a .cfg file in gamedata.

@PART:HAS[@MODULE[ModuleDeployableSolarPanel]]:FINAL
{
    useKopernicusSolarPanels = False
}

This will turn off Kopernicus multistar panels and revert to stock panel behavior.

PS: If someone could kindly point the author(s) of BackgroundResourceProcessing to this post, it'd probably help them.

Edited August 21, 2020 by R-T-B

[adsii1970]

@R-T-B

Just downloaded your patch shared just a bit ago. I am getting an error message that it's not compatible with 1.10.1.  Here's the error log folder...

https://1drv.ms/u/s!ApHsh39Vt0dQia0Zev19D0g-5teqXg?e=8DsN4P

[TruthfulGnome]

1.10.1 support?

[saxyomega90125]

20 hours ago, R-T-B said:

 

 

There really wasn't another way to override the method we needed, so it had to be done for multistar.  If you are in a single star system, you can always turn off Kopernicus solar panels and likely fix issues like this, with a modulemanager patch, like this in a .cfg file in gamedata.

@PART:HAS[@MODULE[ModuleDeployableSolarPanel]]:FINAL
{
    useKopernicusSolarPanels = False
}

This will turn off Kopernicus multistar panels and revert to stock panel behavior.

PS: If someone could kindly point the author(s) of BackgroundResourceProcessing to this post, it'd probably help them.

Would it not be better to include this, or at least this information, in the main release? IME the majority players who use Kopernicus aren't running multistar, they're just running a planet pack or two i.e. OPM. And having this information here, it's just going to get lost for 90-95% of users as soon as the thread hits page 23.

Seems to me the best choice would be to add in a MM config that only enables Kopernicus solar panels if it detects one of the popular multistar mods. Failing that, if you want multistar support to be the priority, you could include a standalone config in the mod's zip called 'Stock Solar Panels for non-multistar users' with the instructions above at the top of the file and on the front page post. Or for CKAN, maybe even just slap together a parallel release with that config in it.

Any of those options will make it easier for the people who download the mod, and anything you can do to make it easy for them will cut the number of support requests you get dramatically.

Congrats on the 1.9.1 release btw

[hemeac]

2 hours ago, adsii1970 said:

@R-T-B

Just downloaded your patch shared just a bit ago. I am getting an error message that it's not compatible with 1.10.1.  Here's the error log folder...

https://1drv.ms/u/s!ApHsh39Vt0dQia0Zev19D0g-5teqXg?e=8DsN4P

@adsii1970, are you using the Bleeding Edge version of Kopernicus?  The stable CKAN release that is linked in this thread is only 1.9.1 compatible, noticed from your logs that you are running 1.10.1.  Not related to your issue, but you have a copy of MiniAVC in GEP.  You may want to remove that with ZeroMiniAVC to help reduce log spam as it isn't fully compatible with current KSP versions.

 

@TruthfulGnome, this is relevant for you too, but you may want to wait to upgrade to 1.10.1 for your main save.  You can see R-T-B's post earlier on this page for the roadmap to a stable 1.10.1 release.
 

 

Edited August 22, 2020 by hemeac

[R-T-B]

5 hours ago, saxyomega90125 said:

Would it not be better to include this, or at least this information, in the main release? IME the majority players who use Kopernicus aren't running multistar, they're just running a planet pack or two i.e. OPM. And having this information here, it's just going to get lost for 90-95% of users as soon as the thread hits page 23.

Seems to me the best choice would be to add in a MM config that only enables Kopernicus solar panels if it detects one of the popular multistar mods. Failing that, if you want multistar support to be the priority, you could include a standalone config in the mod's zip called 'Stock Solar Panels for non-multistar users' with the instructions above at the top of the file and on the front page post. Or for CKAN, maybe even just slap together a parallel release with that config in it.

Any of those options will make it easier for the people who download the mod, and anything you can do to make it easy for them will cut the number of support requests you get dramatically.

Congrats on the 1.9.1 release btw

In hindsight, we probably should've put up more warnings about the changed solar code.  I was overconfident that the few mods we shipped configs with were going to be enough, really.  But I still maintain the default settings are still correct going forward.  I probably WILL add documentation on how to disable the solar panels though for potential mod conflicts.

Mind you, eventually other mods should adapt and adjust to this change and you won't need to think about this at all.  We are just sort of in an ugly transition period with the code there, for the moment.  I hope to not have to do things like this often, but there really was no other way to implement multistar that I could find, and yes I do believe multistar support is integral to Kopernicus and should be supported by default (with an opt out for chance bugs, of course).

If I could do it all over, I probably would make the solar panel code turn on/offable in the Kopernicus_config.cfg file we now have that anyone can read/edit easily.  But I was reusing some old code, and I tried not to rock the boat too much by using it's old module manager syntax.  Guess that's where we are now, for better or for worse.  Certainly doesn't make sense to change it yet again, now. 

I think the best thing to do for now would be to just update the release link with the information on how to disable this mode, which is really easy to do.  I'll do that now.

EDIT: Actually, only Prestja can do that, lol.  Anyways, I tried.  Maybe next release we'll ship that option as an optional extractable "extra" zip if it's still an issue.

Edited August 22, 2020 by R-T-B

[R-T-B]

6 hours ago, adsii1970 said:

@R-T-B

Just downloaded your patch shared just a bit ago. I am getting an error message that it's not compatible with 1.10.1.  Here's the error log folder...

https://1drv.ms/u/s!ApHsh39Vt0dQia0Zev19D0g-5teqXg?e=8DsN4P

The main stable release we just made is not ready for 1.10.1.  The bleeding edge release, linked above, is.  It's not as scary as it sounds, honestly.  It works pretty well right now.  It just lacks control of comets so it's not quite ready for prime time.

[hemeac]

39 minutes ago, R-T-B said:

In hindsight, we probably should've put up more warnings about the changed solar code.  I was overconfident that the few mods we shipped configs with were going to be enough, really.  But I still maintain the default settings are still correct going forward.  I probably WILL add documentation on how to disable the solar panels though for potential mod conflicts.

Mind you, eventually other mods should adapt and adjust to this change and you won't need to think about this at all.  We are just sort of in an ugly transition period with the code there, for the moment.  I hope to not have to do things like this often, but there really was no other way to implement multistar that I could find, and yes I do believe multistar support is integral to Kopernicus and should be supported by default (with an opt out for chance bugs, of course).

If I could do it all over, I probably would make the solar panel code turn on/offable in the Kopernicus_config.cfg file we now have that anyone can read/edit easily.  But I was reusing some old code, and I tried not to rock the boat too much by using it's old module manager syntax.  Guess that's where we are now, for better or for worse.  Certainly doesn't make sense to change it yet again, now. 

I think the best thing to do for now would be to just update the release link with the information on how to disable this mode, which is really easy to do.  I'll do that now.

EDIT: Actually, only Prestja can do that, lol.  Anyways, I tried.  Maybe next release we'll ship that option as an optional extractable "extra" zip if it's still an issue.

You were in a bit of catch as you weren't getting tons of users reporting issues as long as people just wanted to wait for it to exit "pre-release".  There's always next release to iron out the bugs that come out from the CKAN release and hope people make backups of their saves.