Jump to content

[1.8.1 - 1.9.1] Kopernicus Continued


prestja

Recommended Posts

@R-T-B, not sure that the fix to your Solar Panel Config will end up with the expected behavior with parts with multiple solar panels. 

Going into the ModuleManager.ConfigCache, can see that parts with multiple solar panel modules will only have the first set a Kopernicus module, the rest will remain stock:

  Reveal hidden contents

 

Link to comment
Share on other sites

Going back to 1.9.1-7, you can see the issue with the Near Future Solar, your solar code still patched the solar module:

  Reveal hidden contents

The culprit happened in JNSQ as that disables Kopernicus solar panels at the part level which disables the B9 patch BUT

You have

@PART:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[~useKopernicusSolarPanels[false]]]:FINAL
{
    @MODULE[ModuleDeployableSolarPanel],*
    {
        @name = KopernicusSolarPanels
    }
}

Which will convert all moduledeployablesolarpanels to Kopernicus unless the modder has ALSO specified useKopernicusSolarPanels = false within the module of the solar panel part.

This is my suggested config which also incorporates elements of Zorg's BDB Patch to hopefully make it a bit more failsafe.  I have tested this with 60+ part mods in both JNSQ as well as multi-sun setup: Stock + GEP with no B9 Warnings in 1.9.1.

// If any modder adds useKopernicusSolarPanels = false to a module instead of a part, add it to the part:
@PART:HAS[@MODULE:HAS[#useKopernicusSolarPanels[?alse]]]:FINAL
{
	%useKopernicusSolarPanels = false
}

// Uses regular expressions to convert any case variants like FalSe to false
@PART:HAS[#useKopernicusSolarPanels[*]]:FINAL
{
    // This cfg will enable KopernicusSolarPanels
    // to allow support for multiple lightsources
    // 
    // If you want to avoid this, add "useKopernicusSolarPanels = false" to the PART node
    // That will stop Kopernicus from changing the behaviour of SolarPanels
    @useKopernicusSolarPanels,* ^= :F:f:
    @useKopernicusSolarPanels,* ^= :A:a:
    @useKopernicusSolarPanels,* ^= :L:l:
    @useKopernicusSolarPanels,* ^= :S:s:
    @useKopernicusSolarPanels,* ^= :E:e:
}

// Converts all ModuleDeployableSolarPanel modules within a part to KopernicusSolarPanels unless the part has useKopernicusSolarPanels = false
@PART:HAS[@MODULE[ModuleDeployableSolarPanel],~useKopernicusSolarPanels[false]]:FINAL
{
    @MODULE[ModuleDeployableSolarPanel],*
    {
        @name = KopernicusSolarPanels
    }
}

//B9PartSwitch support, changes the identifier to a generic identifier, just to be safe, but only runs if the part does not have useKopernicusSolarPanels = false ... 
@PART:HAS[@MODULE[ModuleB9PartSwitch],~useKopernicusSolarPanels[false]]:FINAL
{
    @MODULE[ModuleB9PartSwitch],*
    {
        @SUBTYPE,*
        {
            @MODULE:HAS[@IDENTIFIER[ModuleDeployableSolarPanel]]
            {
				@IDENTIFIER[ModuleDeployableSolarPanel]
				{
					@name = *SolarPanel*
				}
            }
        }
    }
}

// clean up
@PART:HAS[#useKopernicusSolarPanels[*]]:FINAL
{
	!useKopernicusSolarPanels = delete
}

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

 

Edited by hemeac
Updated suggested patch after testing
Link to comment
Share on other sites

  On 10/6/2020 at 2:19 AM, hemeac said:

@R-T-B, not sure that the fix to your Solar Panel Config will end up with the expected behavior with parts with multiple solar panels. 

Going into the ModuleManager.ConfigCache, can see that parts with multiple solar panel modules will only have the first set a Kopernicus module, the rest will remain stock:

  Reveal hidden contents

 

Expand  

The current fix is more a fallback to old behavior.  It won't cover all cases but it will function as it did before for at least near future solar and most major mods.  I obviously botched the first patch and was just looking for quick fix (still a modularmanager noob in terms of understanding syntax). 

I was planning on looking at it in more detail tomorrow but I appreciate you beating me to it.  That will likely ship to bleeding edge tomorrow and then to stable very soon thereafter.  I just need to test it, which I will probably do tomorrow morning.  Thanks.  You'll get credit in next release's release notes.

Edited by R-T-B
Link to comment
Share on other sites

  On 10/6/2020 at 4:30 AM, R-T-B said:

The current fix is more a fallback to old behavior.  It won't cover all cases but it will function as it did before for at least near future solar and most major mods.  I obviously botched the first patch and was just looking for quick fix (still a modularmanager noob in terms of understanding syntax). 

I was planning on looking at it in more detail tomorrow but I appreciate you beating me to it.  That will likely ship to bleeding edge tomorrow and then to stable very soon thereafter.  I just need to test it, which I will probably do tomorrow morning.  Thanks.

Expand  

It definitely took my lunch break+ to diagnose why it was failing.

Link to comment
Share on other sites

@R-T-B R-T-B released this 1 minute ago · 1 commit to master since this release

New in this version (1.9.1-9)

1.) Contributions to SolarPanels.cfg from forum user hemeac to help avoid errors in third party packs.

New in major release (1.9.1)

1.) Planet pack authors (or you) may now specify the packs target shader level by by setting config/Kopernicus_Config.cfg EnforcedShaderLevel. 3 = Ultra/Atlas, 2 = High, 1 = Medium, and 0 = Low. Planet pack authors may use this via modulemanager module if needed as well. Note that we encourage of the KSP Parallax shader project over use of Squad's ATLAS shader. It is both equally performant and more flexible.

2.) The longstanding ringshader bugs have been fixed.

3.) Performance Optimization and bugfixes enabling KittopiaTech support.

