Jump to content

[1.8.x-1.12.x]R-T-B's Kopernicus Unified "Bleeding Edge" Branch[REACTIVATED]

R-T-B

By R-T-B
in KSP1 Mod Development

 Share

Recommended Posts

R-T-B

R-T-B

Posted
  • Author
Posted (edited)

This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's mainline Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here.

This is release 31. It contains the following changes:

1.) Comet/Asteroid behavioral bugfixes. No new control, but comets should spawn more now (spawn rate multiplied by 5) and also have proper naming.

2.) Some fixes to the ultra-shader disabling code requested by the Parallax mod and Beyond Home team (Thanks @Gameslinx)

3.) The ring shader has seen some fixes from our own shader pro @LGhassen

Known Bugs:

1.)  The "enableComets" parameter is deprecated now and does not function.  Set "cometPercentage" to 0 to get the same effect.

2.) Fogramp maybe doesn't work right, it's been very buggy in reports lately.

Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc.

Thanks and as always, report bugs!

-RTB

EDIT:  And yet another one:

@R-T-B R-T-B released this 1 hour ago

This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's mainline Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here.

This is release 32. It contains the following changes:

1.) a small race condition for ultra-shader disabling was fixed vs Release 31.

Known Bugs:

1.) The "enableComets" parameter is deprecated now and does not function. Set "cometPercentage" to 0 to get the same effect.

2.) Fogramp maybe doesn't work right, it's been very buggy in reports lately.

Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc.

Thanks and as always, report bugs!

-RTB

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

Gordon Dry

Posted
Posted

To catch all cases I needed to fiddle GameData\Kopernicus\Config\SolarPanels.cfg: 

@PART:HAS[@MODULE:HAS[#useKopernicusSolarPanels[?alse]]]:FINAL
{
	%useKopernicusSolarPanels = 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:
}

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

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

//B9PartSwitch support
@PART:HAS[@MODULE[ModuleB9PartSwitch],~useKopernicusSolarPanels[false]]:FINAL
{
    @MODULE[ModuleB9PartSwitch],*
    {
        @SUBTYPE,*
        {
            @MODULE:HAS[@IDENTIFIER[ModuleDeployableSolarPanel]]
            {
				@IDENTIFIER[ModuleDeployableSolarPanel]
				{
					@name = KopernicusSolarPanels
				}
            }
        }
    }
}

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

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

 

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

R-T-B

Posted
  • Author
Posted
13 hours ago, Gordon Dry said:

To catch all cases I needed to fiddle GameData\Kopernicus\Config\SolarPanels.cfg: 


@PART:HAS[@MODULE:HAS[#useKopernicusSolarPanels[?alse]]]:FINAL
{
	%useKopernicusSolarPanels = 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:
}

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

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

//B9PartSwitch support
@PART:HAS[@MODULE[ModuleB9PartSwitch],~useKopernicusSolarPanels[false]]:FINAL
{
    @MODULE[ModuleB9PartSwitch],*
    {
        @SUBTYPE,*
        {
            @MODULE:HAS[@IDENTIFIER[ModuleDeployableSolarPanel]]
            {
				@IDENTIFIER[ModuleDeployableSolarPanel]
				{
					@name = KopernicusSolarPanels
				}
            }
        }
    }
}

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

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

 

Can you clarify what this does?  What do you mean by "catch all cases?"

Link to comment
Share on other sites
Gordon Dry

Gordon Dry

Posted
Posted (edited)

I have seen patches that assume that "useKopernicusSolarPanels = false" has to  be in the root of PART, other patches assume it has to be in the MODULE[ModuleDeployableSolarPanel].

In some cases only the first of multiple MODULE[ModuleDeployableSolarPanel] has been patched.

And last but not least this weirdness triggered some B9PartSwitch errors on other parts because the internal mesh switching thing for upgradeable solar panels was borked because of the beforementioned behavior.

 

So, when there are two ways of attempting this, either put it into PART or put it into MODULE[ModuleDeployableSolarPanel], then both cases should be taken into account for failsafeness.

Edited by Gordon Dry
Link to comment
Share on other sites
OhioBob

OhioBob

Posted
Posted
1 hour ago, Gordon Dry said:

I have seen patches that assume that "useKopernicusSolarPanels = false" has to  be in the root of PART, other patches assume it has to be in the MODULE[ModuleDeployableSolarPanel].

The instructions have always said that it goes in the root PART node.  From SolarPanels.cfg:

Quote

    // 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

People who put it in the MODULE node apparently (1) don't read instructions, and (2) don't test.

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

R-T-B

Posted
  • Author
Posted (edited)
7 hours ago, Gordon Dry said:

You're right, but a failsafe patch is still a good idea.

This is not an ideal world.

Fair point.  I'm far from encouraging people to do it wrong, but I still will probably use this as the new SolarPanels.cfg in next release.  Just to make users lives easier.

 

I assume this is "false" not "?alse" correct?  Or am I just not aware of this syntax?  On first line: 

@PART:HAS[@MODULE:HAS[#useKopernicusSolarPanels[?alse]]]:FINAL

 

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

R-T-B

Posted
  • Author
Posted (edited)

This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's mainline Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here.

This is release 33. It contains the following changes:

1.) Additional fixes to the Atlas shader for bugs relating to square patches, particlularly noticiable in the Joolian moon templates (Thanks To @StollD for the help).

2.) More edge cases dealt with in SolarPanels.cfg, thank you forum user Gordon Dry.

Known Bugs:

1.) The "enableComets" parameter is deprecated now and does not function. Set "cometPercentage" to 0 to get the same effect.

2.) Fogramp maybe doesn't work right, it's been very buggy in reports lately.

Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc.

Thanks and as always, report bugs!

-RTB

 

This release is pretty big in terms of the changes to fix the square-texture / "farm patch "issue on moons of Jool.  It also may implement Atlas better in general.  Download and test please?  We'd like to push this to stable as soon as possible, but need more widespread testing.

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

R-T-B

Posted
  • Author
Posted (edited)
4 hours ago, Gordon Dry said:

&)

I got mixed up with the reporter of the farm patch issue, will edit, lol.  Thanks!

As an interesting note, the latest atlas changes seem to have made the JNSQ KSC beachfront property.  I think when using the atlas shader, this is correct behavior given the altitude/location, JNSQ devs probably did not intend this though.

EDIT:  This is a bug.  It is being fixed now and will apply soon.

EDIT: Below bug was fixed in latest release.

screenshot.png

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

R-T-B

Posted
  • Author
Posted (edited)

This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's mainline Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here.

This is release 34. It contains the following changes:

1.) An additional config parameter was added to Kopernicus_Config.cfg, EnforcedShaderLevel. This allows packs to choose the shader level enforced by Kopernicus on a per pack basis. The default is 2 (high) to avoid issues with old packs that do not support Atlas (most do not at this point in time). It can also be set to 3 (Ultra) to enable Atlas, or 1 (medium), or even 0 (low) on a per pack preferential basis. Note if a pack does not support atlas behavior is undefined. Setting 3 (Ultra) is best used thus in stock scenarios, or close to stock packs, like OPM.

