Jump to content

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

Thomas P.

By Thomas P.
in KSP1 Mod Releases

 Share

Recommended Posts

JadeOfMaar

JadeOfMaar

Posted
Posted

@HebaruSan Try this. The values are a multiple of the planet's radius with the decimal point shifted forward 3 places. I don't know what the logic for this is called.

Quote 

outerRadius = 40000
innerRadius = 30000

This should translate into this

Quote

outerRadius = 40.000x the planet's width
innerRadius = 30.000x the planet's width

 

Link to comment
Share on other sites
OhioBob

OhioBob

Posted
Posted (edited)
1 hour ago, HebaruSan said:

What are the units for ring radius? I assumed it would be kilometers, but putting this around the Sun: 


                outerRadius = 40000
                innerRadius = 30000

... gives me a ring just inside of Eve's orbit, which is 9 billion meters in radius. I see no sane conversion from one set of figures to the other.

The units are body radii, with 3 implied decimal places, and measured from the center of the body.  So the numbers 30000 and 40000 means that the rings extend from 30 to 40 radii from the center of the sun, where 1 solar radius = 261,600 km.

(edit 1)  Oops, I didn't see that the question has already been answered.

(edit 2)  Also note that the inner and outer radii mark the inner and outer edges of the ring texture.  It's possible the texture could be transparent in parts, making the ring appear smaller than the texture.

 

Edited by OhioBob
Link to comment
Share on other sites
The White Guardian

The White Guardian

Posted
Posted
16 hours ago, HebaruSan said:

What are the units for ring radius? I assumed it would be kilometers, but putting this around the Sun: 


                outerRadius = 40000
                innerRadius = 30000

... gives me a ring just inside of Eve's orbit, which is 9 billion meters in radius. I see no sane conversion from one set of figures to the other.

Although the question has been answered already, I wouldn't mind writing a console application to do the number crunching...

Link to comment
Share on other sites
KerbMav

KerbMav

Posted
Posted (edited)
On 6.7.2017 at 11:59 PM, OhioBob said:

Of course you'll have to adjust the orbits of the other planets as well, or else Kerbin will be out of plane with all of them.  You will likely also have to adjust the longitudeOfAscendingNode (LAN) of many of the planets.  For instance, suppose you incline Kerbin's orbit 20 degrees.  Let's say you want Duna to have a similar inclination of somewhere around 19-21 degrees.  If you change Duna's inclination without changing its LAN, Duna's orbit will be tilted by the correct amount, but in an entirely wrong direction.  This is because Kerbin LAN equals 0 degrees, and Duna's LAN equals 135.5 degrees.  You will have to change Duna's LAN to something close to 0 degrees so that the orbital planes end up relatively close to one another.
 

Checking the wiki shows me I underestimated the effect even half a degree inclination will have on an orbit ...

OK, lets not talk about planets, moons then: The all to often occuring eclipses bother me to a marginal degree - with how much inclination for the Mun could I get away with without creating to much trouble like you described above? Less inclination needed the higher the orbit is, yes?

Edited by KerbMav
Link to comment
Share on other sites
OhioBob

OhioBob

Posted
Posted (edited)
22 hours ago, KerbMav said:

Checking the wiki shows me I underestimated the effect even half a degree inclination will have on an orbit ...

OK, lets not talk about planets, moons then: The all to often occuring eclipses bother me to a marginal degree - with how much inclination for the Mun could I get away with without creating to much trouble like you described above? Less inclination needed the higher the orbit is, yes?

Mun and Kerbin have the same LAN, so that simplifies things.  To stop solar eclipses from happening every new-Mun, you'll have to give Kerbin and Mun different inclinations.  Anything less than a couple degrees difference in inclination means that you'll still have at least a partial eclipse every orbit, with Mun's limb grazing the Sun.  For there to be a clear separation between Mun and Sun (at the times of greatest separation), the difference in the inclinations needs to be greater than 2 degrees.  How much greater is entirely up to you.  Mun will pass directly over the face of the Sun only when new-Mun occurs at the same time that Mun at or near one of its nodes*.  Be advised that inclining Mun's orbit means that it will no longer orbit around Kerbin's equator.  This means that getting to Mun will be more difficult, much like getting to Minmus.

