Jump to content

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


Thomas P.

Recommended Posts

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.

Link to comment
Share on other sites

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 by Galileo
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by Galileo
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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 by Gordon Fecyk
Don't try this at home.
Link to comment
Share on other sites

@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 by JadeOfMaar
Link to comment
Share on other sites

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 by Thomas P.
Link to comment
Share on other sites

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/

 

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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
			}
		}

 

Link to comment
Share on other sites

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 by OhioBob
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...