Known Bugs:

1.) The "enableComets" parameter is deprecated now and does not function. Set "cometPercentage" to 0 to get the same effect.

2.) Fogramp maybe doesn't work right, it's been very buggy in reports lately.

Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc.

Thanks and as always, report bugs!

-RTB

 

NOTE!!!: This fixes the above bug for planet packs by disabling the atlas shader in most cases, and will be pushed to stable very soon!  If you still want the atlas shader (Usually applicable to those using a stock-alike pack like OPM, or just plains stock), simply set "EnforcedShaderLevel = 3" in config/Kopernicus_Config.cfg.  If you are developing a custom planet pack, the Kopernicus dev team strongly recommends considering Parallax over Atlas (KSP's builtin "Ultra" shader).  It is both equally performant, and much prettier!

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

R-T-B

Posted
  • Author
Posted

This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's mainline Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here.

This is release 35. It contains the following changes:

1.) We no longer enforce shader settings in the default package, that is up to the texture pack author and/or user to decide.

Known Bugs:

1.) The "enableComets" parameter is deprecated now and does not function. Set "cometPercentage" to 0 to get the same effect.

2.) Fogramp maybe doesn't work right, it's been very buggy in reports lately.

Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc.

Thanks and as always, report bugs!

-RTB

Link to comment
Share on other sites
Gordon Dry

Gordon Dry

Posted
Posted
14 minutes ago, R-T-B said:

We no longer enforce shader settings in the default package, that is up to the texture pack author and/or user to decide.

So, practically, what does this mean for now - as long as the planet packs do not provide fitting patches?

For example, if I let the default settings 

	EnforceShaders = false
	WarnShaders = false
	EnforcedShaderLevel = 2

as they are, how will the impact to OPM be? @Poodmund

Link to comment
Share on other sites
OrbitalManeuvers

OrbitalManeuvers

Posted
Posted

So I installed 34 (191) last night, cheated to orbit to several BH planets, and nothing had improved over previous versions, in fact it looked worse to me. But, I'd prefer to be more confident about what I'm testing/reporting.

Have you decided about cheating to orbit, whether that's a valid test for checking the patchwork texture issue? I'm guessing that it's probably safer to avoid it, it's just much more time consuming to test, so I wanna be sure that I'm doing what matters.

Also, last night was the first time I've seen the term "atlas" or any mention of alternate shaders, so if there's something I'm supposed to be doing other than just replacing the entire Kopernicus folder with your build updates and leaving everything else the same, I don't know about it. For Beyond Home (no resize, solar system replacement) do you want any settings tweaked?

