R-T-B

[1.9.1-1.10.1]R-T-B's Kopernicus Unified "Bleeding Edge" Branch

Recommended Posts

Yo I just reinstalled my game after a while and my main saves have corrupted, so I want to start a new game with a new planet pack, anyone know a good one that replaces or makes changes to the stock system?

Share this post


Link to post
Share on other sites
5 minutes ago, Neil Kermstrong said:

Yo I just reinstalled my game after a while and my main saves have corrupted, so I want to start a new game with a new planet pack, anyone know a good one that replaces or makes changes to the stock system?

JNSQ

Share this post


Link to post
Share on other sites

Depending on how far you want to go with the changes:

OPM is one I personally use - it adds 4 planets to the outer Kerbol system and doesn't change anything else (except for putting Eeloo in orbit around one of those planets.) I like this because I can apply my own rescale mod on top of it, and I get "mostly stock" everything.

I've read good things about the Beyond Home series, and it looks beautiful from all the screenshots. Unfortunately (for me) it replaces the entire solar system, which is something I didn't want when I was looking at planet packs.

Share this post


Link to post
Share on other sites
27 minutes ago, StoneWolfPC said:

JNSQ

Does that one just rescales the stock system?

Edited by Neil Kermstrong
Typo

Share this post


Link to post
Share on other sites
Just now, Neil Kermstrong said:

Does that one just rescales the stock system?

yes,JNSQ rescales the current Kerbolar System by 3.7x(or 2.5x),and it adds a couple of planets,yet be careful,you'll need more than 16gb of ram on your computer,or the performance results could be.... unsettling.

Share this post


Link to post
Share on other sites
5 minutes ago, Dat Kerbal Dude said:

3.7x

2.7x

Do your research before posting!

Share this post


Link to post
Share on other sites

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 42. It contains the following changes:

1.) Particle support bugfixes and further small-scale optimizations for the landscatter culler.

Known Bugs:

1.) None known as of now, however that does not mean there is none! Report if you find any!

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, still trying to optimize until JNSQ runs well on 4GB's of ram, despite the impossibility of it.

19 hours ago, Neil Kermstrong said:

My 4gb ram computer has said no

I get that.  I'd say OPM with land scatters off/some other things turned down is your best bet.  It's basically stock styled so it will run about the same.

Edited by R-T-B

Share this post


Link to post
Share on other sites

KSP 10.1/BG/BE 1101-41/JNSQ

I've been using JNSQ and the BE branch since 1101-2 without any significant problems.  Recently I sent a rover to Gilly and found no surface features and no scan points.  I have rovers on the Mun and Minmus and see scatters and scan points on those bodies.  Can anyone replicate this?  Thanks.

Edit: False alarm, my mistake.  Seems that the scatters and scans points are there, they are just very few and far between.

Edited by Quickspin
update

Share this post


Link to post
Share on other sites
3 hours ago, R-T-B said:

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 42. It contains the following changes:

1.) Particle support bugfixes and further small-scale optimizations for the landscatter culler.

Known Bugs:

1.) None known as of now, however that does not mean there is none! Report if you find any!

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, still trying to optimize until JNSQ runs well on 4GB's of ram, despite the impossibility of it.

I get that.  I'd say OPM with land scatters off/some other things turned down is your best bet.  It's basically stock styled so it will run about the same.

That's good to know.

 

Also I just noticed I am not getting illumination or solar panels problems, before I had to delete solarpanels.cfg but now it's working just fine with it

Share this post


Link to post
Share on other sites
1 hour ago, Neil Kermstrong said:

Also I just noticed I am not getting illumination or solar panels problems, before I had to delete solarpanels.cfg but now it's working just fine with it

Yep, we bugfixed the cfg file a bit back.  Probably helped.

3 hours ago, Quickspin said:

Seems that the scatters and scans points are there, they are just very few and far between.

It's possible the land scatter culler (a recently added feature) is going a bit overboard.  Can anybody confirm if this is intended behavior?  If that is the origin, setting Kopernicus_Config.cfg's "ScatterCullDistance" to have two extra zeros on the end (so "1000000" instead of "10000") will effectively disable it.

Share this post


Link to post
Share on other sites
2 hours ago, R-T-B said:
6 hours ago, Quickspin said:

Seems that the scatters and scans points are there, they are just very few and far between.

It's possible the land scatter culler (a recently added feature) is going a bit overboard.  Can anybody confirm if this is intended behavior?  If that is the origin, setting Kopernicus_Config.cfg's "ScatterCullDistance" to have two extra zeros on the end (so "1000000" instead of "10000") will effectively disable it.

Given my rover's situation on Gilly, I don't see any difference between these two settings - 3 or 4 scatters.  The terrain looks great, BTW.

Share this post


Link to post
Share on other sites
3 hours ago, Quickspin said:

Given my rover's situation on Gilly, I don't see any difference between these two settings - 3 or 4 scatters.  The terrain looks great, BTW.

Sounds like scatters on Gilly may just be less dense by nature, dunno for certain.  Someone correct me if I'm wrong.  But it sounds like the scatter culler is not the cause if it is a bug.

Edited by R-T-B

Share this post


Link to post
Share on other sites
58 minutes ago, R-T-B said:

Sounds like scatters on Gilly may just be less dense by nature, dunno for certain.  Someone correct me if I'm wrong.  But it sounds like the scatter culler is not the cause if it is a bug.

Scatters on Gilly are very dense. Something may be wrong.

Share this post


Link to post
Share on other sites
5 hours ago, Hohmannson said:

Scatters on Gilly are very dense. Something may be wrong.

Hmmm.  Are they in JNSQ though? 

Another thing to try is compare it with release 40.  That's the release before the culling was added.  It would certainly be stock behavior and rule out whether the culling code is doing this or not. @Quickspin, if you have a moment to test that, I'd be appreciative.

Also keep in mind if it is the culling, you need to move to a new area on gilly to properly test as the ones in a save will still be culled until you move.  An "area" is roughly a 10km radius.  If that's too much a bother in your active game, I get it.  Just asking.

Edited by R-T-B

Share this post


Link to post
Share on other sites
6 hours ago, R-T-B said:
11 hours ago, Hohmannson said:

Scatters on Gilly are very dense. Something may be wrong.

Hmmm.  Are they in JNSQ though? 

Another thing to try is compare it with release 40.  That's the release before the culling was added.  It would certainly be stock behavior and rule out whether the culling code is doing this or not. @Quickspin, if you have a moment to test that, I'd be appreciative.

I was using BE 1101-20 when I deployed the rover on Gilly.  That's when I didn't find scatters (or just didn't see them).  When I saw your changes in 1101-41, I updated to that thinking maybe something would change, but it seemed the same.  So, the idea that Gilly has sparse scatters in JNSQ is probably correct.  Given that, if you still think moving the rover would be a helpful test, I'll do that and report back in a day or two.

Share this post


Link to post
Share on other sites
6 hours ago, Quickspin said:

So, the idea that Gilly has sparse scatters in JNSQ is probably correct.

Sounds like it.  Only test if you have nothing better to do, as I am 99% sure this is the case then.

Share this post


Link to post
Share on other sites

hiya. I will be fully satisfied with "it's complicated" as the answer ... but here's the question: the patch that was released for JNSQ for the patchwork texture stuff is very different than the change I originally tried on BeyondHome, which was to change the PQS node's materialType setting from whatever triplanerthingus, to Vacuum. That change worked fine for me on Armstrong in BH, but my understanding is that the JNSQ patch is better, yes? Is it possible to sum up what the JNSQ patch is doing such that I could try the same thing on BH (I'm on an older version and not holding my breath for an official patch). 

Incomplete quote from the JNSQ patch for 1.10 included in spoiler for reference. Does either approach accomplish the same thing, if the scope is my own personal install? :)

Spoiler

@Kopernicus:LAST[JNSQ]

{

  @Body[Dres]

  {

    @Template

    {

      @name = Moho

      !removePQSMods = DEL

      removeAllPQSMods = True

    }

  }

 

Share this post


Link to post
Share on other sites
On 10/16/2020 at 2:42 PM, OrbitalManeuvers said:

hiya. I will be fully satisfied with "it's complicated" as the answer ... but here's the question: the patch that was released for JNSQ for the patchwork texture stuff is very different than the change I originally tried on BeyondHome, which was to change the PQS node's materialType setting from whatever triplanerthingus, to Vacuum. That change worked fine for me on Armstrong in BH, but my understanding is that the JNSQ patch is better, yes? Is it possible to sum up what the JNSQ patch is doing such that I could try the same thing on BH (I'm on an older version and not holding my breath for an official patch). 

Incomplete quote from the JNSQ patch for 1.10 included in spoiler for reference. Does either approach accomplish the same thing, if the scope is my own personal install? :)

  Hide contents

@Kopernicus:LAST[JNSQ]

{

  @Body[Dres]

  {

    @Template

    {

      @name = Moho

      !removePQSMods = DEL

      removeAllPQSMods = True

    }

  }

 

It isn't really that complicated and I will try to explain it in simple terms.

The bottom line is summed up in this announcement I made earlier in the Kopernicus Discord:

Anouncement:  I have cracked the issue with square tiles on Joolian Moon templates.  It is not a Kopernicus bug so much as an improper use of configs.  Most configs (JNSQ included) are using AtmosphericTriplanarZoomRotation as their PQS material.  This DOES NOT WORK on the following bodies as they don't implement that shader:  Laythe (1.9.1 only), Tylo, Bop, Pol, Eeloo.  You must use AtmosphericBasic/AtmosphericOptimized or Vacuum on these bodies or you will get the tile bug!  It's that simple!

So what does that mean?

It means you can fix this two ways:  One is the first way I showed, using the more primitive shaders like AtmosphericBasic or Vacuum.  The other way is to use the more complex shader, but switch the template completely.  That's what OhioBob did.  He also removed all PQSMods to make sure it works right.  Yes, that will muck with things like randoliths, but at least you get the pretty shader without bugs.

Edited by R-T-B

Share this post


Link to post
Share on other sites
8 hours ago, R-T-B said:

It isn't really that complicated and I will try to explain it in simple terms.

Incredibly, this makes sense to me. Thank you for taking the time to write it out. That gives me everything I need to know for short term local fixes, and confirms that proper changes need to come from the mod authors :)

Share this post


Link to post
Share on other sites

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.