Jump to content

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


Thomas P.

Recommended Posts

2 hours ago, Galileo said:

I don't know what the issue is.  It took me forever to figure it out because I don't use Macs or Linux.  I made 2 versions for my planet pack.  One for macs and Linux and one for Windows.  The only major downside of having to set everything as Png is the amount of ram they use. 

Ah, so if it weren't for the memory thing, it would almost make sense to go with PNG as a best practice in planet packs, given both the Mac/Linux and dx11 proclivities for choking on dds.  Memory was never a problem for me, I'd start becoming concerned at about 20-24GB of usage for the game.  I do wonder if there's some other way to package the mods so that they're platform agnostic?

 

1 hour ago, komodo said:

I'd be curious to find if it is a Linux/Mac thing, or an OpenGL thing: does the same issue happen on Windows when forced to OpenGL?

(I'd have used a sed regex, but to each their own :P )

Oh, the Perl script calls sed to modify the .cfg files.  It would have taken a lot more work to actually use the file I/O in Perl when you can just launch a system command from the script to do the same thing.  Perl is mostly useful for generating and manipulating the filenames to convert from/to, and for using similar information to feed to sed in order to modify the configs.  This is meant to be run under the OPM directory before it's copied to KSP's GameData folder.  Yeah, it's inefficient as it searches every config for each string to replace, but that's not the bulk of the processing.  I mainly just wanted to get the mod to work correctly, it could certainly be more thorough and a bit more elegant.  It's specific to OPM but would probably work with a slight bit of modification for other mods that are only distributed with dds.

 

#!/usr/bin/perl

my @ddsfiles = `find CTTP OPM -name "*color.dds" -o -name "*normal.dds"`;
my @configs = `find CTTP OPM -name "*.cfg"`;

## backup existing config files
foreach my $config (@configs) {	
	chomp $config;
	print "Backing up $config to $config.bak\n";
	system "cp $config $config.bak";
	}

foreach my $ddsfile (@ddsfiles) {
	chomp $ddsfile;
	(my $pngfile = $ddsfile) =~ s/\.[^.]+$//;
	$pngfile .= ".png";

	print "Converting $ddsfile \>\> $pngfile\n";
	system "convert $ddsfile $pngfile";

	my @fileparts = split '/', $ddsfile;
	my $replacestr = $fileparts[$#fileparts];
	my @newparts = split '/', $pngfile;
	my $newstr = $newparts[$#newparts];

	print "Replace $replacestr WITH $newstr in *.cfg\n";
	foreach my $config (@configs) {
		chomp $config;
		# print "Executing 'sed -i s/$replacestr/$newstr/g $config'\n";
		system "sed -i s/$replacestr/$newstr/g $config";
	}
}

 

Cheers,

-BS

Link to comment
Share on other sites

Thanks for the script. Many ways indeed to get this done, I would have gone about it differently, but the important part is it works. Perl always seems like a shotgun solution to me, but this one is just complex enough to justify the overhead.

Link to comment
Share on other sites

I'm cross-posting this here because I think the problem may be with Kopernicus.  When using SigmaDimensions to resize kerbin KSP would not load.  The log spammed with the following.  Frustrated, I removed SigmaDimensions and tried to resize kerbin manually via kopernicus alone.  Everything works fine at normal scales.  Even planet packs with new planets work (OPM).  I can edit Kerbin's atmosphere and even the scale of the overall system, but whenever I touch kerbin's radius I get the same errors.

[EXC 11:52:16.605] ArgumentNullException: Argument cannot be null.
Parameter name: source
    System.Linq.Check.SourceAndPredicate (System.Object source, System.Object predicate)
    System.Linq.Enumerable.All[KopernicusStar] (IEnumerable`1 source, System.Func`2 predicate)
    Kopernicus.Components.KopernicusStar.GetNearest (.CelestialBody body)
    Kopernicus.RuntimeUtility.LateUpdate ()

https://www.dropbox.com/s/hv4y6bk97q9bzra/KSP.log

Is this a linux/capitalizations thing?  Have others managed to resize kerbin?

Edited by Sandworm
Link to comment
Share on other sites

I released Kopernicus 1.2.0-3 on Github.

It contains two untested PQSCity loaders, some fixes for barycenters, and maybe the most important thing: A system that allows for almost bug free reparenting of Kerbin. What the system does is to read a config node named "PostSpawnOrbit" from the Body node, that uses the same parameter names as the Orbit node, and to apply it after KSP has spawned the planetary system prefab.

While this is not the best way, and Kopernicus was built specifically to avoid live patching of the system, this is the only way, since it is, apart from some minor visual bugs, stable. (For comparison: if I reparented Kerbin in the prefab in 1.2, the space center was totally black. So yeah..)

Planet makers should use the Orbit node to define the orbital elements, and the PostSpawnOrbit node to change the referenceBody.

(I really should have called this release 1.2-3)

Link to comment
Share on other sites

2 hours ago, Thomas P. said:

I released Kopernicus 1.2.0-3 on Github.

It contains two untested PQSCity loaders, some fixes for barycenters, and maybe the most important thing: A system that allows for almost bug free reparenting of Kerbin. What the system does is to read a config node named "PostSpawnOrbit" from the Body node, that uses the same parameter names as the Orbit node, and to apply it after KSP has spawned the planetary system prefab.

While this is not the best way, and Kopernicus was built specifically to avoid live patching of the system, this is the only way, since it is, apart from some minor visual bugs, stable. (For comparison: if I reparented Kerbin in the prefab in 1.2, the space center was totally black. So yeah..)

Planet makers should use the Orbit node to define the orbital elements, and the PostSpawnOrbit node to change the referenceBody.

(I really should have called this release 1.2-3)

Can we still use the regular method for reparenting other bodies?

Link to comment
Share on other sites

Ok so i have been trying to use the new PQSCity2 loaders in my cfg and even though i have changed the longitude and latitude, when i load a game they are still in the stock locations. This is what im putting it in my cfg. I only have the first CommNetDish location changed in this example. Maybe im doing something wrong. I know it was untested so maybe it never worked. i dunno. Its a start though!

Spoiler

PQS
        {
            materialType = AtmosphericExtra
            Material
            {
                saturation = 1
                contrast = 4
                powerNear = 0.725
                powerFar = 0.675
                groundTexStart = 0
                groundTexEnd = 1750
                steepTexStart = 1750
                steepTexEnd = 100000
                steepTex = GPP/Terrain/cliffface3_00
                steepBumpMap = GPP/Terrain/cliffface3_01
                steepNearTiling = 800
                steepTiling = 80
                lowTex = GPP/Terrain/grass00
                lowBumpMap = GPP/Terrain/grass01
                lowNearTiling = 10000
                lowMultiFactor = 1000
                lowBumpNearTiling = 10000
                lowBumpFarTiling = 1000
                midTex = GPP/Terrain/grass00
                midBumpMap = GPP/Terrain/grass01
                midNearTiling = 6000
                midMultiFactor = 600
                midBumpNearTiling = 600
                midBumpFarTiling = 60
                highTex = GPP/Terrain/noise00
                highBumpMap = GPP/Terrain/noise01
                highNearTiling = 8000
                highMultiFactor = 400
                highBumpNearTiling = 8000
                highBumpFarTiling = 400
            }
            Mods
            {
                VertexHeightMap
                {
                    map = GPP/Gael/PluginData/Gael_heightmap.png
                    offset = -900
                    deformity = 4000
                    scaleDeformityByRadius = False
                    order = 2
                    enabled = true
                }
                City2
                {
                    snapToSurface = True
                    alt = 26.5085343698738
                    lat = 8.6
                    lon = -168.25
                    objectName = Harvester Massif
                    up = 0,1,0
                    rotation = 0
                    snapHeightOffset = 0
                    visibilityRange = 30000
                    commnetStation = True
                    order = 100
                    enabled = True
                    name = CommNetDish
                    index = 0
                }
                City2
                {
                    snapToSurface = True
                    alt = -547.007823586464
                    lat = 5.36
                    lon = 108.55
                    objectName = Nye Island
                    up = 0,1,0
                    rotation = 0
                    snapHeightOffset = -15
                    visibilityRange = 30000
                    commnetStation = True
                    order = 100
                    enabled = True
                    name = CommNetDish
                    index = 1
                }
                City2
                {
                    snapToSurface = True
                    alt = -616.89689206914
                    lat = -59.59
                    lon = -25.87
                    objectName = Mesa South
                    up = 0,1,0
                    rotation = 0
                    snapHeightOffset = 0
                    visibilityRange = 30000
                    commnetStation = True
                    order = 100
                    enabled = True
                    name = CommNetDish
                    index = 2
                }
                City2
                {
                    snapToSurface = True
                    alt = 2251.97478733736
                    lat = 9.45
                    lon = -172.11
                    objectName = Crater Rim
                    up = 0,1,0
                    rotation = 0
                    snapHeightOffset = 0
                    visibilityRange = 30000
                    commnetStation = True
                    order = 100
                    enabled = True
                    name = CommNetDish
                    index = 3
                }
                City2
                {
                    snapToSurface = True
                    alt = -746.266213960829
                    lat = 63.095
                    lon = -90.08
                    objectName = North Station One
                    up = 0,1,0
                    rotation = 0
                    snapHeightOffset = 0
                    visibilityRange = 30000
                    commnetStation = True
                    order = 100
                    enabled = True
                    name = CommNetDish
                    index = 4
                }

 

Edited by Galileo
Link to comment
Share on other sites

@Sigma88, have you had a chance to look into my ring inclination problem?  I'm sure you're busy and I don't want to pressure you, but I haven't seen anything since your initial reply.  As a reminder, below is the post where I described the problem.

 

Link to comment
Share on other sites

4 hours ago, OhioBob said:

@Sigma88, have you had a chance to look into my ring inclination problem?  I'm sure you're busy and I don't want to pressure you, but I haven't seen anything since your initial reply.  As a reminder, below is the post where I described the problem.

 

sorry, forgot about that.

I didn't have much time to test, but have you tried using something like

@Kopernicus:FINAL
{
	@Body[Name]
	{
		%Rings
		{
			%Ring
			{
				@lockRotation = false
			}
		}
	}
}

not sure if you should use false or true, try them both and see what happens

Link to comment
Share on other sites

10 hours ago, Sigma88 said:

sorry, forgot about that.

I didn't have much time to test, but have you tried using something like


@Kopernicus:FINAL
{
	@Body[Name]
	{
		%Rings
		{
			%Ring
			{
				@lockRotation = false
			}
		}
	}
}

not sure if you should use false or true, try them both and see what happens

Yes, I experimented with the lockRotation parameter.  It didn't solve the problem.  Although it locked the ascending node of the rings in place once the game was started, it didn't stop the line of nodes from shifting from one run to the next.  As I recall, with lockRotation = false the ring axis would precess with the planet's rotation; and with lockRotation = true the ascending node remained fixed and was not tied to the planet's rotation.  However, I could find no way to permanently lock the ascending node to a particular celestial longitude.  As I explained, on one run the rings would have an ascending node of X.  I'd then exit the game, edit the moonlet's ascending node to match the rings, restart the game, and now the rings would have an ascending node of Y.  The lockRotation parameter appeared to have no affect on this random shifting of the ascending node.

It appeared that it just wouldn't allow me to make the ascending nodes of the rings and moonlet the same.  I could get the moonlet within a few degrees of the ring plane, but anytime I tried to make them exactly coplanar, the line of nodes of the rings would change on the next run.  Adding to the frustration, I could make the rings and moonlet coplanar if I edited the moonlet's ascending node using KittopiaTech; however, the problem would rear its ugly head when I edited the moonlet's config to make that change permanent.

Hey, I just got an idea.  The moonlet orbits in a gap in the rings, however that gap isn't real - it's just a blank spot in the middle of one solid image.  What if we actually split it into two separate rings with a real gap between them?  Maybe then we could place the moonlet in this gap without it affecting the rings.  I'll have to experiment with this to see if I can make it work.
 

Edited by OhioBob
Link to comment
Share on other sites

4 minutes ago, OhioBob said:

Hey, I just got an idea.  The moonlet orbits in a gap in the rings, however that gap isn't real - it's just a blank spot in the middle of one solid image.  What if we actually split it into two separate rings with a real gap between them?  Maybe then we could place the moonlet in this gap without it affecting the rings.  I'll have to experiment with this to see if I can make it work.

I thought about doing that but I didn't think it would make a difference. I haven't even tried it yet though. I don't know if the moonlet actually affects the rings that why I haven't tried anything. I just figured it didnt.

Edited by Galileo
Link to comment
Share on other sites

1 hour ago, OhioBob said:

Yes, I experimented with the lockRotation parameter.  It didn't solve the problem.  Although it locked the ascending node of the rings in place once the game was started, it didn't stop the line of nodes from shifting from one run to the next.  As I recall, with lockRotation = false the ring axis would precess with the planet's rotation; and with lockRotation = true the ascending node remained fixed and was not tied to the planet's rotation.  However, I could find no way to permanently lock the ascending node to a particular celestial longitude.  As I explained, on one run the rings would have an ascending node of X.  I'd then exit the game, edit the moonlet's ascending node to match the rings, restart the game, and now the rings would have an ascending node of Y.  The lockRotation parameter appeared to have no affect on this random shifting of the ascending node.

It appeared that it just wouldn't allow to make the ascending nodes of the rings and moonlet the same.  I could get the moonlet within a few degrees of the ring plane, but anytime I tried to make them exactly coplanar, the line of nodes of the rings would change on the next run.  Adding to the frustration, I could make the rings and moonlet coplanar if I edited the moonlet's ascending node using KittopiaTech; however, the problem would rear its ugly head when I edited the moonlet's config to make that change permanent.

Hey, I just got an idea.  The moonlet orbits in a gap in the rings, however that gap isn't real - it's just a blank spot in the middle of one solid image.  What if we actually split it into two separate rings with a real gap between them?  Maybe then we could place the moonlet in this gap without it affecting the rings.  I'll have to experiment with this to see if I can make it work.

not sure, I was using that parameter in my OPM Tilt to get the rings on urlum to stay vertical, but I have no idea if it's still working or not.

Link to comment
Share on other sites

1 hour ago, Galileo said:

I thought about doing that but I didn't think it would make a difference. I haven't even tried it yet though. I don't know if the moonlet actually affects the rings that why I haven't tried anything. I just figured it didnt.

I'm getting ready to start some tests to see if it will work.  If it does, I'll send you the changes.

Link to comment
Share on other sites

I'm completely baffled.  There's something really buggy going on here that I can't figure out.  The first thing I did was to edit the planet's ring to split it into two rings, both having an inclination angle of 30 degrees.  I next edited the moon to give it an orbital inclination of 30 degrees.  I then started the game to see what it looked like.  At this point everything looked OK - I had two rings as expected and everything was inclined 30 degrees.  The only problem was that the ascending nodes of the rings and moon did not match.  I estimated approximately how much I needed to change the moon's LAN, exited the game, edited the cfg, and restarted.  This time the orientation of the rings and moon was exactly the same as before, i.e. changing the moon's LAN did nothing.  I tried a few other cfg changes and, lo and behold, none of my edits are taking effect.  I even switched back to the original cfg files and no change.  The Module Manager cache is showing my initial edits and is refusing to update no matter what changes I make to the cfg file.  I tried deleting the Kopernicus cache, the Module Manager cache, and the logs, but everything is recreated with the same wrong numbers rather than pulling new data from the Kopernicus cfg files.

For example, here is the ring node from the current (and original unedited) cfg file:

		Rings
		{
			Ring
			{
			angle = 0
			outerRadius = 2200
			innerRadius = 1200
			texture = GPP/Tellumo/PluginData/Tellumo_ring.png
			color = 0.5,0.65,0.5,0.5
			lockRotation = True
			unlit = true
			}
		}

And below is what is in ModuleManager.ConfigCache.  This is the ring node from my initial edit of the cfg file.  It refuses to update even though the Kopernicus cfg now includes the above ring node.

			Rings
			{
				Ring
				{
					angle = 30
					outerRadius = 1450
					innerRadius = 1200
					texture = GPP/Tellumo/PluginData/Tellumo_ring.png
					color = 0.5,0.65,0.5,0.5
					lockRotation = True
					unlit = true
				}
				Ring
				{
					angle = 30
					outerRadius = 2200
					innerRadius = 1460
					texture = GPP/Tellumo/PluginData/Tellumo_ring.png
					color = 0.5,0.65,0.5,0.5
					lockRotation = True
					unlit = true
				}
			}

Similarly, here is the moon's current orbit node:

		{
			referenceBody = Tellumo
			color = 0.0,0.0,0.0,0.0
			iconColor = 0,0,0,0
			inclination = 0
			eccentricity = 0
			semiMajorAxis = 1455000
			longitudeOfAscendingNode = 0
			argumentOfPeriapsis = 0
			meanAnomalyAtEpoch = 0
			epoch = 0
		}

And here is what ModuleManager.ConfigCache is showing (note that the inclination is 30 degrees):

			Orbit
			{
				referenceBody = Tellumo
				color = 0.0,0.0,0.0,0.0
				iconColor = 0,0,0,0
				inclination = 30
				eccentricity = 0
				semiMajorAxis = 1455000
				longitudeOfAscendingNode = 0
				argumentOfPeriapsis = 0
				meanAnomalyAtEpoch = 0
				epoch = 0
			}

I'm using Kopernicus Release 3, which is packaged with Module Manager 2.7.2.  I noticed that the Module Manager thread is showing the most current release as 2.7.1.  I tried both versions with the same result.  I find it very bizarre that my original edits took effect while every change I've attempted since then has failed.

If anybody needs to see the full logs, I can provide those on request.

Link to comment
Share on other sites

32 minutes ago, OhioBob said:

I'm completely baffled.  There's something really buggy going on here that I can't figure out.  The first thing I did was to edit the planet's ring to split it into two rings, both having an inclination angle of 30 degrees.  I next edited the moon to give it an orbital inclination of 30 degrees.  I then started the game to see what it looked like.  At this point everything looked OK - I had two rings as expected and everything was inclined 30 degrees.  The only problem was that the ascending nodes of the rings and moon did not match.  I estimated approximately how much I needed to change the moon's LAN, exited the game, edited the cfg, and restarted.  This time the orientation of the rings and moon was exactly the same as before, i.e. changing the moon's LAN did nothing.  I tried a few other cfg changes and, lo and behold, none of my edits are taking effect.  I even switched back to the original cfg files and no change.  The Module Manager cache is showing my initial edits and is refusing to update no matter what changes I make to the cfg file.  I tried deleting the Kopernicus cache, the Module Manager cache, and the logs, but everything is recreated with the same wrong numbers rather than pulling new data from the Kopernicus cfg files.

For example, here is the ring node from the current (and original unedited) cfg file:


		Rings
		{
			Ring
			{
			angle = 0
			outerRadius = 2200
			innerRadius = 1200
			texture = GPP/Tellumo/PluginData/Tellumo_ring.png
			color = 0.5,0.65,0.5,0.5
			lockRotation = True
			unlit = true
			}
		}

And below is what is in ModuleManager.ConfigCache.  This is the ring node from my initial edit of the cfg file.  It refuses to update even though the Kopernicus cfg now includes the above ring node.


			Rings
			{
				Ring
				{
					angle = 30
					outerRadius = 1450
					innerRadius = 1200
					texture = GPP/Tellumo/PluginData/Tellumo_ring.png
					color = 0.5,0.65,0.5,0.5
					lockRotation = True
					unlit = true
				}
				Ring
				{
					angle = 30
					outerRadius = 2200
					innerRadius = 1460
					texture = GPP/Tellumo/PluginData/Tellumo_ring.png
					color = 0.5,0.65,0.5,0.5
					lockRotation = True
					unlit = true
				}
			}

Similarly, here is the moon's current orbit node:


		{
			referenceBody = Tellumo
			color = 0.0,0.0,0.0,0.0
			iconColor = 0,0,0,0
			inclination = 0
			eccentricity = 0
			semiMajorAxis = 1455000
			longitudeOfAscendingNode = 0
			argumentOfPeriapsis = 0
			meanAnomalyAtEpoch = 0
			epoch = 0
		}

And here is what ModuleManager.ConfigCache is showing (note that the inclination is 30 degrees):


			Orbit
			{
				referenceBody = Tellumo
				color = 0.0,0.0,0.0,0.0
				iconColor = 0,0,0,0
				inclination = 30
				eccentricity = 0
				semiMajorAxis = 1455000
				longitudeOfAscendingNode = 0
				argumentOfPeriapsis = 0
				meanAnomalyAtEpoch = 0
				epoch = 0
			}

I'm using Kopernicus Release 3, which is packaged with Module Manager 2.7.2.  I noticed that the Module Manager thread is showing the most current release as 2.7.1.  I tried both versions with the same result.  I find it very bizarre that my original edits took effect while every change I've attempted since then has failed.

If anybody needs to see the full logs, I can provide those on request.

I don't think I understand.

can your cfgs be downloaded somewhere? it might help to look at everything together

Link to comment
Share on other sites

9 hours ago, Sigma88 said:

I don't think I understand.

can your cfgs be downloaded somewhere? it might help to look at everything together

I'm using the cfgs from Galileo's plant pack.  You can download the entire package by going to the thread below.  The planet with the rings is Tellumo and its small moon is Lili.

If you download the package you will find that neither the rings nor moon has any inclination, which was not our original intent.  We were forced to settle for no inclination because when we tried to add inclination we couldn't get the rings and moon to be coplanar (as described earlier).

For yesterday's experiment, I edited Tellumo.cfg to split the single ring into two separate rings with 30o inclination, and I edited Lili.cfg to add 30o of orbital inclination.  These edits are what you see in my previous post.  After making these initial edits and loading KSP, I could immediately see the changes and everything appeared as expected.  After that, however, things started to go haywire.  No matter what changes I now make to Tellumo.cfg or Lili.cfg, nothing changes when I load up KSP.  I even reinstalled the original cfgs, but when I load up KSP I still get Tellumo having two separate rings inclined 30o and Lili is still inclined 30o.  It makes no sense.  It's like its completely ignoring what it in the cfgs and is somehow remembering and using the settings from a previous version.

 

Link to comment
Share on other sites

4 hours ago, OhioBob said:

I'm using the cfgs from Galileo's plant pack.  You can download the entire package by going to the thread below.  The planet with the rings is Tellumo and its small moon is Lili.

If you download the package you will find that neither the rings nor moon has any inclination, which was not our original intent.  We were forced to settle for no inclination because when we tried to add inclination we couldn't get the rings and moon to be coplanar (as described earlier).

For yesterday's experiment, I edited Tellumo.cfg to split the single ring into two separate rings with 30o inclination, and I edited Lili.cfg to add 30o of orbital inclination.  These edits are what you see in my previous post.  After making these initial edits and loading KSP, I could immediately see the changes and everything appeared as expected.  After that, however, things started to go haywire.  No matter what changes I now make to Tellumo.cfg or Lili.cfg, nothing changes when I load up KSP.  I even reinstalled the original cfgs, but when I load up KSP I still get Tellumo having two separate rings inclined 30o and Lili is still inclined 30o.  It makes no sense.  It's like its completely ignoring what it in the cfgs and is somehow remembering and using the settings from a previous version.

 

I'll try that and get back to you.

(sorry if I'll make you wait, but I'm pretty busy with SB right now)

Edited by Sigma88
Link to comment
Share on other sites

nyKZbiql.png

I'm playing around at building a system via Kopernicus.  Moving planets around works.  Resizing planets works.  I've got a giant duna around Kerbin atm that just makes me laugh.  But when I try to resize Kerbin itself I get null reference exceptions.  Are there special rules for working with Kerbin as opposed to the other stock bodies?

tE4V7Qtm.png

Update: PROGRESS!!!  After a few days of bashing around I managed to hack it into working.  I have now resized kerbin and think I understand the bug.  I noticed that Kopernicus wasn't creating a Kerbin.bin file as it does for other bodies.  I suspect the lack of this file was the source of the null reference.  So I copy-pasted over the Vall.bin file and renamed it Kerbin.bin.  That actually worked!  Kopernicus now starts without null references and I have a giant Kerbin.

 

The KSC is out to sea a little, but that's a much less fundamental problem.

 

Edited by Sandworm
Link to comment
Share on other sites

I dont know if anyone else is experiencing the output log being flooded with nullrefs but every time i go into the tracking station it happens. Im including my log and a screenshot. This is stock with only Kopernicus and its dependencies installed. 

its this, over and over again

NullReferenceException: Object reference not set to an instance of an object
  at Kopernicus.RuntimeUtility.LateUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

https://www.dropbox.com/s/9tbhp4mz2z8cqlg/output_log.txt?dl=0


ghGBpvz.png

 

Edited by Galileo
Link to comment
Share on other sites

6 hours ago, Galileo said:

I dont know if anyone else is experiencing the output log being flooded with nullrefs but every time i go into the tracking station it happens. Im including my log and a screenshot. This is stock with only Kopernicus and its dependencies installed. 

its this, over and over again


NullReferenceException: Object reference not set to an instance of an object
  at Kopernicus.RuntimeUtility.LateUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

https://www.dropbox.com/s/9tbhp4mz2z8cqlg/output_log.txt?dl=0


ghGBpvz.png

 

Redownload from Github please, it was a bug I hotfixed.

Edited by Thomas P.
Link to comment
Share on other sites

My log file is seeing about 100 of these a second during re-entry. Before I go and setup a clean install to isolate the problem further, has this been seen by anyone else yet?

 

[EXC 22:01:42.561] TargetException: Non-static field requires a target
    System.Reflection.MonoField.GetValue (System.Object obj)
    Kopernicus.RuntimeUtility.LateUpdate ()

 

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