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

[Neil Kermstrong]

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?

[StoneWolfPC]

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

[etmoonshade]

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.

[Neil Kermstrong]

27 minutes ago, StoneWolfPC said:

JNSQ

Does that one just rescales the stock system?

Edited October 13, 2020 by Neil Kermstrong
Typo

[Dat Kerbal Dude]

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.

[Neil Kermstrong]

Just now, Dat Kerbal Dude said:

be careful,you'll need more than 16gb of ram

My 4gb ram computer has said no

[Commodore_32]

5 minutes ago, Dat Kerbal Dude said:

3.7x

2.7x

Do your research before posting!

[R-T-B]

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 42

R-T-B released this 5 minutes 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 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 October 14, 2020 by R-T-B

[Quickspin]

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 October 14, 2020 by Quickspin
update

[Neil Kermstrong]

3 hours ago, R-T-B said:

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 42

R-T-B released this 5 minutes 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 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

[R-T-B]

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.

[Quickspin]

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.

[R-T-B]

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 October 15, 2020 by R-T-B

[Hohmannson]

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.

[R-T-B]

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 October 15, 2020 by R-T-B

[Quickspin]

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.

[R-T-B]

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.

[OrbitalManeuvers]

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

    }

  }

 

[R-T-B]

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 October 18, 2020 by R-T-B

[OrbitalManeuvers]

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

[Fergrim]

Hey!  First of all I wanted to sincerely thank you for working on this.

Being able to even have a prayer of getting the latest version running on kopernicus early like this is really great.

I just have one question, perhaps you can save my head some banging against my desk, does Kopernicus 1.10 currently work with sigma rescale?

I use Kopernicus to run OPM and Valentine, and I've always preferred to play at like 3.5 - 6x.  But I like to basically adjust those settings myself, so I've always used sigma rescale.. But in trying to get KSP running recently, I've narrowed my issue down to sigma + kopernicus (you know, standard KSP crashing on load business).

Should I expect sigma rescale to work with your latest branch or should I just stop trying until someone tells me it's good to go again?  If you know it should work, I'll happily blame my ineptitude and get back to work on making it work.   Just figured I'd ask rather than get any more frustrated/confused.

Edited October 22, 2020 by Fergrim

[R-T-B]

On 10/21/2020 at 7:33 PM, Fergrim said:

does Kopernicus 1.10 currently work with sigma rescale?

Sorry for taking so long to get back to you on this, work had me overworked for a bit... heh.

I unfortunately have no idea.  Sigma would be the one to ask about that.  I don't deal with the rescale guys much.

And indeed, on that note all, development on Kopernicus should be resuming this weekend.  I hope to improve comets, in particular.  They aren't really that great right now.

Edited October 24, 2020 by R-T-B

[Fergrim]

Np, of course  Do you know if there is any other option to rescale in general outside of sigma?  As far as I know, it's the only one, which is why I thought it was sort of married to kopernicus.  If there's another way, I'd be glad to look into that as well

[R-T-B]

11 hours ago, Fergrim said:

Np, of course  Do you know if there is any other option to rescale in general outside of sigma?  As far as I know, it's the only one, which is why I thought it was sort of married to kopernicus.  If there's another way, I'd be glad to look into that as well

I'm not into rescale mods, so I don't know unfortunately.

If anyone else could weigh in here I'd appreciate it.

[etmoonshade]

On 10/21/2020 at 9:33 PM, Fergrim said:

Hey!  First of all I wanted to sincerely thank you for working on this.

Being able to even have a prayer of getting the latest version running on kopernicus early like this is really great.

I just have one question, perhaps you can save my head some banging against my desk, does Kopernicus 1.10 currently work with sigma rescale?

I use Kopernicus to run OPM and Valentine, and I've always preferred to play at like 3.5 - 6x.  But I like to basically adjust those settings myself, so I've always used sigma rescale.. But in trying to get KSP running recently, I've narrowed my issue down to sigma + kopernicus (you know, standard KSP crashing on load business).

Should I expect sigma rescale to work with your latest branch or should I just stop trying until someone tells me it's good to go again?  If you know it should work, I'll happily blame my ineptitude and get back to work on making it work.   Just figured I'd ask rather than get any more frustrated/confused.

I had a hell of a time with Sigma Dimensions a month or three ago. My eventual solution was to do a FULLY clean install of KSP - don't transfer your configs, don't copy stuff from old folders. Install everything from a clean distribution.

Edit: Clean including KSP. Delete the folder from your Steam directory entirely, run the uninstall from Steam, and then reinstall it.

Edited October 26, 2020 by etmoonshade