* Note that total solar eclipses shouldn't ever occur in KSP.  This is because Mun has a smaller apparent diameter than Sun when viewed from Kerbin (1.9o vs. 2.2o).  Solar eclipse should actually be of the annular type.  The fact that Sun completely disappears during a solar eclipse is an error.**

** It looks to me that the Sun behaves as a point source of light.  A body doesn't need to completely cover the Sun to produce an eclipse, it just needs to cover the center point.  When the center point is covered, the sunflare is extinguished, and when the center point is uncovered, the sunflare returns.  The same thing happens during sunrises and sunsets.  This is why Mun is able to produce what looks like total solar eclipses even though it shouldn't.
 

Edited by OhioBob
Link to comment
Share on other sites
KerbMav

KerbMav

Posted
Posted
On 6.7.2017 at 11:59 PM, OhioBob said:

You would have to do something like this: 


@Kopernicus:AFTER[Kopernicus]
{
	@Body[Kerbin]
	{
		@Orbit
		{
			inclination = 0		//enter amount of inclination in degrees, where inclination = axial tilt
		}
	}
}

 

After several tries that did nothing - I corrected the typo in Koperniucs ... was that a test?! :D:D:D 

Link to comment
Share on other sites
OhioBob

OhioBob

Posted
Posted
35 minutes ago, KerbMav said:

After several tries that did nothing - I corrected the typo in Koperniucs ... was that a test?! :D:D:D 

Woops.  Sorry about that.  I've fixed my original post so it doesn't happen again to somebody else.

Link to comment
Share on other sites
Galileo

Galileo

Posted
Posted
23 minutes ago, daniel l. said:

I've been out of the loop for a while, is it true that Kopernicus now has multiple light sources? @Thomas P. ?

Yes, Thomas P. and Sigma88 have worked out a way to support multiple stars, allowing solar panels to work properly as well.

Link to comment
Share on other sites
daniel l.

daniel l.

Posted
Posted
1 minute ago, Galileo said:

Yes, Thomas P. and Sigma88 have worked out a way to support multiple stars, allowing solar panels to work properly as well.

Well. I will have to check this out! :D That was my biggest all-time frustration. 

Link to comment
Share on other sites
OhioBob

OhioBob

Posted
Posted
14 hours ago, daniel l. said:

Well. I will have to check this out! :D That was my biggest all-time frustration. 

It was frustrating for the GPP developers as well.  We have a two-star system and struggled for months trying to figure out how to deal with the solar panel bug.  Kopernicus 1.2.2-9 and 1.3.0-4 now fixes it.  Kopernicus now correctly recognizes the difference in the stars' luminosities and adjusts the output of solar panels accordingly.  Be advised, however, if you use the mod Kerbalism, it doesn't play well with Kopernius Solar Panels.  Kerbalism still need to figure out a solution and catch up.  That's the only bug that I'm aware of. 

Link to comment
Share on other sites
Sigma88

Sigma88

Posted
Posted
4 hours ago, The White Guardian said:

I keep noticing terrain-scatter related issues. I'll try reproducing and submitting a bug report.

if landcontrol is involved a fix has already been found and will be included in the next release

Link to comment
Share on other sites
Galileo

Galileo

Posted
Posted (edited)
4 hours ago, The White Guardian said:

I keep noticing terrain-scatter related issues. I'll try reproducing and submitting a bug report.

I already created a land control issue on github, and it has been fixed for the next update as far as I know. Hopefully that's soon. 

edit: ninja'd by Sigma

Edited by Galileo
Link to comment
Share on other sites
Gameslinx

Gameslinx

Posted
Posted

Hey guys!

Messing around with multiple stars within the same system (a star orbits Kerbol). I have a few log errors regarding something to do with 'solar flux'. I've identified the log errors so i'll post them below, but i'll also attach the config file for the star and the kopernicus.log // body.log. The following is taken from the Output.log. This is spammed when the star comes into view. 

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

TimingFI threw during Update: System.NullReferenceException: Object reference not set to an instance of an object
  at Kopernicus.Components.KopernicusStar.Flux (ModularFI.ModularFlightIntegrator fi, Kopernicus.Components.KopernicusStar star) [0x00000] in <filename unknown>:0 
  at Kopernicus.Components.KopernicusStar.SunBodyFlux (ModularFI.ModularFlightIntegrator flightIntegrator) [0x00000] in <filename unknown>:0 
  at ModularFI.ModularFlightIntegrator.CalculateSunBodyFlux () [0x00000] in <filename unknown>:0 
  at FlightIntegrator.ThermoPrecalculate () [0x00000] in <filename unknown>:0 
  at FlightIntegrator.Update () [0x00000] in <filename unknown>:0 
  at ModularFI.ModularFlightIntegrator.TimedUpdate () [0x00000] in <filename unknown>:0 
  at TimingFI.Update () [0x00000] in <filename unknown>:0

'Object reference not set to an instance of an object' shows I must have messed up a name somewhere, but i've checked the config many times and I cannot see any issues with it. I've placed comments in the code where i've removed parts of it because of identity mismatches between Kittopia and the exports on Github.

Config, output log, kopernicus log and body log attached here:

https://www.dropbox.com/s/zt0vc7064orthis/Star logs.zip?dl=0

Any help would be greatly appreciated. Thanks guys :)

Link to comment
Share on other sites
OhioBob

OhioBob

Posted
Posted (edited)

@Gameslinx, I haven't looked at the logs, but I have looked over you config.  I've got several comments to share with you, but I'm not sure if any of this will fix your problem.

  • SolarPowerCurve is a relic from the past and doesn't do anything.  I see that you have it commented out, but you should probably just delete it.
  • Do you really want the atmosphere to have oxygen?
  • You don't need an albedo for stars, but even still, albedo goes under the Properties node, not the Atmosphere node.*
  • I don't think temperatureLapseRate and gasMassLapseRate do anything (I believe they're obsolete), so you should probably delete them.
  • Hydrogen in stars is monatomic, not molecular.  Therefore atmosphereMolarMass should be about half what you have it.
  • The adiabaticIndex should be 1.667, which is typical for monatomic gases.
  • You haven't given the star a luminosity.  The star should be given a luminosity or else you'll get the same value as the template.

Here's some more explanation about luminosity.  In real life luminosity is the total energy emitted by a star per unit time.  In KSP, however, luminosity is the solar flux at the distance from a star equal to the distance of the home world from its star.  In the case of the stock sun, luminosity = 1360.  This means that the solar flux at Kerbin (13.6 Gm from the sun) is equal to 1360 W/m2.  Whatever luminosity you give to a different star in the same universe, that will be the solar flux at a distance of 13.6 Gm from that star.  The ratio of the luminosities as defined in KSP is directly proportional to the ratio of the luminosities as defined in real life.  So if you have a star that has 1/2 the total energy output of the stock sun, you should assign it a luminosity of 680.  I always use the parameter "luminosity", I don't know if "solarLuminosity" is also valid of not.

* I don't know where this error originated, but it's been copied over and over again from one config to another.
 

Edited by OhioBob
Link to comment
Share on other sites
Gameslinx

Gameslinx

Posted
Posted
11 minutes ago, OhioBob said:

snip

Cheers for pointing those out. I'll edit the atmosphere config (i overlooked oxygen it seems...)

I've added a luminosity (350), removed the lapse rates and albedo values and changed the adiabatic index to 1.667. 

 

However the error is still there being spammed in the log. Thanks for the corrections, though - i may have overlooked them in the future!

Link to comment
Share on other sites
OhioBob

OhioBob

Posted
Posted
Just now, Gameslinx said:

However the error is still there being spammed in the log.

That doesn't surprise me.  My suggestions were things to help clean up the config, not necessarily suggestions for fixing the immediate problem.  There is really nothing obvious that I can see that would be generating the error.

Link to comment
Share on other sites
OhioBob

OhioBob

Posted
Posted