Tonight I'll grab 35 (or whatever is current a little later today) and try again. But ugh, I hate reporting that something isn't fixed, and I want to be 100% sure that I'm not mis-testing something and giving you false negatives.

OK last question. In the attached image from last night, I've circled a feature of this bug that no one has said anything very specific about. Do you already understand what's causing this very non-random pattern to appear super-imposed on top of texture areas? 

Spoiler

g7VrINA.png

 

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

R-T-B

Posted
  • Author
Posted (edited)
3 hours ago, Gordon Dry said:

So, practically, what does this mean for now - as long as the planet packs do not provide fitting patches?

For example, if I let the default settings 


	EnforceShaders = false
	WarnShaders = false
	EnforcedShaderLevel = 2

as they are, how will the impact to OPM be? @Poodmund

You can choose whatever setting you want by default using the in game slider.  In packs like OPM that are largely stock based, that should be fine.  We are basically easing enforcement of shader-settings to a "my pack needs this setting because it's only tested with it" basis.  Pack authors can opt for a forced or warned setting if they need it, but we don't use it anymore in stock.

1 hour ago, Poodmund said:

Cheating to orbit 'should' be fine if you completely reset the camera scene, i.e. Cheat to orbit -> Go back to the Space Center -> Go to Tracking Station -> Go back to vessel... then do your testing and make your assumptions.

Yes.  It always breaks if you cheat to orbit, but a reload should fix it.  Also, the atlas shader being on (shader quality "Ultra") is most likely going to break Joolian moon-bodies (still working on this, MIGHT have fixed it but I wouldn't be surprised if it's still a thing).  This can be worked around by setting the shader setting to "high" until I figure something better out.  You still get the 1.8 shader.

1 hour ago, OrbitalManeuvers said:

OK last question. In the attached image from last night, I've circled a feature of this bug that no one has said anything very specific about. Do you already understand what's causing this very non-random pattern to appear super-imposed on top of texture areas? 

  Reveal hidden contents

g7VrINA.png

 

That particular circled pattern is a new one to me.  Does it happen on a reload?  That's the only way a cheat-to-orbit is a valid test, unfortunately.  Squad limitations.

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

OrbitalManeuvers

Posted
Posted
11 minutes ago, R-T-B said:

That pattern is a new one to me.  Does it happen on a reload?

I feel like I've been showing pictures of this pattern for a long time. The picture from last night you thought was the mun ... the one from the other day of KSC ...

This is a consistently inconsistent feature of this defect on my machine. The mis-textured rectangles are always like a tint offset or a pattern overlay or both. The shapes within the pattern are unpredictable in layout but always the same in form, as if you're seeing a viewport onto a larger texture with random offsets. You can see this in the first image below - different rects have different patterns, but the nature of the shapes is always similar.

 

Spoiler

KoX2z2V.png

Lighter square near the shore to the north shows pattern

yxQz6if.jpg

 

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

R-T-B

Posted
  • Author
Posted (edited)
9 minutes ago, OrbitalManeuvers said:

I feel like I've been showing pictures of this pattern for a long time. The picture from last night you thought was the mun ... the one from the other day of KSC ...

This is a consistently inconsistent feature of this defect on my machine. The mis-textured rectangles are always like a tint offset or a pattern overlay or both. The shapes within the pattern are unpredictable in layout but always the same in form, as if you're seeing a viewport onto a larger texture with random offsets. You can see this in the first image below - different rects have different patterns, but the nature of the shapes is always similar.

 

  Reveal hidden contents

KoX2z2V.png

Lighter square near the shore to the north shows pattern

yxQz6if.jpg

 

You are correct.  I guess it just wasn't jumping to mind (but I mean, patterns are hard to memorize vs grids)

So it does happen on reload?

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

OrbitalManeuvers

Posted
Posted
36 minutes ago, R-T-B said:

So it does happen on reload?

Yes it does, but let me give you some good news for a change. I've been testing Armstrong in BH for reasons. But I'm looking at Rock right now (cheat to orbit) which uses the Moho template and it's (pardon the pun) rock solid.

So given that I have planets that suck and planets that (omg again) rock, is there anything specific you'd like me to try?

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

R-T-B

Posted
  • Author
Posted
15 minutes ago, OrbitalManeuvers said:

Yes it does, but let me give you some good news for a change. I've been testing Armstrong in BH for reasons. But I'm looking at Rock right now (cheat to orbit) which uses the Moho template and it's (pardon the pun) rock solid.

So given that I have planets that suck and planets that (omg again) rock, is there anything specific you'd like me to try?

Hmm.  Try the teleport/reload scenario with shaders set on high, maybe?  Only if not tried already obviously...

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.

×
 Share
Go to topic listing
×
×
  • Create New...