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

[Gordon Fecyk]

Backporting biome displayName support to 1.3.0-x release?

I understand KSP 1.3.1 is the current release, but 1.3.1 has this very stupid landing gear collider bug that makes the game unplayable for anyone using SSTO-type craft at places other than Kerbin.

I tried the 1.3.1-3 release on my 1.3.0 installation and lost solar panel functionality, which was easy to fix by just turning off Kopernicus solar panels. But now scatter colliders aren't working either in Stock Visual Terrain. There are probably other things that don't quite work with Kopernicus 1.3.1-3 on KSP 1.3.0.

I wouldn't worry too much about displayName support for biomes in an otherwise stock game, but this is part of my AEK YouTube series and before heading to Duna I put in the Restored Duna Project. I made localization strings for that and they do work on 1.3.1-2. No worries if it's too much trouble, though.

[Galileo]

13 minutes ago, Gordon Fecyk said:

Backporting biome displayName support to 1.3.0-x release?

I understand KSP 1.3.1 is the current release, but 1.3.1 has this very stupid landing gear collider bug that makes the game unplayable for anyone using SSTO-type craft at places other than Kerbin.

I tried the 1.3.1-3 release on my 1.3.0 installation and lost solar panel functionality, which was easy to fix by just turning off Kopernicus solar panels. But now scatter colliders aren't working either in Stock Visual Terrain. There are probably other things that don't quite work with Kopernicus 1.3.1-3 on KSP 1.3.0.

I wouldn't worry too much about displayName support for biomes in an otherwise stock game, but this is part of my AEK YouTube series and before heading to Duna I put in the Restored Duna Project. I made localization strings for that and they do work on 1.3.1-2. No worries if it's too much trouble, though.

Scatter objects not having colliders in SVT is news to me. I just tried and it works fine. Solar panels also seem to be working fine for me.  The only thing I concur with here is the landing gear issue. 

Edited December 5, 2017 by Galileo

[Gordon Fecyk]

Just now, Galileo said:

Scatter objects not having colliders in SVT is news to me. I just tried and it works fine. Solar panels also seem to be working fine for me.

This happened during an attempt to use Kopernicus 1.3.1-3 on KSP 1.3.0, which I think is currently an unsupported combination. There's nothing wrong with SVT or solar panels when I use a supported combination.

Putting Kopernicus 1.3.0-8 back in place of 1.3.1-3 fixed both the solar panels and the scatter colliders, but broke biome displayName displays at Restored Duna.

[Sigma88]

1 minute ago, Gordon Fecyk said:

This happened during an attempt to use Kopernicus 1.3.1-3 on KSP 1.3.0, which I think is currently an unsupported combination. There's nothing wrong with SVT or solar panels when I use a supported combination.

Putting Kopernicus 1.3.0-8 back in place of 1.3.1-3 fixed both the solar panels and the scatter colliders, but broke biome displayName displays at Restored Duna.

Kopernicus 1.3.1-3 shouldn't even load in 1.3.0

it should disable itself to avoid compatibility issues and pop-up an error message that warns you to not start any saved game

[Galileo]

8 minutes ago, Gordon Fecyk said:

This happened during an attempt to use Kopernicus 1.3.1-3 on KSP 1.3.0, which I think is currently an unsupported combination. There's nothing wrong with SVT or solar panels when I use a supported combination.

Putting Kopernicus 1.3.0-8 back in place of 1.3.1-3 fixed both the solar panels and the scatter colliders, but broke biome displayName displays at Restored Duna.

Yeah, Kopernicus is version locked backwards and forwards.  So there is no way Kopernicus 1.3.1-x worked in 1.3.0.

ninja’d by Sigma

Edited December 5, 2017 by Galileo

[suomynonA]

35 minutes ago, Sigma88 said:

I have no idea honestly

 

everything looks fine in the mm cache

There aren't texture size limits or anything are there? All the maps are 4096x2048. Or maybe I screwed up and made the orbit color invisible but I don't think that's it.

[Sigma88]

13 minutes ago, suomynonA said:

There aren't texture size limits or anything are there? All the maps are 4096x2048. Or maybe I screwed up and made the orbit color invisible but I don't think that's it.

I think unity limit is 8k x 8k ?

something like that, 4k x 2k is pretty normal, should work

 

[Gordon Fecyk]

3 hours ago, Sigma88 said:

Kopernicus 1.3.1-3 shouldn't even load in 1.3.0.

You delete .version files and it'll load. No guarantees it'll work, but that's what I get for trying unsupported stuff.

This is Not Recommended. Don't try this at home and don't ask for support if you try it.

Again, no worries because I was just trying out stuff and not expecting anything.

I guess I have to wait for either Squad to fix the wheels (again), or wait for Thomas to consider a backport. Or I could drop Duna Restored. I'll figure it out.

I'm using a version of Restored Duna I modified to support Kopernicus 1.3.1-2 and Stock Visual Terrain, and this fully works on KSP 1.3.1 and Kopernicus 1.3.1-3 including biome displayName support. I just can't go that way because Squad broke the landing gear in Stock KSP 1.3.1. That's a problem for Squad and nothing to do with Kopernicus.

Edited December 5, 2017 by Gordon Fecyk
Don't try this at home.

[JadeOfMaar]

@Gordon Fecyk Please remove your suggestion. Kopernicus version locking saves its devs from going through hoops when providing support for planet packs. It's far better that a planet modder update (or even drop) their mod, or a non-modder change their game version than Thomas and co have to make wasteful moves because the complainant has a version of Kopernicus (or a planet pack) installed that's not optimized for their KSP version.

We don't need users knowing how to defeat the version lock.

Edited December 5, 2017 by JadeOfMaar

[Thomas P.]

25 minutes ago, JadeOfMaar said:

@Gordon Fecyk Please remove your suggestion. Kopernicus version locking saves its devs from going through hoops when providing support for planet packs. It's far better that a planet modder update (or even drop) their mod, or a non-modder change their game version than Thomas and co have to make wasteful moves because the complainant has a version of Kopernicus (or a planet pack) installed that's not optimized for their KSP version.

We don't need users knowing how to defeat the version lock.

Oh, he can keep his suggestion. It is useless since Kopernicus doesn't use the version file (actually no mod does - thats just visual stuff for the KSP-AVC users). The version checking is baked into the dll and unless you know what you are doing it is impossible to remove it.

Actually on the topic of backports: I did backports in the past and it was an utter pain. Also, back then, Kopernicus could use pretty much the same code between both versions (1.2.2 and 1.3). This changed with 1.3.1, since now for example sunflares are handled fundamentally different and it would be even more work to port everything back to how it worked before. So sorry, I am currently not going to do backports again.

Edited December 5, 2017 by Thomas P.

[Electrocutor]

Noticed you packed the older MM 2.8 with this instead of 3.0; is there a reason?

[Thomas P.]

3.0 wasn't released at the time I released 1.3.1-3 and I am not going to make an update just for a new MM version when the one that is shipped still works.

[Kangroozeeh]

Is there a download link to RELEASE 2 somewhere? The new update borked everything for me

[OhioBob]

8 hours ago, suomynonA said:

https://www.dropbox.com/s/q6fo45d6hqalarp/Info.zip?dl=0 Here's hoping I got everything, as far as I know the only mod I'm using is kopernicus. I'm pretty sure I reinstalled the game a few months ago and kept it clean.

Is the following case sensitive?  Try it without the all caps.

@Kopernicus:AFTER[KOPERNICUS]

 

2 hours ago, Kangroozeeh said:

Is there a download link to RELEASE 2 somewhere? The new update borked everything for me

https://github.com/Kopernicus/Kopernicus/releases/

 

[suomynonA]

3 hours ago, OhioBob said:

Is the following case sensitive?  Try it without the all caps.

@Kopernicus:AFTER[KOPERNICUS]

 

https://github.com/Kopernicus/Kopernicus/releases/

 

Tried it, same result, it's as if the planet completely doesn't exist.

[Jalaris]

@Thomas P. @Galileo Galileo, I saw that you are using the kopernicus asteroids and created a config for belts and whatnot in GPP. I was wondering if you know if Kopernicus asteroids come default with the stock system when installed, and if not, do you know anywhere or anyone that has made an asteroid.cfg for it already?  I googled and looked around but haven't found anything so far.

[Galileo]

6 hours ago, Jalaris said:

@Thomas P. @Galileo Galileo, I saw that you are using the kopernicus asteroids and created a config for belts and whatnot in GPP. I was wondering if you know if Kopernicus asteroids come default with the stock system when installed, and if not, do you know anywhere or anyone that has made an asteroid.cfg for it already?  I googled and looked around but haven't found anything so far.

Yes stock alread comes with asteroids. “Kopernicus asteroids” are the stock asteroids, altered to work with planet packs so long as you have a cfg, like in GPP

[OhioBob]

@suomynonA, I think I found the problem.  The following is a partial copy of your planet cfg:

@Kopernicus:AFTER[Kopernicus]
{
	Body
	{
		name = Ringo
		cacheFile = Ringo/Cache/Ringo.bin
		Template
		{
			name = Laythe
			removeAllPQSMods = true
		}
		Properties
		{
			description = Likely candidate for habitation
			radius = 5737010
			geeASL = 0.96
			isHomeWorld = false
			tidallyLocked = false
			rotationPeriod = 57600
			timewarpAltitudeLimits = 0 5000 20000 35000 50000 100000 300000
			ScienceValues
			{
				landedDataValue = 7
				splashedDataValue = 2
				flyingLowDataValue = 1
				flyingHighDataValue = 1
				inSpaceLowDataValue = 6
				inSpaceHighDataValue = 5.25
				recoveryValue = 6
				flyingAltitudeThreshold = 50000
				spacealtitudeThreshold = 400000
			}
		}
	}	
	ScaledVersion
	{
		...

The close bracket right above ScaledVersion closes the Body node. ScaledVersion and everything that follows must be inside the Body node.  Remove the close bracket right above ScaledVersion and replace it with one at the very end of the file.

I also don't know what's up with your Atmosphere node, but it has massive amounts of unneeded tabs and/or line breaks.  I don't know if that's messing anything up or not, but it probably should be cleaned up.  Below is a cleaned up version of your atmosphere code if you want to use it.

		Atmosphere
		{
			ambientColor = 0.4,0.4,0.5.1.0
			lightColor = 0.4,0.5,0.6.1.0
			altitude = 79000
			enabled = true
			oxygen = true
			temperatureSeaLevel = 275
			temperatureCurve
			{
				key = 0 273 0.00000E+00 -2.64000E-03
				key = 12500 240 -2.64000E-03 -3.20000E-03
				key = 25000 200 -3.20000E-03 -2.40000E-03
				key = 37500 170 -2.40000E-03 -1.60000E-03
				key = 50000 150 -1.60000E-03 -6.00000E-04
				key = 75000 135 -6.00000E-04 -4.00000E-03
				key = 80000 115 -4.00000E-03 -1.87500E-03
				key = 88000 100 -1.87500E-03 0.00000E+00
			}
			temperatureSunMultCurve
			{
				key = 0 1 0.00000E+00 -6.00000E-05
				key = 20000 -0.2 -6.00000E-05 1.33333E-05
				key = 50000 0.2 1.33333E-05 0.00000E+00
				key = 60000 0.2 0.00000E+00 -5.00000E-06
				key = 70000 0.15 -5.00000E-06 -5.00000E-06
				key = 80000 0.1 -5.00000E-06 -2.50000E-06
				key = 88000 0.08 -2.50000E-06 0.00000E+00
			}
			temperatureLatitudeBiasCurve
			{
				key = 0 13.99 0 -0
				key = 38 0 -0.7092 -0.7092
				key = 90 -52.01 -1.1519 0
			}
			temperatureLatitudeSunMultCurve
			{
				key = 0 5 0 -0
				key = 38 4.36 -0.0322 -0.0322
				key = 90 2 -0.0524 0
			}
			temperatureAxialSunBiasCurve
			{
				key = 0 -0.49 -0.006 -0.006
				key = 35 -0.6 -0 -0
				key = 125 -0 0.0105 0.0105
				key = 215 0.6 0 0
				key = 305 0 -0.0105 -0.0105
				key = 360 -0.49 -0.006 -0.006
			}
			temperatureAxialSunMultCurve
			{
				key = 0 0 0 0
				key = 38 0.5 0.02 0.02
				key = 90 1 0 0
			}
			temperatureEccentricityBiasCurve
			{
				key = 0 3.82 0 -7.64
				key = 1 -3.82 -7.64 0
			}
			pressureCurve
			{
				key = 0 6.75838E+01 0.00000E+00 -1.07907E-02
				key = 3000 4.15609E+01 -6.83774E-03 -6.83774E-03
				key = 6000 2.51810E+01 -4.27159E-03 -4.27159E-03
				key = 9000 1.50171E+01 -2.62929E-03 -2.62929E-03
				key = 12000 8.80550E+00 -1.59304E-03 -1.59304E-03
				key = 15000 5.06343E+00 -9.53362E-04 -9.53362E-04
				key = 17000 3.45620E+00 -6.69500E-04 -6.69500E-04
				key = 20000 1.90825E+00 -3.86379E-04 -3.86379E-04
				key = 23000 1.02570E+00 -2.17044E-04 -2.17044E-04
				key = 26000 5.35978E-01 -1.18300E-04 -1.18300E-04
				key = 29000 2.73194E-01 -6.24883E-05 -6.24883E-05
				key = 31000 1.71942E-01 -4.03063E-05 -4.03063E-05
				key = 34000 8.39789E-02 -2.04499E-05 -2.04499E-05
				key = 37000 3.98684E-02 -1.01011E-05 -1.01011E-05
				key = 40000 1.84276E-02 -4.80753E-06 -4.80753E-06
				key = 43000 8.33464E-03 -2.23556E-06 -2.23556E-06
				key = 46000 3.68523E-03 -1.01714E-06 -1.01714E-06
				key = 48000 2.11067E-03 -5.94061E-07 -5.94061E-07
				key = 51000 8.96675E-04 -2.58409E-07 -2.58409E-07
				key = 54000 3.75967E-04 -1.09552E-07 -1.09552E-07
				key = 57000 1.56114E-04 -4.60020E-08 -4.60020E-08
				key = 60000 6.41810E-05 -1.91281E-08 -1.91281E-08
				key = 62000 3.52835E-05 -1.05981E-08 -1.05981E-08
				key = 65000 1.42552E-05 -4.33283E-09 -4.33283E-09
				key = 68000 5.69707E-06 -1.75254E-09 -1.75254E-09
				key = 71000 2.25155E-06 -7.01115E-10 -7.01115E-10
				key = 74000 8.79692E-07 -2.77337E-10 -2.77337E-10
				key = 76000 4.65189E-07 -1.51718E-10 -1.51718E-10
				key = 79000 0 0 0
			}
		}

 

[suomynonA]

So I tried those and it fixed everything enough to give me an error at least. https://www.dropbox.com/s/zbcrjn48eccsra4/Info.zip?dl=0 Same modlist as before (only kopernicus) and current version of ksp.

[OhioBob]

@suomynonA, what's this?  Is that path correct?  Why is it not using the GameData folder?

			texture = AdvancedExploration\Ringo\PluginData\Ringo_color.dds

 

[suomynonA]

Just now, OhioBob said:

@suomynonA, what's this?  Is that path correct?  Why is it not using the GameData folder?

			texture = AdvancedExploration\Ringo\PluginData\Ringo_color.dds

 

Ah, forgot to change the path, I'll see if that fixes it.

[suomynonA]

22 minutes ago, suomynonA said:

Ah, forgot to change the path, I'll see if that fixes it.

Nope.

[OhioBob]

I've got a problem that just doesn't make a lot of sense to me.  I've got one body in an eleven body planet pack that won't create a cache file.  The body loads up in the game just fine and everything looks OK, but I get only 10 out of 11 .bin files in my cache folder.  This one body just refuses to produce a cache file.  Its cfg is essentially identical to the others.  In fact, I tried recreating the cfg from a copy of one of the others that is known to work, but still no cache file.  All the logs look good from what I can tell.  The only difference that I can see in any of the logs is that the Kopernicus logs for the bodies producing cache files include the following,

[LOG 23:21:19]: Brovo is using custom cache file 'C:/Program Files/Kerbal Space Program 131 GPP 1588 GEP/KSP_x64_Data/../GameData\GEP/Cache/Brovo.bin' in 'C:/Program Files/Kerbal Space Program 131 GPP 1588 GEP/KSP_x64_Data/../GameData\GEP/Cache'
[LOG 23:21:19]: Body.PostApply(ConfigNode): Loading cached scaled space mesh: Brovo

while those lines are missing from the log for the body for which I'm having the problem.  Does anybody have any ideas on what could be causing this problem?  Help please.

(edit)

Here's a new test I just tried.  I took one of the working cfgs and made a copy of it with a new file name.  I then made minimal edits to the file, changing only the body name, the cache file name, and the referenceBody.  With those changes only, it produced a cache file.  

I next made additional edits to the "Properties" node; changing description, radius, geeASL, initialRotation, and timewarpAltitudeLimits.  I then deleted the cache file and restarted.  With these additional changes, no cache file was generated.  When I reverse those changes and go back to the previous properties settings, the cache is again generated.

How can those few simple edits to the Properties affect whether or not a cache file is generated?

(edit #2)

OK, I've isolated the problem to the radius, and I'm pretty sure I know now what's happening.  By coincidence my body's radius just happens to be exactly the same as the template.  As long as I use a radius that's different from the template, I get a cache file.  But when the radii match, no cache file is generated.

Is that intended behavior?  Should no cache file be generated when the planet radius matches that of the template?  I can say from my experience here that my body doesn't look right when no cache file is generated.  It looks much better when I force Kopernicus to generate a cache (by changing the radius just a little bit).  I suggest that you edit your code to force the generation of a cache file even when the radii match.

 

Edited December 8, 2017 by OhioBob

[Sigma88]

@OhioBob

Add

Debug

{

update = true

}

 

In the Body node and it will force kopernicus to export the cache

[OhioBob]

Thanks, @Sigma88.  You're solution works great.  I'm just sorry I had to waste a couple hours chasing down the source of the problem.

On ‎12‎/‎6‎/‎2017 at 3:38 PM, suomynonA said:

Nope.

I don't know if it's the source of your problem or not, but I just noticed another error in your config.  timewarpAltitudeLimits requires 8 values, you have only 7.