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

barfing_skull · October 26, 2016

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 )

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

komodo · October 26, 2016

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.

Sandworm · October 27, 2016

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 October 27, 2016 by Sandworm

Thomas P. · October 27, 2016

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)

Streetwind · October 27, 2016

I'm loving it!(tm)

Time to make good on that promised bribe... :wink:

_Augustus_ · October 27, 2016

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?

Thomas P. · October 27, 2016

3 minutes ago, _Augustus_ said:

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

sure, why not?

Edited October 27, 2016 by Thomas P.

_Augustus_ · October 27, 2016

Bug - with any mods that add stuff beyond Jool (such as OPM) installed, if I'm not zoomed out to view the whole system I can see orbit lines jumping around in the background.

Galileo · October 27, 2016

Pretty excited

Edited October 27, 2016 by Galileo

Galileo · October 27, 2016

Disregard

Edited October 28, 2016 by Galileo

Galileo · October 28, 2016

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 October 28, 2016 by Galileo

OhioBob · October 28, 2016

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

Sigma88 · October 28, 2016

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

OhioBob · October 28, 2016

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 October 28, 2016 by OhioBob

Galileo · October 28, 2016

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 October 28, 2016 by Galileo

Sigma88 · October 28, 2016

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.

OhioBob · October 28, 2016

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.

OhioBob · October 28, 2016

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.

Sigma88 · October 28, 2016

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

OhioBob · October 29, 2016

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 30^o inclination, and I edited Lili.cfg to add 30^o 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 30^o and Lili is still inclined 30^o. 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.

Sigma88 · October 29, 2016

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 30^o inclination, and I edited Lili.cfg to add 30^o 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 30^o and Lili is still inclined 30^o. 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 October 29, 2016 by Sigma88

Sandworm · October 30, 2016

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?

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 October 30, 2016 by Sandworm

Galileo · October 30, 2016

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

Edited October 30, 2016 by Galileo

Thomas P. · October 30, 2016

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

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

Edited October 30, 2016 by Thomas P.

kormer · October 31, 2016

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 ()

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation