[1.8.1 - 1.9.1] Kopernicus Continued

[R-T-B]

1 hour ago, prestja said:

Mun doesn't have a gorges biome.

Thanks.  Inexperience showing.

20 minutes ago, Hohmannson said:

BH Armstrong. Seems to be that old good Tylo template bug

Ah!  That one may actually be a separate bug from the one that was occurring on Kerbin.  I think I've heard reports the Tylo template is bugged in some situations.  I'll look into it.  Mainly I need to look around whatever makes Tylo unique as a template, and work from there.

Edited September 29, 2020 by R-T-B

[Hohmannson]

3 minutes ago, R-T-B said:

Mainly I need to look around whatever makes Tylo unique

As for 1.9.1 Tylo, Pol, Bop, Laythe, Vall and Eeloo are suspected to be cursed. On 1.10.1 same, except Laythe. On 1.9.1 Tellumo with its Laythe template got those patchworks. There was an announcement about it in Kop discord.

[R-T-B]

Just now, Hohmannson said:

As for 1.9.1 Tylo, Pol, Bop, Laythe, Vall and Eeloo are suspected to be cursed. On 1.10.1 same, except Laythe. On 1.9.1 Tellumo with its Laythe template got those patchworks. There was an announcement about it in Kop discord.

Hmmm...  Interesting.  It's like the whole Jool system loads differently and may need a special handler.

I will look into this today.  WIthout a clear plan of action, I can't promise a fix timeframe, but watch the bleeding edge in case I have a stroke of brilliance.

[Hohmannson]

14 minutes ago, R-T-B said:

It's like the whole Jool system loads differently and may need a special handler.

It looks like it was not revamped by skwod, and some shady thing breaks all new-material bodies templated to them. Or they miss some unknown properties. Laythe is fixed in 1.10.1, because revamp, seems to be a correlation.

Edited September 29, 2020 by Hohmannson

[siimav]

5 hours ago, R-T-B said:

Ah darn.  Are you running with Ultra shaders?  I really thought we had this eliminated...  Guess we need to take another look.  That's the Mun, right?

Btw, that bug is really common in RSS as well. It happens especially often around Phobos and Deimos but I don't think any of the bodies are immune to it.

Edited September 29, 2020 by siimav

[R-T-B]

11 minutes ago, siimav said:

Btw, that bug is really common in RSS as well. It happens especially often around Phobos and Deimos but I don't think any of the bodies are immune to it.

I'll make an attempted bugfix at this top priority.  I can't believe I am only now hearing of this, thank you for the report guys!

[R-T-B]

Just FYI, I've been informed that teleportation will always produce a bug like the above, and a quick reload to a save where you did not teleport said flight will fix it in that instance.  This is not a fixable bug, but more of a squad thing.

Were any of the above reports a result of teleportation?

Edited September 29, 2020 by R-T-B

[OrbitalManeuvers]

3 hours ago, Hohmannson said:

BH Armstrong. Seems to be that old good Tylo template bug

Yes, this is correct. Sorry, left that out. I should also mention it's not being resized, and also not the latest BH ... I grabbed the last pre-parallax release.

 

7 hours ago, R-T-B said:

Ah darn.  Are you running with Ultra shaders?

yes, Ultra.

btw, I'll just add that my 1.9 JNSQ install seems really stable in the texture department. Your fixes toward this problem have absolutely made progress. Thanks for looking into it!

[OrbitalManeuvers]

1 hour ago, R-T-B said:

Were any of the above reports a result of teleportation?

Not in my case, no. I flew there and landed for realsies.

HOWEVER ... how very interesting to see you say this. When you first started looking into this, I was utterly convinced that KRASH was a huge contributing factor, precisely because it does scene switches, and scene switches felt very involved early on. Plus, pretty much all RSS/RO players use KRASH, it would seem. However, removing KRASH still showed all the symptoms on my JNSQ install, so I figured it maybe wasn't involved. I still think cheat to orbit or KRASH seem to make the problem show up more/worse ... totally unscientific observation.

[OhioBob]

3 hours ago, R-T-B said:

Ah!  That one may actually be a separate bug from the one that was occurring on Kerbin.  I think I've heard reports the Tylo template is bugged in some situations.  I'll look into it.  Mainly I need to look around whatever makes Tylo unique as a template, and work from there.