@Gameslinx, I just noticed something in your logs.  It seems that for some reason Kopernicus isn't picking up your atmosphere.  For example, Olu'um.Body.log is showing the following: 

[LOG 14:16:06]: atmosphereDepth = 600000
[LOG 14:16:06]: atmosphereTemperatureSeaLevel = 5840
[LOG 14:16:06]: atmospherePressureSeaLevel = 16
[LOG 14:16:06]: atmosphereMolarMass = 0.0022
[LOG 14:16:06]: atmosphereAdiabaticIndex = 1.43

Those are the values for the original stock sun.  It's using the values of the template rather than your values.  I don't see anything in your config that could be causing this.  There could be some tiny glitch in your formatting that's just going unnoticed.

You could try comparing your config to Grannus.cfg from GPP.  Grannus is the second star in a binary system.  It has been working fine for us.

 

 

Link to comment
Share on other sites
OhioBob

OhioBob

Posted
Posted (edited)

@Gameslinx, I just went through your Olu'um config and made a few changes.  I added it to my stock game (both 1.2.2 and 1.3.0) and it is now working fine for me.  I'm also not getting any NullReferenceException.  I'm not entirely sure which one of the changes I made fixed the problem, but the problem is fixed as far as I can tell.  Here's Olu'um.cfg with my changes: 

@Kopernicus:FOR[GPO]
{
	Body
	{
		name = Olu'um
		// flightGlobalsIndex = 185		
		// cacheFile = Olei/Cache/Supergiant.bin
		Template
		{
			name = Sun
		}	
		Properties
		{
			description = Olu'um is a sub-star. It's very close to being massive enough to ignite. If Olu'um swallows much more of its accretion disk, there's a good chance it will become a tiny star. If this happens, it will not be good for the planets in its system, as they would all burn to a crisp.
			radius = 10000000      
			geeASL = 0.4
			rotates = true
			rotationPeriod = 15000
			tidallyLocked = false
			initialRotation = 0
			isHomeWorld = false
			timewarpAltitudeLimits = 0 20109 40219 80438 160875 321750 643500 1287000
			ScienceValues
			{
				landedDataValue = 0
				splashedDataValue = 0
				flyingLowDataValue = 8.5
				flyingHighDataValue = 8
				inSpaceLowDataValue = 2.5
				inSpaceHighDataValue = 2
				recoveryValue = 0
				flyingAltitudeThreshold = 100000
				spaceAltitudeThreshold =  350000000
			}
		}
		Orbit
		{
			referenceBody = Sun
			color = 0.415686,0.352941,0.803922,1
			inclination = 0
			eccentricity = 0
			semiMajorAxis = 53394283856
			longitudeOfAscendingNode = 259
			argumentOfPeriapsis = 0
			meanAnomalyAtEpoch = 2.27167344093323
			epoch = 99.6799999999973
		}
		Atmosphere
		{
			ambientColor = 0.781,0.882,0.697,1
			lightColor = 0.781,0.882,0.697,1
			enabled = true
			oxygen = false
			altitude = 405000.0
			staticPressureASL = 607.95
			pressureCurve
			{
				key = 0 607.95
				key = 20000 607.94
				key = 40000 600.036
				key = 60000 590.5595
				key = 80000 570.8192
				key = 100000 530.40557
				key = 120000 500.71404
				key = 140000 450.02383
				key = 170000 310.416679
				key = 200000 300.184984
				key = 300000 290.0716413
				key = 400000 240.0237546
				key = 403000 10
				key = 405000 0 0 0
			}
			pressureCurveIsNormalized = false            
			temperatureSeaLevel = 3400
			temperatureCurve
			{
				key = 0 3500 
				key = 15750 3000
				key = 83250 2500
				key = 133750 1000
				key = 189750 500
				key = 260000 100
				key = 400000 50
				key = 403000 1
				key = 405000 0
			}
			temperatureCurveIsNormalized = false
			adiabaticIndex = 1.667
			atmosphereMolarMass = 0.0014
		}
		ScaledVersion
		{
			Light
			{
				sunlightColor = 1,0.6573034,0.758427,1
				sunlightIntensity = 1
				scaledSunlightColor = 1,0.6573034,0.758427,1
				scaledSunlightIntensity = 1
				IVASunColor = 1,0.6573034,0.758427,1
				IVASunIntensity = 1
				ambientLightColor = 0.9420224,0.7191012,0.8764045,1
				sunLensFlareColor = 0.5393258,0.02808989,0.3146067,1
				sunAU = 21841200
				luminosity = 350
				brightnessCurve
				{
					key = -0.02 0.4 0 0
					key = 0.01 0.4 0 0
					key = 0.1 4 0 0
					key = 0.2 4 0 0
					key = 0.8 4 0 0
				}
			}
			Material
			{
				emitColor0 = 0.3033708,0.8988764,0.6179775,1
				emitColor1 = 1,0.8370786,1,1
				sunspotColor = 0.2471908,0.1235956,0.1797753,1
				sunspotPower = 1
				sunspotTex = BUILTIN/sunsurfacenew
				rimColor = 0.6573033,0.3146068,0.5730336,1
				rimPower = 0
				rimBlend = 3
			}
		}
	}
}

Most of my changes were things we already discussed, or just simple format cleanup (indentation, etc.).  I've commented out flightGlobalsIndex and cacheFile.  In GPP we found that assigning flightGlobalsIndex numbers started messing with the sequence of contracts being received.  I think the working theory at this point is that it works better if we just let Kopernicus assign the index numbers.  I removed cacheFile only because I didn't know exactly how to set up your file structure.  You can certainly re-enable that.  Something else that you'll want to change back is sunspotTex.  I changed it to the builtin texture only because I didn't have your texture.  I also added sunspotPower, though I'm not 100% certain what that does (I assume it controls how strongly visible the sunspots are).  You'll have to play around with it.

I suspect that whatever fixed the problem was just in the format cleanup.  This is the second time in the last month or two in which somebody was having a problem with a config that I was able to fix just by going through the file and reformatting indentation, line spacing, etc. (I always use tab for indentation, no spaces).  There's apparently just some small thing in there that Kopernicus doesn't like.  It pays to keep things neat and clean.

I also recommend that you add some in and out slopes to pressureCurve and temperatureCurve. 

 

Edited by OhioBob
Link to comment
Share on other sites
Gameslinx

Gameslinx

Posted
Posted
24 minutes ago, OhioBob said:

@Gameslinx, I just went through your Olu'um config and made a few changes.  I added it to my stock game (both 1.2.2 and 1.3.0) and it is now working fine for me.  I'm also not getting any NullReferenceException.  I'm not entirely sure which one of the changes I made fixed the problem, but the problem is fixed as far as I can tell.  Here's Olu'um.cfg with my changes: 