4.) JNSQ & other large world "Farm patch" bug fixed.

5.) Particle support restored.

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

7.) 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.

8.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable shader locking, as well as set preferred shader level. Easy to edit, just look inside!

Edited by R-T-B
Link to comment
Share on other sites

This is a big release to the stable branch people, for both planet devs and players.  I strongly advise updating!  Highlighting some of the chief improvements below!

@R-T-B R-T-B released this now

New in this version (1.9.1-10)

1.) Added a culling range to land scatters, by default at 10km, configurable by the Kopernicus_Config.cfg parameter ScatterCullDistance. This massively improves performance in scatter-heavy planet packs with land scatters on.

2.) We now support "Breaking Ground" anomalies out of the box, eliminating the need for "MyRocksAreBiggerThanYours."

3.) Material names have been simplified. You can still use the old ones, but there are simpler alternatives now. You can see https://github.com/R-T-B/Kopernicus/pull/28/files for details, or simply wait for the wiki to update. Remember, the old names still work and we have no plans to change that, this is just for usability.

New in major release (1.9.1)

1.) Planet pack authors (or you) may now specify the packs target shader level by by setting config/Kopernicus_Config.cfg EnforcedShaderLeve. 3 = Ultra/Atlas, 2 = High, 1 = Medium, and 0 = Low. Planet pack authors may use this via modulemanager module if needed as well. Note that we encourage of the KSP Parallax shader project over use of Squad's ATLAS shader. It is both equally performant and more flexible.

2.) The longstanding ringshader bugs have been fixed.

3.) Performance Optimization and bugfixes enabling KittopiaTech support.

4.) JNSQ & other large world "Farm patch" bug fixed.

5.) Particle support restored.

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

7.) 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.

8.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable shader locking, as well as set preferred shader level. Easy to edit, just look inside!

Edited by R-T-B
Link to comment
Share on other sites

  On 10/26/2020 at 8:59 PM, TARDIS Mapping said:

Will do, I'll have it to you in a few days. My apologies about taking so long to reply, ngl, I forgot I signed up for the KSP forums.

Expand  

Thanks for getting back to me.  I hope I can help you out!  And no worries, the only cost of taking a long time with my requests is I can't help you until I get what I ask for, lol.

  On 10/25/2020 at 5:28 AM, OOM said:

What did you say?

Expand  

I think he's surprised the internet didn't eat our thread, is all.  Forum updates here do weird crap a lot.

Link to comment
Share on other sites

@R-T-B R-T-B released this 1 hour ago · 1 commit to master since this release

New in this version (1.9.1-11)

1.) Solarpanel.cfg fixes to support more third party solar panels with less work.

2.) Fixes for the colliders on land scatters (due to a small bug in the distance-culling system).

3.) Added an RGB+A parser (MapSOParserRGBA) for devs who requested it. Largely an under the hood change with no end-user impact immediately visible.

New in major release (1.9.1)

1.) Added a culling range to land scatters, by default at 10km, configurable by the Kopernicus_Config.cfg parameter ScatterCullDistance. This massively improves performance in scatter-heavy planet packs with land scatters on.

2.) We now support "Breaking Ground" anomalies out of the box, eliminating the need for "MyRocksAreBiggerThanYours."

3.) Material names have been simplified. You can still use the old ones, but there are simpler alternatives now. You can see https://github.com/R-T-B/Kopernicus/pull/28/files for details, or simply wait for the wiki to update. Remember, the old names still work and we have no plans to change that, this is just for usability.

