[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[technogeeky]

Bad form to quote myself but I've found the problem:

A user named OrbitalDebris has been updating RPM.dll and SCANsatRPM.dll to keep them in synch with the dev builds of MechJeb as sarbian releases them. Unfortunately, doing so breaks RPM integration with the v6rc version of SCANsat.

I did not compile RPM.dll or MechJebRPM.dll myself to release it, so I couldn't have matched them. Plus, I'm behind on dev builds.

This situation is really grim, though. There is no way it's reasonable to ask someone to build against this many targets. Surely there is an explanation how version checking is being done here. I need to find more documentation about assemblies and DLLs and versioning.

I mean, don't get me wrong -- I'll be happy to build whatever and release whatever to make sure it works for the most people. But there are new dev builds of MechJeb nearly daily. And there is no reason to suspect that each new dev build of any of these things is going to break anything.

We need to loosen the version restrictions going on.

[DMagic]

OK. I have pushed all of my changes into my master/v6.

I've tested the changes to the SCANsat partmodule that I uploaded a little more. Everything seems to be working ok.

The primary change is to the storage of science data. It now persists through saving and loading and can be reviewed as you normally would.

Do people want to be able to collect the data on EVA? I don't see much need for that, but it's an easy fix.

The other changes are just to move stuff off of OnUpdate where possible.

I did not compile RPM.dll or MechJebRPM.dll myself to release it, so I couldn't have matched them. Plus, I'm behind on dev builds.

This situation is really grim, though. There is no way it's reasonable to ask someone to build against this many targets. Surely there is an explanation how version checking is being done here. I need to find more documentation about assemblies and DLLs and versioning.

I think people need to pick a dev build and stick with it, either SCANsat or MechJeb; using both is probably not a good idea.

And more to the point, the SCANsat releases are test builds, any errors encountered while using a test build of SCANsat, an unofficial build of RPM, with a dev build of MJ and another unofficial build of RPM won't provide much insight into what might be wrong with SCANsat.

When an official update for SCANsat v6 is released then RPM can be updated and this problem will go away. But for now I think it would be helpful if anyone testing SCANsat and SCANsatRPM stuck with the standard release of MJ.

[technogeeky]

I've tested the changes to the SCANsat partmodule that I uploaded a little more. Everything seems to be working ok.

The primary change is to the storage of science data. It now persists through saving and loading and can be reviewed as you normally would.

Do people want to be able to collect the data on EVA? I don't see much need for that, but it's an easy fix.

The other changes are just to move stuff off of OnUpdate where possible.

I think people need to pick a dev build and stick with it, either SCANsat or MechJeb; using both is probably not a good idea.

And more to the point, the SCANsat releases are test builds, any errors encountered while using a test build of SCANsat, an unofficial build of RPM, with a dev build of MJ and another unofficial build of RPM won't provide much insight into what might be wrong with SCANsat.

When an official update for SCANsat v6 is released then RPM can be updated and this problem will go away. But for now I think it would be helpful if anyone testing SCANsat and SCANsatRPM stuck with the standard release of MJ.

I do understand the sentiment, but it seems silly overall. I feel like I'm always going to be using a dev build of either MechJeb or SCANsat for all of my life. Why can't we just compile a DLL that doesn't care about versions? Or why can't we actually use versioning information to say that anything with the same Major.Minor.*.* should be tried. This whole -- things just not working with no explanation is bizzare.

I wonder if there are any errors in KSP.log (or that other, more detailed one) that say what is happening?

Can someone who is having that problem please take a look? I suppose I am having the problem with MechJeb (though I don't even know if I have MechJebRPM installed... silly me)

[technogeeky]

It makes me wonder if:

1. SCANsat is responsible for actually having a version number (that is automatically changed/assigned) or

2. If all of the RPM libraries are responsible for *not* having a version. Perhaps this is forcing them to fall back to comparing hash values of the DLL or something silly.

[technogeeky]

I've tested the changes to the SCANsat partmodule that I uploaded a little more. Everything seems to be working ok.

The primary change is to the storage of science data. It now persists through saving and loading and can be reviewed as you normally would.

Do people want to be able to collect the data on EVA? I don't see much need for that, but it's an easy fix.

There are two reasons I think it might be good to collect data:

1. For RemoteTech users who have incorrect or otherwise failed relay networks.

2. For interacting with new add-ons which "automatically" (how?) collect data and store it in the capsule. I haven't looked at any yet.

I'll look at your changes tonight and incorporate them.

I have a private branch with caching support enabled. I am testing your solution and my solution in isolation to see if there are performance differences (there are no visible differences).

[Mecripp]

Here are 2 post by Mihara about the MJ DEV. and SCANsat.

http://forum.kerbalspaceprogram.com/threads/57603-0-23-5-RasterPropMonitor-make-your-IVA-a-glass-cockpit-%28v0-16%29-20-Apr?p=1105267&viewfull=1#post1105267

http://forum.kerbalspaceprogram.com/threads/57603-0-23-5-RasterPropMonitor-make-your-IVA-a-glass-cockpit-%28v0-16%29-20-Apr?p=1105568&viewfull=1#post1105568

[technogeeky]

Here are 2 post by Mihara about the MJ DEV. and SCANsat.

http://forum.kerbalspaceprogram.com/threads/57603-0-23-5-RasterPropMonitor-make-your-IVA-a-glass-cockpit-%28v0-16%29-20-Apr?p=1105267&viewfull=1#post1105267

http://forum.kerbalspaceprogram.com/threads/57603-0-23-5-RasterPropMonitor-make-your-IVA-a-glass-cockpit-%28v0-16%29-20-Apr?p=1105568&viewfull=1#post1105568

This is the most helpful thing I've yet seen.

Mihara and I should work together on this problem, I guess. I don't know if there's a difference yet, but I play and develop in Linux, and he in Windows.

Anyway, let me think about what I have read by Mihara and .NET docs (which seem to agree: nobody in KSP land seems to use cryptographic signing on their modules, so version numbers are not involved -- though I think there might be two separate loopholes to this).

I'll reply in the new thread in Add-on Requests and Support or whatever that sub-forum is called.

Thanks.

[DMagic]

There are two reasons I think it might be good to collect data:

1. For RemoteTech users who have incorrect or otherwise failed relay networks.

2. For interacting with new add-ons which "automatically" (how?) collect data and store it in the capsule. I haven't looked at any yet.

Yeah, I was thinking maybe someone would crash land and break off their antenna, it seems unlikely, but I guess it's bound to happen eventually.

It's easy enough to add in EVA collection. External collection (or other manipulation) through other mods is dependent on how those mods are setup, but most of them search for parts implementing ModuleScienceExperiment, so they won't see this at all.

The only mod that I know of that properly handles this is Tarsier Space Technology's hard drive part. It searches for parts using the IScienceDataContainer interface, checks if they have Science Data (using the standard interface methods), and pulls out any that it finds. Then it clears out the part's data using IScienceDataContainer.DumpData, this is the same method that is called when you transmit data by right-clicking on the antenna.

[technogeeky]

DMagic: FYI, merged it all. Thanks!

[Rocketman1994]

Soooo, out of curiosity is this mod work with 23.5? I only use MJ and kerbal alarm clock (so I'm not that mod heavy).

[4nxs]

Soooo, out of curiosity is this mod work with 23.5? I only use MJ and kerbal alarm clock (so I'm not that mod heavy).

I use both and more. I have v6rc from technogeeky and DMagic installed, it is working fine.

[Spooks]

is there a way if i fast travel to my prob it won't deploy.

right a way so they won't shaking himself apart.

i tink its scansat its the most stuff i have on my sat ather sats dont have the probleam

[technogeeky]

is there a way if i fast travel to my prob it won't deploy.

right a way so they won't shaking himself apart.

i tink its scansat its the most stuff i have on my sat ather sats dont have the probleam

Another person on reddit asked the same question.

I can not say with 100% certainty that this is not related to SCANsat (yet, I may be able to figure it out with more information). But it's probably not related to SCANsat.

Install KJR. The physics easing will correct this problem, no matter what is causing it. And it's probably KSP itself and/or something producing rounding errors.

[Mecripp]

is there a way if i fast travel to my prob it won't deploy.

right a way so they won't shaking himself apart.

i tink its scansat its the most stuff i have on my sat ather sats dont have the probleam

Some builds of MJ will do that and there was a old problem with SCANsat that if you put the Sat part at a joint that would happen KSP bug, I guess, I haven't had that happen in a long time.

[Arcamean]

Hi there I'm trying to diagnose a problem that appeared when I installed some mods recently, one of them being SCANsat. Anyways the problem happens after a random amount of time in game, usually when I'm in the VAB, and the screen flickers black for a second and half then back to normal. Afterwards it's like the icons have "moved" because when I mouse over say Launch and click nothing happens. I have to move the mouse down a quarter inch then it lets me, but I can't click on the different part tabs. I'm not sure if this is a SCANsat issue, or caused by something else but I'm trying to eliminate it one mod at a time. I've also installed Kethane, Rasterprop and a few others. I'd install one by one but KSP takes so damn long to boot I'll be here all week, lol.

[KerbMav]

First: I love what you are doing with this mod, which is one of THE mods for KSP, thank you for keeping it alive and prosper!

The different parts - there are quite many. Maybe instead of making them different kinds of scanners, they should have different rates of power usage and FOV? At least the low and high resolution I almost always edit into one part.

Is it possible to add th BTDT to EVA Kerbals?

"Readings are of the scale, I have to see this with my own big eyes!"

I am almost sure I found the part.cfg for a Kerbal once, but ...

The small sat-dish part does not work for me, the dish does not extend, the maptraq does not open and placing the part in VAB is reversed, the attachment point being on the tip of the dish.

[criminy]

At least the low and high resolution I almost always edit into one part.

I feel they're pretty well suited as two different parts because of the lower tech requirement for the low resolution altimetry sensor. The sensor data seems to be approximately commensurate with the technology level.

[Mecripp]

First: I love what you are doing with this mod, which is one of THE mods for KSP, thank you for keeping it alive and prosper!

The different parts - there are quite many. Maybe instead of making them different kinds of scanners, they should have different rates of power usage and FOV? At least the low and high resolution I almost always edit into one part.

Is it possible to add th BTDT to EVA Kerbals?

"Readings are of the scale, I have to see this with my own big eyes!"

I am almost sure I found the part.cfg for a Kerbal once, but ...

The small sat-dish part does not work for me, the dish does not extend, the maptraq does not open and placing the part in VAB is reversed, the attachment point being on the tip of the dish.

This will work you just need to put your part name in and have KAS install too.

@PART[Part name here]

{

MODULE

{

name = SCANsat

sensorType = 0

fov = 0

min_alt = 0

max_alt = 0

best_alt = 0

power = 0.05

}

MODULE

{

name = SCANsat

sensorType = 32

fov = 1

min_alt = 0

max_alt = 2000

best_alt = 0

power = 0.01

scanName = BTDT scan

}

RESOURCE

{

name = ElectricCharge

amount = 500

maxAmount = 500

}

MODULE

{

name = KASModuleGrab

evaPartPos = (0.0, 0.0, -0.15)

evaPartDir = (0,0,-1)

storable = True

storedSize = 4

attachOnPart = True

attachOnEva = False

attachOnStatic = False

}

}

[KerbMav]

.

Hm, so basically carrying a tricorder around.

[DMagic]

Hm, so basically carrying a tricorder around.

Do you mean adding the module directly to the EVA Kerbal, or just dragging around the BTDT part on your back? The KAS method would work fine for just picking up the part, but I'm not sure if you can use MM to add modules to a Kerbal.

There is no user-accessible EVA Kerbal part.cfg file, I assume there is something like it somewhere, but I'm not sure if MM can actually do anything with it. The people in the MM thread might know more about that though.

[Tiron]

It makes me wonder if:

1. SCANsat is responsible for actually having a version number (that is automatically changed/assigned) or

2. If all of the RPM libraries are responsible for *not* having a version. Perhaps this is forcing them to fall back to comparing hash values of the DLL or something silly.

From reading Mihara's stuff on the subject, it's actually Squad's fault. Something in the way their plugin loading setup is arranged makes it so that directly calling functions from another .dll only works if it's the exact right version of the .dll, otherwise it doesn't allow it. He's got a couple posts on the subject, talking mostly with Sarbian after a change to Mechjeb's buildbot broke compability with the dev mechjebs.

Here's one

Another

Given what happened with the Mechjeb Dev version and the nature of it, it seems like the pluginloader's going off the version number on the .dll for the purposes of enforcing this.

Basically what happened was this: Mechjeb's version numbers are hard-coded in the code itself, and are only changed when a release is pulled. All the mechjeb dev-builds since version 2.2.1.0 was released (225/226-242 at the moment) if you pull the code down and compile it yourself, will show up as version 2.2.1.0.

They also have an automated build bot set up, which every time there's a commit to the project automatically compiles the new version and hosts it for people to download. At some point here recently they changed how it does so: instead of just compiling it straight up, it now automatically appends the commit # onto the last digit of the version number. So instead of it coming out at 2.2.1.0 like it would if you compiled it yourself, the one the buildbot spits out comes out as 2.2.1.242 (or whatever.)

Judging by the forum posts, before that change to the buildbot, the dev versions of mechjeb worked with RPM without any modification. You could just drop them in and they'd work...apparently because they had the same version number as the last release. I've seen people mentioning a specific commit where the change took place and the compatibility broke.

My understanding is that dropping the version numbering on the .dll wouldn't fix it in and of itself: the new one would still register as 'different', but if the version number didn't change after that, and the functions that were being hooked into didn't either, each subsequent version after that would continue to work after it'd been recompiled once.

In fact, if my understanding is correct, you could make your versions of scansat work as a drop-in on the unmodified RPM simply by setting it up in such a way that your .dlls always came out with a version number of 1.0.5.32015, the version of the release that RPM's been compiled with.

It's not great practice, and it'd remove the ability to tell what version you had by checking the plugin... but it should allow it to work without having to rebuild RPM constantly.

Edited May 8, 2014 by Tiron

[Starstrider42]

Basically what happened was this: Mechjeb's version numbers are hard-coded in the code itself, and are only changed when a release is pulled. All the mechjeb dev-builds since version 2.2.1.0 was released (225/226-242 at the moment) if you pull the code down and compile it yourself, will show up as version 2.2.1.0.

They also have an automated build bot set up, which every time there's a commit to the project automatically compiles the new version and hosts it for people to download. At some point here recently they changed how it does so: instead of just compiling it straight up, it now automatically appends the commit # onto the last digit of the version number. So instead of it coming out at 2.2.1.0 like it would if you compiled it yourself, the one the buildbot spits out comes out as 2.2.1.242 (or whatever.)

In fact, if my understanding is correct, you could make your versions of scansat work as a drop-in on the unmodified RPM simply by setting it up in such a way that your .dlls always came out with a version number of 1.0.5.32015, the version of the release that RPM's been compiled with.

It's not great practice, and it'd remove the ability to tell what version you had by checking the plugin... but it should allow it to work without having to rebuild RPM constantly.

Hmmm... that seems like an issue that could affect other plugins as well. Do you have any advice for the "safest" way for modders to set up their plugin versions?

[KerbMav]

Do you mean adding the module directly to the EVA Kerbal, or just dragging around the BTDT part on your back? The KAS method would work fine for just picking up the part, but I'm not sure if you can use MM to add modules to a Kerbal.

There is no user-accessible EVA Kerbal part.cfg file, I assume there is something like it somewhere, but I'm not sure if MM can actually do anything with it. The people in the MM thread might know more about that though.

Yes, that was the idea, more reason to carry a Kerbal around - the part would be usable by a probe too.

(If the Kerbals are not accessible - how would one change the parameters for surface sample and EVA report?)

[heikkik]

Well, using SCANsat has led me to a new discovery! It's just a small easter egg south of KSC. Well, I guess small isn't the right word here, but it's quite well hidden from sight when you normally play the game. I'm not sure if ISAmapsat actually had this level of detail, at least when it comes to in-game maps. I didn't actually care about the renders you could get outside all that much.

Thanks for a great predecessor to mapsat. Couldn't play KSP properly without this finding out a good landing zone first.

[Dweller_Benthos]

Well, using SCANsat has led me to a new discovery! It's just a small easter egg south of KSC. Well, I guess small isn't the right word here, but it's quite well hidden from sight when you normally play the game. I'm not sure if ISAmapsat actually had this level of detail, at least when it comes to in-game maps. I didn't actually care about the renders you could get outside all that much.

Do you mean the

smiley face in the ocean?

or something else?