I haven't used a Tylo template in years because it was always buggy.  The thing that I noticed about it the last time I used it is that I couldn't change terrain textures (i.e. PQS/Material).  I would attempt to use custom textures and it just kept giving me the same built-in stock textures.

[siimav]

1 hour ago, R-T-B said:

Were any of the above reports a result of teleportation?

Nope, happens even after F5 and F9

[R-T-B]

Hmm.  Unfortunately for further fixes I am having a hard time finding a solution that's immediately obvious.  I'll advise future planet pack authors to avoid the Tylo template, and continue to look into this.  It's not forgotten, just waiting until a path forward hopefully is discovered.

Edited September 29, 2020 by R-T-B

[R-T-B]

2 hours ago, siimav said:

Nope, happens even after F5 and F9

Yep, at least on Tylo, can replicate.  Weird.  The logs are barren though, no errors and nothing amiss.

Edited September 29, 2020 by R-T-B

[Nicky21]

I'll stay on the version 5 for a while, I have no plans to mine asteroids in the near future.

In GPP , Gael is the fourth planet in the system. Niven is the third. Maybe asteroids are spawning near Niven? Dunno.... I get a lot of log spam saying "[kopernikus] no new objects this time. probability is x%". I'm goona guess that objects are spawning somwhere and the list is full, they just not spawning near enough so that I can detect them.

Should I go bug the guys (guy, actually) maintaining GPP to update their config files ?

[R-T-B]

1 hour ago, Nicky21 said:

I'll stay on the version 5 for a while, I have no plans to mine asteroids in the near future.

In GPP , Gael is the fourth planet in the system. Niven is the third. Maybe asteroids are spawning near Niven? Dunno.... I get a lot of log spam saying "[kopernikus] no new objects this time. probability is x%". I'm goona guess that objects are spawning somwhere and the list is full, they just not spawning near enough so that I can detect them.

Should I go bug the guys (guy, actually) maintaining GPP to update their config files ?

The config files should not need updating as far as I am aware.  They should work as they did before.  I'll take a look at the asteroid code soon and see if something is not amiss.

Just so users here are aware, the bleeding edge now has an experimental bugfix for the "farm patch" issue.  Please download the latest of that to help test!

 

@Hohmannson, @OrbitalManeuvers, @siimav

Edited September 30, 2020 by R-T-B

[R-T-B]

Kopernicus 1.9.1-6

R-T-B released this now

New in this version (1.9.1-6)

1.) We now use the "high" shader setting by default. This works better with most planet packs out there, and eliminates many system replacement pack bugs from packs being non-atlas ready. If you are using a mostly stock system, you may try the atlas shader out by setting config/Kopernicus_Config.cfg EnforcedShaderLevel = 3. 3 = Ultra, 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.

New in major release (1.9.1)

1.) The longstanding ringshader bugs have been fixed.

2.) Performance Optimization and bugfixes enabling KittopiaTech support.

3.) JNSQ & other world "Farm patch" bug fixed.

4.) Particle support restored.

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

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

This release should fix the "square patch" bug we have had for some time with Joolian moons.

We should note with this release we are forcing the shader setting to "high" instead of Ultra.  This is intended.  We are officially encouraging planet devs to move towards Parallax shader project over squads "Ultra" Atlas shader.  If you must use Atlas, or are using a largely stock pack that benefits from atlas, you may try the atlas shader out by setting config/Kopernicus_Config.cfg EnforcedShaderLevel = 3.

Edited September 30, 2020 by R-T-B

[R-T-B]

Kopernicus 1.9.1-7

R-T-B released this 11 minutes ago

New in this version (1.9.1-7)

1.) We no longer enforce the default shader setting, you may choose whatever you wish by default. Planet pack authors may set restrictions, but we have none out the gate.  This is really the only change with this release, and we thought it best for user freedom to push it out quickly after making the decision to do this.

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

New in major release (1.9.1)

1.) The longstanding ringshader bugs have been fixed.

2.) Performance Optimization and bugfixes enabling KittopiaTech support.

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

4.) Particle support restored.

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

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

[OhioBob]

12 hours ago, R-T-B said:

The [asteroid] config files should not need updating as far as I am aware.  They should work as they did before.  I'll take a look at the asteroid code soon and see if something is not amiss.

If the problems I addressed here have be fixed so that asteroids work better*, I probably will update the configs.  It's not that the current configs won't work, but it's because I couldn't really do what I wanted to do with asteroids because of the bugs.  I had to make some compromises to work around the bugs, settling for something that worked instead of exactly what I wanted.

* Specifically the things we already talked about - spawn group limits and probability.

[R-T-B]

2 hours ago, OhioBob said:

If the problems I addressed here have be fixed so that asteroids work better*, I probably will update the configs.  It's not that the current configs won't work, but it's because I couldn't really do what I wanted to do with asteroids because of the bugs.  I had to make some compromises to work around the bugs, settling for something that worked instead of exactly what I wanted.

* Specifically the things we already talked about - spawn group limits and probability.

No, unfortunately as of now we still have the same behavior and pitfalls.  I couldn't work out a fix.  I hope to someday but comet support is a larger priority.  And I mean real support, not just a percentage of asteroids like we have now.

Edited September 30, 2020 by R-T-B

[vagabond77]

[ERR 18: 52: 40.228] Initialization errors on ModuleB9PartSwitch (moduleID = 'cellSwitch') on part nfs-panel-deploying-advanced-1x2-wv4-1 subtype 'Advanced'
   Could not find matching module

Hi, I found this strange error after updating Kopernicus to "KopernicusBE_1101_Release33.zip" and later versions.

The error seems to refer to the NearFutureSolar mod but until the version "KopernicusBE_1101_Release33.zip" everything worked correctly.

I attach the log with the minimum of mods to generate the problem:

https://drive.google.com/drive/folders/1fjRThU_BaIX02xDBcJ6MAG1kyBjE1dPV?usp=sharing

 

GameData Folder:
B9PartSwitch
CommunityResourcePack
JNSQ
Kopernicus
ModularFlightIntegrator
NearFutureSolar
RationalResources
RationalResourcesParts

Squad

SquadExpansion

ModuleManager.4.1.4.dll

Thanks.

 

 

Edited October 5, 2020 by vagabond77

[R-T-B]

1 hour ago, vagabond77 said:

[ERR 18: 52: 40.228] Initialization errors on ModuleB9PartSwitch (moduleID = 'cellSwitch') on part nfs-panel-deploying-advanced-1x2-wv4-1 subtype 'Advanced'
   Could not find matching module

Hi, I found this strange error after updating Kopernicus to "KopernicusBE_1101_Release33.zip" and later versions.

The error seems to refer to the NearFutureSolar mod but until the version "KopernicusBE_1101_Release33.zip" everything worked correctly.

I attach the log with the minimum of mods to generate the problem:

https://drive.google.com/drive/folders/1fjRThU_BaIX02xDBcJ6MAG1kyBjE1dPV?usp=sharing

 

GameData Folder:
B9PartSwitch
CommunityResourcePack
JNSQ
Kopernicus
ModularFlightIntegrator
NearFutureSolar
RationalResources
RationalResourcesParts

Squad

SquadExpansion

ModuleManager.4.1.4.dll

Thanks.

 

 

It looks like the solarpanel.cfg had a change that caused this.  I will fix this when I get home.  In the meantime, installing a solarpanel.cfg from an older version should work.

[vagabond77]

Thanks! 

[R-T-B]

Kopernicus 1.9.1-8

R-T-B released this 41 minutes ago · 1 commit to master since this release

New in this version (1.9.1-8)

1.) Bugfix for third party solar mods caused by syntax errors in Solarpanels.cfg. (Thanks for the report, @vagabond77).  This is also available on bleeding edge.

New in major release (1.9.1)

1.) 2.) 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!

[CaffyCrazy]

Closer and closer to current KSP version. Ya'll are doing amazing work.

Edited October 5, 2020 by CaffyCrazy

[R-T-B]

5 hours ago, CaffyCrazy said:

Closer and closer to current KSP version. Ya'll are doing amazing work.

Yep, it'll be the first time in a long time if we beat SQUAD to KSP 1.11 with our stable 1.10.1 release, but we're on target to do so if all goes well!