3.) Planet pack authors (or you) may now specify the packs target shader level by by setting config/Kopernicus_Config.cfg EnforcedShaderLeve. 3 = Ultra/Atlas, 2 = High, 1 = Medium, and 0 = Low. Planet pack authors may use this via modulemanager module if needed as well. Note that we encourage of the KSP Parallax shader project over use of Squad's ATLAS shader. It is both equally performant and more flexible.

4.) The longstanding ringshader bugs have been fixed.

5.) Performance Optimization and bugfixes enabling KittopiaTech support.

6.) JNSQ & other large world "Farm patch" bug fixed.

7.) Particle support restored.

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

9.) 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.

10.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable shader locking, as well as set preferred shader level. Easy to edit, just look inside!

Link to comment
Share on other sites

I apologize to release two releases in one day, but we had a logspam issue, so here's the hotfix.  Bleeding edge will also get the same fix in just a moment.

@R-T-B R-T-B released this 39 seconds ago · 1 commit to master since this release

New in this version (1.9.1-12)

1.) This is a hotfix to address logspam issues that were otherwise mostly harmless (may hurt performance but not your game). Updating is still advisable.

New in major release (1.9.1)

1.) Solarpanel.cfg fixes to support more third party solar panels with less work.

2.) Fixes for the colliders on land scatters (due to a small bug in the distance-culling system).

3.) Added an RGB+A parser (MapSOParserRGBA) for devs who requested it. Largely an under the hood change with no end-user impact immediately visible.

4.) Added a culling range to land scatters, by default at 10km, configurable by the Kopernicus_Config.cfg parameter ScatterCullDistance. This massively improves performance in scatter-heavy planet packs with land scatters on.

5.) We now support "Breaking Ground" anomalies out of the box, eliminating the need for "MyRocksAreBiggerThanYours."

6.) Material names have been simplified. You can still use the old ones, but there are simpler alternatives now. You can see https://github.com/R-T-B/Kopernicus/pull/28/files for details, or simply wait for the wiki to update. Remember, the old names still work and we have no plans to change that, this is just for usability.

7.) Planet pack authors (or you) may now specify the packs target shader level by by setting config/Kopernicus_Config.cfg EnforcedShaderLeve. 3 = Ultra/Atlas, 2 = High, 1 = Medium, and 0 = Low. Planet pack authors may use this via modulemanager module if needed as well. Note that we encourage of the KSP Parallax shader project over use of Squad's ATLAS shader. It is both equally performant and more flexible.

8.) Performance Optimization and bugfixes enabling KittopiaTech support.

  1. Particle support restored.

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

9.) 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.

10.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable shader locking, as well as set preferred shader level. Easy to edit, just look inside!

Edited by R-T-B
Link to comment
Share on other sites

Just so I am clear, when there is a stable, non-experimental ready release for 1.10.x:  Will it simply be a milestone in the RTB developmental thread? Or will there be a separate topic completely for just the 1.10.x Kopernicus? Or will this topic update and become the 1.10.x "stable release" thread of discussion?

Link to comment
Share on other sites

  On 11/1/2020 at 6:13 AM, Murdabenne said:

Just so I am clear, when there is a stable, non-experimental ready release for 1.10.x:  Will it simply be a milestone in the RTB developmental thread? Or will there be a separate topic completely for just the 1.10.x Kopernicus? Or will this topic update and become the 1.10.x "stable release" thread of discussion?

Expand  

I suspect we will continue to use this topic for stable 1.10.1 and all future builds, but have not discussed it with Prestja yet so that COULD change.  I don't think it will though.

When 1.10 is release btw, we won't be dropped support for 1.9.1.  The new unified build system I pioneered in the bleeding edge should allow us to continue to support 1.9.1 indefinitely (or at least until something really bad stops us).

Edited by R-T-B
Link to comment
Share on other sites

  On 11/1/2020 at 7:53 AM, R-T-B said:

I suspect we will continue to use this topic for stable 1.10.1 and all future builds, but have not discussed it with Prestja yet so that COULD change.  I don't think it will though.

When 1.10 is release btw, we won't be dropped support for 1.9.1.  The new unified build system I pioneered in the bleeding edge should allow us to continue to support 1.9.1 indefinitely (or at least until something really bad stops us).

Expand  

Thanks for the information.  I agree with your intent to have a unified release and consequentially a unified topic message thread for all versions, based off this, the current 1.9.x topic.  Its simpler, and hopefully makes for less work for you and @prestjaas well, since this is a lot of stuff to do and you both are donating your free time.   Eric Raymond famously remarked "Every good work of software starts by scratching a developer's personal itch." I hope developing and maintaining this wonderful add-on keeps "scratching" whatever it does for both of you.

Edited by Murdabenne
typo
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...