[1.8.1-1] [PLEASE FORK ME] Kopernicus & KittopiaTech

[Tonka Crash]

Just now, The Tenth Avenger said:

Hey everyone

When I have a craft landed at the surface of any body with kopernicus installed, the game tends to lower the frame rate extremly.

Anyone know why this could be?

It's apparently a problem with the new breaking ground surface features. You can edit your save file and change ROCSeed to -1 to disable them. I wanted to keep them, so I removed Kopernicus instead and saw my performance double.

It was discussed Friday in this thread:

 

[Nightside]

3 minutes ago, The Tenth Avenger said:

Hey everyone

When I have a craft landed at the surface of any body with kopernicus installed, the game tends to lower the frame rate extremly.

Anyone knows why this could be?

Does it happen with/without Terrain scatters? I’ve noticed it too in1.7.3, but haven’t had time too properly test.

[The Tenth Avenger]

Just now, Nightside said:

Does it happen with/without Terrain scatters? I’ve noticed it too in1.7.3, but haven’t had time too properly test.

Without

[Nicky21]

13 hours ago, Nightside said:

Does it happen with/without Terrain scatters? I’ve noticed it too in1.7.3, but haven’t had time too properly test.

Lower the terraisn scatterer in the game's settings to somethign liek 5%. or lower.

I've nothiced the same thing im my GPP game adn thsi fixed the issue.

[KerbMav]

10 hours ago, Nicky21 said:

Lower the terraisn scatterer in the game's settings to somethign liek 5%. or lower.

Does that affect the new science scatter thingies? About to go on a search for my first specials and rock collection run.

[Starwaster]

41 minutes ago, KerbMav said:

Does that affect the new science scatter thingies? About to go on a search for my first specials and rock collection run.

No. Technically Surface Features (or sometimes ROCs) aren't really scatter and the frequency with which they appear is handled in their own configuration files. They are not affected by the Terrain Scatter setting at all. They are somewhat affected by the terrain quality setting because they are only supposed to appear at max subdivision. They also are only supposed appear at velocities slower than 500 (configurable in settings.cfg as SERENITY_ROCS_VISUAL_SPEED)

