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

[Diddly Feelerino]

7 minutes ago, Starwaster said:

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)

Just tried it again with 50% scatter, ROCSeed set to -1 both on save and persistent files. Still get lag.

Very strange; this problem wasn't apparent in earlier versions. Has the scatter spread been increased or something?

[Joker58th]

4 hours ago, Diddly Feelerino said:

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.
 

@Diddly Feelerino Actually, I recall this as well in my scenario with a Mun landing.  After landing, if I jumped to the tracking station, for example, and went back to the same ship, the lag was gone.  Can you try completely disabling terrain scatters, restart the game and try your mun landing again?

Edit: And when I say disable terrain scatters, I mean unchecking the radial button and not just adjusting the slider to 0.  That may be the same thing but I'm not 100% on that.

Edited July 17, 2019 by Joker58th

[Starwaster]

2 minutes ago, Diddly Feelerino said:

Just tried it again with 50% scatter, ROCSeed set to -1 both on save and persistent files. Still get lag.

Very strange; this problem wasn't apparent in earlier versions. Has the scatter spread been increased or something?

Not that I know of. Here's something else you can try based on what @Galileo did for JNSQ. Basically creates three new settings for terrain quality with reduced minDistance

Just make a config file in your GameData folder somewhere and save the contents from below.

@Kopernicus
{
	Preset
	{
		name = Performance_Low
		displayName = Performance_Low
		PLANET
		{
			name = Moho
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Eve
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Gilly
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Kerbin
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Mun
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Minmus
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Duna
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Ike
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Dres
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Laythe
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Vall
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Tylo
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Bop
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Pol
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = Eeloo
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = LaytheOcean
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
		PLANET
		{
			name = KerbinOcean
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 6
		}
	}
	Preset
	{
		name = Performance_Default
		displayName = Performance_Default
		PLANET
		{
			name = Moho
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Eve
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Gilly
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Kerbin
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Mun
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Minmus
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Duna
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Ike
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Dres
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Laythe
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Vall
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Tylo
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Bop
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Pol
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = Eeloo
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = LaytheOcean
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
		PLANET
		{
			name = KerbinOcean
			minDistance = 4
			minSubdivision = 1
			maxSubdivision = 8
		}
	}
	Preset
	{
		name = Performance_High
		displayName = Performance_High
		PLANET
		{
			name = Moho
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Eve
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Gilly
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Kerbin
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Mun
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Minmus
			minDistance = 8
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Duna
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Ike
			minDistance = 8
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Dres
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Laythe
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Vall
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Tylo
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Bop
			minDistance = 8
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Pol
			minDistance = 8
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = Eeloo
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = LaytheOcean
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
		PLANET
		{
			name = KerbinOcean
			minDistance = 6
			minSubdivision = 1
			maxSubdivision = 10
		}
	}
}

 

[Diddly Feelerino]

10 minutes ago, Joker58th said:

@Diddly Feelerino Actually, I recall this as well in my scenario with a Mun landing.  After landing, if I jumped to the tracking station, for example, and went back to the same ship, the lag was gone.  Can you try completely disabling terrain scatters, restart the game and try your mun landing again?

Much less laggy with scatter disabled; even with 5% scatter the lag is significant. When I do non physics warp the game runs much smoother, but the moment you return to normal phys or physwarp it lags like hell (with scatter enabled). Dunno what's going on.

[dok_377]

On 7/16/2019 at 1:18 AM, 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?

Dont't know the reason, but can confirm, I just had 12 fps after teleporting a craft with ~230 parts to the Mun orbit. After some testing it turned out that this was caused by Kopernicus. 

[Jognt]

You guys with FPS issues, what happens if you move away from your vessel (EVA a kerbal) far enough to pack the main vessel? (2.5km?)

I also have a weird FPS issue around other planets (using JNSQ), and I noticed that the framerate instantly recovered once my main vessel got packed up while I was on EVA.

Unfortunately I can't really remove Kopernicus/sigma stuff due to running JNSQ (and not wanting to break the stuff I have flying around) so I'm at a loss what's causing it, but I'm curious if you guys also experience improvements after vessel packing.

 

[Starwaster]

Just now, Jognt said:

You guys with FPS issues, what happens if you move away from your vessel (EVA a kerbal) far enough to pack the main vessel? (2.5km?)

I also have a weird FPS issue around other planets (using JNSQ), and I noticed that the framerate instantly recovered once my main vessel got packed up while I was on EVA.

Unfortunately I can't really remove Kopernicus/sigma stuff due to running JNSQ (and not wanting to break the stuff I have flying around) so I'm at a loss what's causing it, but I'm curious if you guys also experience improvements after vessel packing.

 

Did you try one of the JNSQ terrain quality settings?

It's an extra set of terrain quality presets if from the main menu you go to Settings -> Graphics and you will see that the slider has 3 more options so it's Low, Default, High, JNSQ_Low, JNSQ_Default and JNSQ_High.

The main difference being that the minDistance is lower. So you have to be closer before things start loading. It seems to also help with the ROC issue.

[Jognt]

Just now, Starwaster said:

Did you try one of the JNSQ terrain quality settings?

It's an extra set of terrain quality presets if from the main menu you go to Settings -> Graphics and you will see that the slider has 3 more options so it's Low, Default, High, JNSQ_Low, JNSQ_Default and JNSQ_High.

The main difference being that the minDistance is lower. So you have to be closer before things start loading. It seems to also help with the ROC issue.

Yeah I set it to the second to last "High", which should be JNSQ_Medium. Mun FPS is still lower than I'd like for my PC (GTX 980, 4ghz 4670k) but I haven't done any scientific comparing. (FPS is still above 20 with a small MH parts lander, so I'm not annoyed enough to quit and test)

Do you actually see JNSQ_[setting]? I only saw it the first time when I had removed the settings.cfg. I thought it was normal that it reverts to either 4x High settings in a row or something else while throwing array out of bounds errors. You make me wonder..

[Starwaster]

Just now, Jognt said:

Yeah I set it to the second to last "High", which should be JNSQ_Medium. Mun FPS is still lower than I'd like for my PC (GTX 980, 4ghz 4670k) but I haven't done any scientific comparing. (FPS is still above 20 with a small MH parts lander, so I'm not annoyed enough to quit and test)

Do you actually see JNSQ_[setting]? I only saw it the first time when I had removed the settings.cfg. I thought it was normal that it reverts to either 4x High settings in a row or something else while throwing array out of bounds errors. You make me wonder..

If you get an error like that it sounds like it's confused about how many presets are in the list. That happened to me and  I deleted the extra ones from the settings.cfg file so it would have to rebuild them after restarting the game

[Jognt]

Just now, Starwaster said:

If you get an error like that it sounds like it's confused about how many presets are in the list. That happened to me and  I deleted the extra ones from the settings.cfg file so it would have to rebuild them after restarting the game

I've removed the entire Settings.cfg several times. But you're saying it's supposed to always show JNSQ_[level]?

[Starwaster]

1 hour ago, Jognt said:

I've removed the entire Settings.cfg several times. But you're saying it's supposed to always show JNSQ_[level]?

I did something based on what they did for JNSQ and this is what it looks like (substitute the word Performance with  JNSQ and that's what you should see)

Edited July 17, 2019 by Starwaster

[Agustin]

How Can I have this installed in 1.7.2? there is a warning not to open my save when loading last two versions for 1.7.1 and 1.7.3

I need to be in 1.7.2 for principia

Edited July 18, 2019 by Agustin

[AVaughan]

5 hours ago, Agustin said:

How Can I have this installed in 1.7.2? there is a warning not to open my save when loading last two versions for 1.7.1 and 1.7.3

I need to be in 1.7.2 for principia

There is no released Kopernicus version for 1.7.2.  Use KSP 1.7.1 or 1.7.3, or compile from source (at your own risk if that doesn't work properly).

[Jognt]

11 hours ago, Agustin said:

How Can I have this installed in 1.7.2? there is a warning not to open my save when loading last two versions for 1.7.1 and 1.7.3

I need to be in 1.7.2 for principia

I'd ask the Principia guys what build they tested with then considering there's no official 1.7.2 build that I know of.

[frencrs]

On 7/17/2019 at 3:17 PM, Starwaster said:

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)

 

Setting the ROCSeed to -1 definitely fixed the lag for me, maybe it's what some other people have suggested and it's loading them at higher speeds and altitudes than <2000m <500m/s?

[Starwaster]

1 hour ago, frencrs said:

 

Setting the ROCSeed to -1 definitely fixed the lag for me, maybe it's what some other people have suggested and it's loading them at higher speeds and altitudes than <2000m <500m/s?

Oh it definitely is. The planet system I'm mainly interested in is Kerbin scaled 10x and IIRC they were loading in at around 30km or so. But the distance isn't consistent and apparently is linked to when the terrain is at max subdivision.

What I'm currently experimenting with is terrain quality presets that reduce the distance at which things start loading in since I want to play with the new BG features fully enabled. If you look further up the thread I posted some presets that cut the minDistance value. The one I posted works well but I think could be better so I'm experimenting with alternate values. Turns out there are lower limits as to how far down you can turn things before it really screws the terrain up. (values of 1 and 2 are BAD and I lost a lander testing things). Maybe @Galileo can shed light on how far down it's safe to go? Maybe the values he used for JNSQ are the lower limit...

Reducing the ROC count also helps but in a scaled up planet system that means fewer of them per square meter and they can be a PITA to find as it is. What scale system are you playing in where you got the lag?

[frencrs]

3 hours ago, Starwaster said:

Oh it definitely is. The planet system I'm mainly interested in is Kerbin scaled 10x and IIRC they were loading in at around 30km or so. But the distance isn't consistent and apparently is linked to when the terrain is at max subdivision.

What I'm currently experimenting with is terrain quality presets that reduce the distance at which things start loading in since I want to play with the new BG features fully enabled. If you look further up the thread I posted some presets that cut the minDistance value. The one I posted works well but I think could be better so I'm experimenting with alternate values. Turns out there are lower limits as to how far down you can turn things before it really screws the terrain up. (values of 1 and 2 are BAD and I lost a lander testing things). Maybe @Galileo can shed light on how far down it's safe to go? Maybe the values he used for JNSQ are the lower limit...

Reducing the ROC count also helps but in a scaled up planet system that means fewer of them per square meter and they can be a PITA to find as it is. What scale system are you playing in where you got the lag?

 

4x scale, around the mun at like 25km. I haven't looked at the new stuff in the dll for the DLC's at all, I'm gonna take a look at them and see if I can find what holds the loading values for those ROCs.

Edited July 19, 2019 by frencrs

[Jognt]

On 7/18/2019 at 12:52 AM, Starwaster said:

I did something based on what they did for JNSQ and this is what it looks like (substitute the word Performance with  JNSQ and that's what you should see)

 

Below is what I see with JNSQ. I was under the impression that was normal. I'll do some checking later with regards to FPS and RoCs. I really don't feel like doing a JNSQ bug report as I doubt I'll be welcomed after my recent "ohmygod you used FINAL?!" spree.

https://imgur.com/a/gpSCqqO

Edit: I removed the entire Terrain{} section in Settings.cfg and let it rebuild it. Nametags were fine on first start and reverted to the pictured behavior after that.

Edited July 19, 2019 by Jognt

[Starwaster]

23 minutes ago, Jognt said:

 

This is what I see with JNSQ. I was under the impression that was normal. I'll do some checking later with regards to FPS and RoCs.

https://imgur.com/a/gpSCqqO

Edit: I removed the entire Terrain{} section in Settings.cfg and let it rebuild it. Nametags were fine on first start and reverted to the pictured behavior after that.

That's what I'm seeing now too. It worked once and I thought it was working on subsequent occasions but it's not.

And, adding those kinds of presets to the TERRAIN section by hand is also supposed to work but is not.  Adding presets by hand is even something that has been suggested on these forums by knowledgeable people but when I try to add presets by hand now, it behaves exactly the same as what you're seeing.

The way Kopernicus adds them is through code and then (I think) KSP is writing them to the Settings.cfg file itself.  So something broke somewhere and I'm guessing it happened fairly recently. Looking at the relevant Kopernicus code, I think that what is happening is that on subsequent game restarts Kopernicus detects that the new presets have been loaded by KSP and so it doesn't go through the final stage of adding them. (after all, why add them a second time?)

So what it looks like to me is that this is a new KSP issue rather than a Kopernicus issue. Hopefully it's possible to do a workaround through Kopernicus. We should make a new issue for it on the github site.

Edit: Tried it one more time just to confirm: Delete Settings.cfg (or delete TERRAIN secion should do same thing but I did the entire file) start KSP and it works once;. The new terrain quality presets can be accessed. After that when I start the game a second time and every time after that, there is an array index exception (IndexOutOfRangeException) when moving the slider past High. So KSP is loading enough of the list to populate the menu slider but is not loading more than the first three default nodes.

Edit #2: So as things are right now, the only player workaround seems to be to one of:

1. Delete the entire settings.cfg file before starting KSP each time
2. Delete just the TERRAN section. (don't screw it up!)

Edited July 19, 2019 by Starwaster

[Galileo]

Regardless of whether it shows the correct name or not in the menu, the settings cfg is loading the correct terrain setting that you chose. So the issue that is being reported here is small and doesn’t make a difference in game. 

KSP rewrites the settings cfg every single time the game is started from a cache somewhere so you won’t lose your preferred settings, but it does not read the custom settings after loading any time after that, but the choice you make for say JNSQ_X still persists. The names just aren’t displayed properly. This has nothing to do with the performance issues that ppl are having with Kopernicus. Advising people to delete the settings cfg or remove the terrain nodes isn’t going to help anything in that regard.

you can create a new issue on github if you would like, but there are bigger fish to fry than making sure a name is displaying properly in the menu settings.

Edited July 19, 2019 by Galileo

[Jognt]

Just now, Galileo said:

Regardless of whether it shows the correct name or not in the menu, the settings cfg is loading the correct terrain setting that you chose. So the issue that is being reported here is small and doesn’t make a difference in game. 

KSP rewrites the settings cfg every single time the game is started from a cache somewhere so you won’t lose your preferred settings, but it does not read the custom settings after loading any time after that, but the choice you make for say JNSQ_X still persists. The names just aren’t displayed properly. This has nothing to do with the performance issues that ppl are having with Kopernicus.

Yes it is a bit of a tangent I admit. Personally I was unsure whether it made an impact beyond "UI breaks" but I'd rather inspect too many options than too few.

At this point I'm more interested in the dynamic and factors at play for the purpose of improving performance than to blame anyone.

[Starwaster]

2 minutes ago, Galileo said:

Regardless of whether it shows the correct name or not in the menu, the settings cfg is loading the correct terrain setting that you chose. So the issue that is being reported here is small and doesn’t make a difference in game. 

KSP rewrites the settings cfg every single time the game is started from a cache somewhere so you won’t lose your preferred settings, but it does not read the custom settings after loading any time after that, but the choice you make for say JNSQ_X still persists. The names just aren’t displayed properly. This has nothing to do with the performance issues that ppl are having with Kopernicus.

you can create a new issue on github if you would like, but there are bigger fish to fry than making sure a name is displaying properly in the menu settings.

This segment of the discussion was only focusing on the terrain menu setting itself; I don't think ANYONE actually suggested that THIS had to do with people's performance issue. We were only discussing our experience with the terrain quality menu setting.

 

[Galileo]

1 hour ago, Jognt said:

Below is what I see with JNSQ. I was under the impression that was normal. I'll do some checking later with regards to FPS and RoCs.

@Starwaster performance was indeed brought up in regards to this issue, and I just wanted to make sure people weren’t wasting their time looking for problems that have been explained a few different times. I know I have explained this a few times in the JNSQ and GPP threads. I don’t expect people to go diving back to look for those posts, I’m just making sure it’s posted here so that we aren’t beating a dead horse again.

Edited July 19, 2019 by Galileo

[Starwaster]

Just now, Galileo said:

@Starwaster performance was indeed brought up in regards to this issue, and I just wanted to make sure people weren’t wasting their time looking for problems that have been explained a few different times. I know I have explained this a few times in the JNSQ and GPP threads.

No, it LED to this issue because using custom presets was talked about as a possible remedy. When errors start getting thrown while changing the menu then it's only natural that people start talking about THAT.

[Galileo]

1 minute ago, Starwaster said:

No, it LED to this issue because using custom presets was talked about as a possible remedy. When errors start getting thrown while changing the menu then it's only natural that people start talking about THAT.

Ok, man.