@Kopernicus:FOR[GPO]
{
	Body
	{
		name = Olu'um
		// flightGlobalsIndex = 185		
		// cacheFile = Olei/Cache/Supergiant.bin
		Template
		{
			name = Sun
		}	
		Properties
		{
			description = Olu'um is a sub-star. It's very close to being massive enough to ignite. If Olu'um swallows much more of its accretion disk, there's a good chance it will become a tiny star. If this happens, it will not be good for the planets in its system, as they would all burn to a crisp.
			radius = 10000000      
			geeASL = 0.4
			rotates = true
			rotationPeriod = 15000
			tidallyLocked = false
			initialRotation = 0
			isHomeWorld = false
			timewarpAltitudeLimits = 0 20109 40219 80438 160875 321750 643500 1287000
			ScienceValues
			{
				landedDataValue = 0
				splashedDataValue = 0
				flyingLowDataValue = 8.5
				flyingHighDataValue = 8
				inSpaceLowDataValue = 2.5
				inSpaceHighDataValue = 2
				recoveryValue = 0
				flyingAltitudeThreshold = 100000
				spaceAltitudeThreshold =  350000000
			}
		}
		Orbit
		{
			referenceBody = Sun
			color = 0.415686,0.352941,0.803922,1
			inclination = 0
			eccentricity = 0
			semiMajorAxis = 53394283856
			longitudeOfAscendingNode = 259
			argumentOfPeriapsis = 0
			meanAnomalyAtEpoch = 2.27167344093323
			epoch = 99.6799999999973
		}
		Atmosphere
		{
			ambientColor = 0.781,0.882,0.697,1
			lightColor = 0.781,0.882,0.697,1
			enabled = true
			oxygen = false
			altitude = 405000.0
			staticPressureASL = 607.95
			pressureCurve
			{
				key = 0 607.95
				key = 20000 607.94
				key = 40000 600.036
				key = 60000 590.5595
				key = 80000 570.8192
				key = 100000 530.40557
				key = 120000 500.71404
				key = 140000 450.02383
				key = 170000 310.416679
				key = 200000 300.184984
				key = 300000 290.0716413
				key = 400000 240.0237546
				key = 403000 10
				key = 405000 0 0 0
			}
			pressureCurveIsNormalized = false            
			temperatureSeaLevel = 3400
			temperatureCurve
			{
				key = 0 3500 
				key = 15750 3000
				key = 83250 2500
				key = 133750 1000
				key = 189750 500
				key = 260000 100
				key = 400000 50
				key = 403000 1
				key = 405000 0
			}
			temperatureCurveIsNormalized = false
			adiabaticIndex = 1.667
			atmosphereMolarMass = 0.0014
		}
		ScaledVersion
		{
			Light
			{
				sunlightColor = 1,0.6573034,0.758427,1
				sunlightIntensity = 1
				scaledSunlightColor = 1,0.6573034,0.758427,1
				scaledSunlightIntensity = 1
				IVASunColor = 1,0.6573034,0.758427,1
				IVASunIntensity = 1
				ambientLightColor = 0.9420224,0.7191012,0.8764045,1
				sunLensFlareColor = 0.5393258,0.02808989,0.3146067,1
				sunAU = 21841200
				luminosity = 350
				brightnessCurve
				{
					key = -0.02 0.4 0 0
					key = 0.01 0.4 0 0
					key = 0.1 4 0 0
					key = 0.2 4 0 0
					key = 0.8 4 0 0
				}
			}
			Material
			{
				emitColor0 = 0.3033708,0.8988764,0.6179775,1
				emitColor1 = 1,0.8370786,1,1
				sunspotColor = 0.2471908,0.1235956,0.1797753,1
				sunspotPower = 1
				sunspotTex = BUILTIN/sunsurfacenew
				rimColor = 0.6573033,0.3146068,0.5730336,1
				rimPower = 0
				rimBlend = 3
			}
		}
	}
}

Most of my changes were things we already discussed, or just simple format cleanup (indentation, etc.).  I've commented out flightGlobalsIndex and cacheFile.  In GPP we found that assigning a flightGlobalsIndex numbers started messing with the sequence of contracts being received.  I think the working theory at this point is that it works better if we just let Kopernicus assign the index numbers.  I removed cacheFile only because I didn't know exactly how to set up your file structure.  You can certainly re-enable that.  Something else that you'll want to change back is sunspotTex.  I changed it to the builtin texture only because I didn't have your texture.  I also add sunspotPower, though I'm not 100% certain what that does (assume it controls how strongly visible the sunspots are).  You'll have to play around with it.

I suspect that whatever fixed the problem was just in the format cleanup.  This is the second time in the last month or two in which somebody was having a problem with a config that I was able to fix just by going through the reformatting indentation, line spacing, etc.  There's apparently just some small thing in there that Kopernicus doesn't like.  It pays to keep things neat and clean.

I also recommend that you add some in and out slopes to pressureCurve and temperatureCurve. 

 

For the slopes, I don't have any means of visually editing them - I just visualise it as best I can.

Thanks for the work on the config! I will test it when i am home on Tuesday. I pray that it works - thank you!

4 hours ago, OhioBob said:

You could try comparing your config to Grannus.cfg from GPP.  Grannus is the second star in a binary system

I was comparing it to Valentine from Extrasolar. That might explain the outdated nodes...

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.

×
 Share
Go to topic listing
×
×
  • Create New...