Note that I say 'supposed to' because I've seen situations with Kopernicus where they appear at times when they shouldn't appear such as 10s of kilometers altitude orbit and velocities faster than 500. It doesn't seem to affect all Kopernicus related mods but I don't know why. (you can check ROC statistics with the F12 menu under Breaking Ground -> Surface Features. Enable Enable Surface Feature Stats Gathering and optionally Find Surface Feature. (puts a big red indicator over surface features)

[Space_Coyote]

On 7/12/2019 at 4:23 PM, 4x4cheesecake said:

To remove Dres, you need a MM patch with the following content:

@Kopernicus:AFTER[Kopernicus]
{
	!Body[Dres] {}
}

 

Okay when  you say Module Manager patch (As I know what MM is) I mean how you would go about this? I mean create this configure file an then how would you implement it? See that's the timy bit of confusion I have..

 

so any insight would be helpful

 

Space_Coyote

[Starwaster]

24 minutes ago, Space_Coyote said:

Okay when  you say Module Manager patch (As I know what MM is) I mean how you would go about this? I mean create this configure file an then how would you implement it? See that's the timy bit of confusion I have..

 

so any insight would be helpful

 

Space_Coyote

Create a file with the extension .cfg. Name the file something appropriate for what you're doing. Put it anywhere in the GameData folder or one of its subfolders. If this is for personal use then don't put it in some mod's folder where you might accidentally delete it.

Paste the text of the MM patch that @4x4cheesecake gave you into the cfg file. It will be processed by Module Manager when you next run the game.

[4x4cheesecake]

34 minutes ago, Space_Coyote said:

Okay when  you say Module Manager patch (As I know what MM is) I mean how you would go about this? I mean create this configure file an then how would you implement it? See that's the timy bit of confusion I have..

 

so any insight would be helpful

 

Space_Coyote

Just create a textfile with this content and save it with a .cfg file extension inside of your GameData directory or any subdirectory of it (I like to keep my personal patches in a folder called "zzz_MM"). MM will take care of anything else

Maybe a little bit of insight for a better understanding:

Kopernicus provides a config interface to manipulate/create celestial bodies. The config file is located in "Kopernicus/Config/System.cfg" and it contains the config node "Kopernicus". Without any changes, it will just copy the stock planets. Well, you are not supposed to touch this file, a MM patch is the way to go. MM allows you to modify config nodes without touching the original file.
The patch I've posted above, reads like this:

@ = Edit
Kopernicus = config node
:AFTER[Kopernicus] = patch order. We want to run the patch after MM read the default config.

Then, the actual patch follow and it is encapsulated between { }:

! = remove
Body = sub config node, each celestial body got one
[Dres] = the name of the sub config node, which is the same as the name of the body
{} = this is the encapsulation of the sub node. Need to be there for syntax reasons ^^

During the next game launch, MM will read the Kopernicus config node and then the patch removes all the informations about Dres. It's like deleting the sub-node from the config file but as soon as you remove the patch, Dres will be back because the informations are still available in the config file

edit:

Edited July 17, 2019 by 4x4cheesecake

[Space_Coyote]

19 minutes ago, 4x4cheesecake said:

Just create a textfile with this content and save it with a .cfg file extension inside of your GameData directory or any subdirectory of it (I like to keep my personal patches in a folder called "zzz_MM"). MM will take care of anything else

Maybe a little bit of insight for a better understanding:

Kopernicus provides a config interface to manipulate/create celestial bodies. The config file is located in "Kopernicus/Config/System.cfg" and it contains the config node "Kopernicus". Without any changes, it will just copy the stock planets. Well, you are not supposed to touch this file, a MM patch is the way to go. MM allows you to modify config nodes without touching the original file.
The patch I've posted above, reads like this:

@ = Edit
Kopernicus = config node
:AFTER[Kopernicus] = patch order. We want to run the patch after MM read the default config.

Then, the actual patch follow and it is encapsulated between { }:

! = remove
Body = sub config node, each celestial body got one
[Dres] = the name of the sub config node, which is the same as the name of the body
{} = this is the encapsulation of the sub node. Need to be there for syntax reasons ^^

 

edit:

Thanks for the information. I crated the file. saved it as a  .cfg and rand th program once ddropping it into the config folder of Kopernicus (and yes i called the file (NoDres.cft) ..

 

SO I take it that can be done quite nicely if you want to get rid of planets without having to call in the Death Star..

 

Of core I'll have other questions as I am thinkingaboug wrking on a star system that I would like to put into game.. got a lot of data I can share so I can try and get this sto work..

 

but again thanks for the heal

 

Space_Coyote

[Diddly Feelerino]

I'm having the same extreme lag problem when landing on a planetary surface (namely, the Mun). Is the problem specifically on Kopernicus' end, or BGs?

[Starwaster]

2 hours ago, Diddly Feelerino said:

I'm having the same extreme lag problem when landing on a planetary surface (namely, the Mun). Is the problem specifically on Kopernicus' end, or BGs?

If it's the BG surface features then I would have to say Kopernicus. It's like I said five posts up. Somehow Kopernicus can force surface features to load under conditions that they are not supposed to be. And if it's a scaled up planet system then they can load in such high numbers that frame rate suffers.

Important question: What planet pack are you using? (i.e. JNSQ? RESCALE? Something else?)

Also, isolate the problem to be sure that it really is the Breaking Ground Surface Features and not something else. It happens when landing you say? Test that by landing another craft (or hopefully you have it saved prior to landing) but first Press F12 just before you start landing

Quote

you can check ROC statistics with the F12 menu under Breaking Ground -> Surface Features. Enable Enable Surface Feature Stats Gathering and optionally Find Surface Feature. (puts a big red indicator over surface features

When the lag starts look at the F12 Menu under Surface Features and it will show you how many have loaded in. It should be no more than a few hundred. If it's in the thousands or tens of thousands that's not a normal amount to see. Scaled up planet systems result in more ROCs than at stock. A lot of them showing up at once will cause lag. Previously I thought the range was 2.5 kilometers but it's actually linked to when the terrain is at maximum subdivision which varies from planet to planet. For the Mun at high terrain quality that's 9 kilometers.  You shouldn't see any surface features from higher up than that when landing. And if you're faster than 500 m/s then you shouldn't see them at all. Somehow with Kopernicus they can be force activated when they shouldn't be. I

[jpinard]

I am running stock KSP and by coincidence I sent a massive science moon mission off when 1.73 came out and I loaded Spectra (hence Kopernicus).  When I installed all the science ground experiments my frame rate collapsed drastically.  I thought it was Spectra since the moon looked like corderoy pants so I uninstalled all of it, and then installed SVE.  Moon looked normal but once again once when I put the full complement of ground surface experiments down the frame rate became abysmall.  Went to the main forums to post the issue and saw Tonka's reference it may be this mod, so posting the information here.

[Joker58th]

1 hour ago, jpinard said:

I am running stock KSP and by coincidence I sent a massive science moon mission off when 1.73 came out and I loaded Spectra (hence Kopernicus).  When I installed all the science ground experiments my frame rate collapsed drastically.  I thought it was Spectra since the moon looked like corderoy pants so I uninstalled all of it, and then installed SVE.  Moon looked normal but once again once when I put the full complement of ground surface experiments down the frame rate became abysmall.  Went to the main forums to post the issue and saw Tonka's reference it may be this mod, so posting the information here.

@jpinard Try turning off Terrain Scatters in the graphics settings, restart the game (important) and see if that helps.  Note that turning off Terrain Scatters does not affect the breaking ground surface features, it just makes them easier to see.  

[Diddly Feelerino]

3 hours ago, Starwaster said:

If it's the BG surface features then I would have to say Kopernicus. It's like I said five posts up. Somehow Kopernicus can force surface features to load under conditions that they are not supposed to be. And if it's a scaled up planet system then they can load in such high numbers that frame rate suffers.

Important question: What planet pack are you using? (i.e. JNSQ? RESCALE? Something else?)

Also, isolate the problem to be sure that it really is the Breaking Ground Surface Features and not something else. It happens when landing you say? Test that by landing another craft (or hopefully you have it saved prior to landing) but first Press F12 just before you start landing

When the lag starts look at the F12 Menu under Surface Features and it will show you how many have loaded in. It should be no more than a few hundred. If it's in the thousands or tens of thousands that's not a normal amount to see. Scaled up planet systems result in more ROCs than at stock. A lot of them showing up at once will cause lag. Previously I thought the range was 2.5 kilometers but it's actually linked to when the terrain is at maximum subdivision which varies from planet to planet. For the Mun at high terrain quality that's 9 kilometers.  You shouldn't see any surface features from higher up than that when landing. And if you're faster than 500 m/s then you shouldn't see them at all. Somehow with Kopernicus they can be force activated when they shouldn't be. I

Thank you for the reply. I'm using SVE with OPM (feels smoother than AVP). SVT however doesn't work at the moment; with it active, the Mun is an invisible object when in low orbit around it (could Kopernicus be responsible for that too?).

Anyways, I checked my savefile out of curiosity, and the ROC counter read at "1557078132". I dunno if that's normal, but the scattered rocks were literally as far as the eye could see (rendered distance, no dropoff).

I have quite a laptop rig (ASUS ROG G752VS) so I'm wondering what the craic is.

EDIT - Cut Scatter down from 50 to 5%, yet I still get major lag when approaching the surface. Seemed smooth when reloading with the 5% setting though (craft was already on surface - only seems to lag when approaching). Weird.

 

Edited July 17, 2019 by Diddly Feelerino

[OncaLupe]

1 hour ago, Diddly Feelerino said:

Anyways, I checked my savefile out of curiosity, and the ROC counter read at "1557078132". I dunno if that's normal, but the scattered rocks were literally as far as the eye could see (rendered distance, no dropoff).

If you're referring to the 'ROCSeed' value in the save file, that's a random number used to determine where the surface features show up. Terrain Scatter and the BG Surface Features are independent. Rocks scattered all over the surface are more likely the terrain scatter. To try and isolate it more, try turning the scatter off completely, exit fully and reload the game, then check the F12 menu under Surface Features while landing as mentioned by Starwaster.

[jpinard]

I should also note, it is not immediately horrible upon loading KSP.  It takes an hour before the fps suddenly degrades.

[Starwaster]

1 hour ago, Diddly Feelerino said:

Thank you for the reply. I'm using SVE with OPM (feels smoother than AVP). SVT however doesn't work at the moment; with it active, the Mun is an invisible object when in low orbit around it (could Kopernicus be responsible for that too?).

Anyways, I checked my savefile out of curiosity, and the ROC counter read at "1557078132". I dunno if that's normal, but the scattered rocks were literally as far as the eye could see (rendered distance, no dropoff).

I have quite a laptop rig (ASUS ROG G752VS) so I'm wondering what the craic is.

EDIT - Cut Scatter down from 50 to 5%, yet I still get major lag when approaching the surface. Seemed smooth when reloading with the 5% setting though (craft was already on surface - only seems to lag when approaching). Weird.

 

There is no ROC counter in the save file. You were probably looking at ROCSeed which controls pseudo-random placement which controls exactly where things are placed when using that seed. ROCs also can be anything besides rocks. It's really just an internal name that Squad uses and which is found in the config files and other places.

As for your invisible Mun problem I have no idea. I don't think it's a Kopernicus problem and I see you already posted in the SVT forum so I won't comment on here. Can't really since I don't know anything about it. 

I see someone just replied while I'm typing and they're quite correct. If you want to know ROC statistics then you need to have statistic gathering enabled via F12.

You can also change that ROCSeed to -1 and that will stop all ROCs from being loaded and you can see what effect that has on your performance while landing. (have to change that in the save file and then reload the save file)

[Diddly Feelerino]

Here you go; image showing the stats! 

PS - Scatter set to 5%; graphics high in general.

https://ibb.co/BVYmx9Y

Edited July 17, 2019 by Diddly Feelerino

[Tonas1997]

I'm having a problem trying to use a 1.3.1 planet pack on 1.6.1-9 Kopernicus, due to outdated variable names. The body in question is a "ghost" barycenter which, on the config files, has the following properties:

Properties
{
	...
	hiddenRnD = True
	RnDVisibility = SKIP
	...
}

Apparently, the RnDVisibility enumerate doesn't have a 'SKIP' value anymore. What should it be replaced by?

EDIT: as per the Kopernicus wiki, the value seems to still exist. Is it now case-sensitive?

Edited July 17, 2019 by Tonas1997

[Diddly Feelerino]

And the same again coming in to land; 50% scatter. Started to lag massively by this point;-

https://ibb.co/nnNtyNx

[Starwaster]

@Diddly Feelerino Those numbers aren't terribly high at all.  They can be in the mid hundreds and not cause lag. If they were in the thousands that would be a different matter but 80 of them are no big deal. I don't think your lag is related to the surface features at all. Maybe you need to post your logs if you haven't done that already for someone to look at

[Diddly Feelerino]

18 minutes ago, Starwaster said:

@Diddly Feelerino Those numbers aren't terribly high at all.  They can be in the mid hundreds and not cause lag. If they were in the thousands that would be a different matter but 80 of them are no big deal. I don't think your lag is related to the surface features at all. Maybe you need to post your logs if you haven't done that already for someone to look at

Weird; the game ran absolutely fine before BG - it's on a decent rig, freshly installed over a wiped HDD. Would only get lag in the past from high part counts.....

UPDATE - 5% and 50% scatter show the same numbers of ROC/surface stats and features. Still getting a tad laggy, even with 5%. I did some noseying about and it seems that I'm not the only one with this issue. I suppose all we can do is sit patient and hope for a fix!

Edited July 17, 2019 by Diddly Feelerino

[Joker58th]

1 hour ago, jpinard said:

I should also note, it is not immediately horrible upon loading KSP.  It takes an hour before the fps suddenly degrades.

@jpinard I initially encountered the lag in a career when doing a Mun landing.  See issue here for details with graphs showing what happens from 15km to the surface on a clean install with minimum mods, no resize, no expansion packs.  You mention the Mun in your earlier post so I thought maybe you were experiencing the same.

[Starwaster]

28 minutes ago, Diddly Feelerino said:

Weird; the game ran absolutely fine before BG - it's on a decent rig, freshly installed over a wiped HDD. Would only get lag in the past from high part counts.....

UPDATE - 5% and 50% scatter show the same numbers of ROC/surface stats and features. Still getting a tad laggy, even with 5%. I did some noseying about and it seems that I'm not the only one with this issue. I suppose all we can do is sit patient and hope for a fix!

Ok, how about trying the other thing I suggested? Edit your save file and set ROCSeed to -1 Maybe backup your persistence file first or make note of the seed number (which actually you already did that since you posted it earlier)

Then load the edited save and see if you still get lag in that situation. If it's really BG ROCs that are doing it then you shouldn't get lag if the ROCSeed is -1. No ROCs at all. (the reason for that is so that you don't have Baobab Trees or Mun Rocks or Vall Cryovolcanoes in ur base killing ur doodz) (that's also why I say 'don't forget your ROCSeed' after you're done testing)

Edited July 17, 2019 by Starwaster