DMagic

[1.7.3] SCANsat [v18.13] -- Real Scanning, Real Science, at Warp Speed! [August 21, 2019]

Recommended Posts

There was a small rover type scanner in the initial models which I use a lot would love to see its return also will we see the calypso added

n7u40UR.jpg

Edited by Virtualgenius

Share this post


Link to post
Share on other sites
tomtom_demo.png

I might borrow this one and see if I can come up with something more SCANsat specific.

Share this post


Link to post
Share on other sites

Okay, two problems:

1.) The included SCANsatRPM.dll doesn't work in my case, possibly because I built RPM off the last full version and not the release. It seems to have some version of the same problem with RPM that it has with SCANsat itself: if the main RPM plugin doesn't have the same version number as whatever RPM it was built with, it can't find it and throws a fit. At least, I presume that's what's going on since rpm's plugin doesn't call either of the extra dlls as a reference. If so, based on my experience an included SCANsatRPM.dll isn't going to work by itself in general, because the source of the release and the pre-built version of the release have different version numbers.

Why is why I said you need all three for it to work. If you update and/or SCANsatRPM/MechjebRPM, then the one you updated gets a no-match on RPM's dll. If you do the main DLL and only one of SCANsatRPM/MechjebRPM, the one you didn't update gets a no-match on RPM's dll.

There's one catch/exception: every time I've built RPM from a given set of source, all three plugins come out with the same version numbers every time I build them. In theory only the main RPM plugin's should matter, but none of them change. So you only need to do all three *once* for any given version of RPM, and after that can just replace the one that needed updated.

All rendered somewhat moot by the fact that neither of them should need updated all that often in future.

2.) I can't get it to build with the last couple releases of v6. I get a build error on line 566 in JSISCANsatRPM.cs.

The error is 'No overload for method 'resetMap' takes 1 arguments'

Here's the function, I've bolded/underlined the relevant line.

		private void RedrawMap()
{
map = new SCANmap();
map.setProjection(SCANmap.MapProjection.Rectangular);
orbitingBody = vessel.mainBody;
map.setBody(vessel.mainBody);
map.setSize(screenWidth, screenHeight);
map.mapscale *= (zoomLevel * zoomLevel + zoomModifier);
mapCenterLong = vessel.longitude;
mapCenterLat = vessel.latitude;
// That's really just sweeping the problem under the carpet instead of fixing it, but meh.
if (zoomLevel == 0)
mapCenterLat = 0;
map.centerAround(mapCenterLong, mapCenterLat);
[B] [U]map.resetMap(mapMode);[/U][/B]

// Compute and store the map scale factors in mapSizeScale. We
// use these values for every segment when drawing trails, so it
// makes sense to compute it only when it changes.
mapSizeScale = new Vector2d(360.0 * map.mapscale / map.mapwidth, 180.0 * map.mapscale / map.mapheight);
redrawDeviation = redrawEdge * 180 / (zoomLevel * zoomLevel + zoomModifier);
try {
localAnomalies = SCANcontroller.controller.getData(vessel.mainBody).getAnomalies();
} catch {
Debug.Log("JSISCANsatRPM: Could not get a list of anomalies, what happened?");
}
// MATH!
double kmPerDegreeLon = (2 * Math.PI * (orbitingBody.Radius / 1000d)) / 360d;
double pixelsPerDegree = Math.Abs(longitudeToPixels(mapCenterLong + (((mapCenterLong + 1) > 360) ? -1 : 1), mapCenterLat) - longitudeToPixels(mapCenterLong, mapCenterLat));
pixelsPerKm = pixelsPerDegree / kmPerDegreeLon;
}

Mapmode's a private integer that's been set elsewhere, but I can't find any other references to a 'resetMap' function, so I'm presuming it's in SCANsat and got changed somehow in one of the more recent versions, which is why it's blowing up (MechjebRPM has a similar problem with the last bunch of dev versions...except in that case it can't even FIND the function because its name got changed, and I already fixed it.)

Edited by Tiron

Share this post


Link to post
Share on other sites
Okay, two problems:

1.) The included SCANsatRPM.dll doesn't work in my case, possibly because I built RPM off the last full version and not the release. It seems to have some version of the same problem with RPM that it has with SCANsat itself: if the main RPM plugin doesn't have the same version number as whatever RPM it was built with, it can't find it and throws a fit. At least, I presume that's what's going on since rpm's plugin doesn't call either of the extra dlls as a reference. If so, based on my experience an included SCANsatRPM.dll isn't going to work by itself in general, because the source of the release and the pre-built version of the release have different version numbers.

Why is why I said you need all three for it to work. If you update and/or SCANsatRPM/MechjebRPM, then the one you updated gets a no-match on RPM's dll. If you do the main DLL and only one of SCANsatRPM/MechjebRPM, the one you didn't update gets a no-match on RPM's dll.

There's one catch/exception: every time I've built RPM from a given set of source, all three plugins come out with the same version numbers every time I build them. In theory only the main RPM plugin's should matter, but none of them change. So you only need to do all three *once* for any given version of RPM, and after that can just replace the one that needed updated.

All rendered somewhat moot by the fact that neither of them should need updated all that often in future.

2.) I can't get it to build with the last couple releases of v6. I get a build error on line 566 in JSISCANsatRPM.cs.

The error is 'No overload for method 'resetMap' takes 1 arguments'

Here's the function, I've bolded/underlined the relevant line.

        private void RedrawMap()
{
map = new SCANmap();
map.setProjection(SCANmap.MapProjection.Rectangular);
orbitingBody = vessel.mainBody;
map.setBody(vessel.mainBody);
map.setSize(screenWidth, screenHeight);
map.mapscale *= (zoomLevel * zoomLevel + zoomModifier);
mapCenterLong = vessel.longitude;
mapCenterLat = vessel.latitude;
// That's really just sweeping the problem under the carpet instead of fixing it, but meh.
if (zoomLevel == 0)
mapCenterLat = 0;
map.centerAround(mapCenterLong, mapCenterLat);
[B] [U]map.resetMap(mapMode);[/U][/B]

// Compute and store the map scale factors in mapSizeScale. We
// use these values for every segment when drawing trails, so it
// makes sense to compute it only when it changes.
mapSizeScale = new Vector2d(360.0 * map.mapscale / map.mapwidth, 180.0 * map.mapscale / map.mapheight);
redrawDeviation = redrawEdge * 180 / (zoomLevel * zoomLevel + zoomModifier);
try {
localAnomalies = SCANcontroller.controller.getData(vessel.mainBody).getAnomalies();
} catch {
Debug.Log("JSISCANsatRPM: Could not get a list of anomalies, what happened?");
}
// MATH!
double kmPerDegreeLon = (2 * Math.PI * (orbitingBody.Radius / 1000d)) / 360d;
double pixelsPerDegree = Math.Abs(longitudeToPixels(mapCenterLong + (((mapCenterLong + 1) > 360) ? -1 : 1), mapCenterLat) - longitudeToPixels(mapCenterLong, mapCenterLat));
pixelsPerKm = pixelsPerDegree / kmPerDegreeLon;
}

Mapmode's a private integer that's been set elsewhere, but I can't find any other references to a 'resetMap' function, so I'm presuming it's in SCANsat and got changed somehow in one of the more recent versions, which is why it's blowing up (MechjebRPM has a similar problem with the last bunch of dev versions...except in that case it can't even FIND the function because its name got changed, and I already fixed it.)

On iPad so sorry for mistakes

As of the latest mechjeb build and the latest scansat build, there will be no more versioning problems. Everyone had agreed to hardcode their versions to workaround.

You need to use the included ssrpm or build it from scansat source.

Reset map should be called with a 1 in the second argument

Anyway please just delete your scansat and ssrpm folders (save any exported pngs) and use the new ones

Share this post


Link to post
Share on other sites
Mapmode's a private integer that's been set elsewhere, but I can't find any other references to a 'resetMap' function, so I'm presuming it's in SCANsat and got changed somehow in one of the more recent versions, which is why it's blowing up (MechjebRPM has a similar problem with the last bunch of dev versions...except in that case it can't even FIND the function because its name got changed, and I already fixed it.)

If you want to build RPM and SCANsatRPM yourself you'll need to download the source for SCANsatRPM v6 and use that in place of the code from Mihara.

As far as I know the only change is to that one line (which should read "map.resetMap(mapMode, 1)"), but I can't guarantee that.

When I download the latest official release of RPM and replace the included SCANsatRPM folder with that included in SCANsat v6 it works fine (MJ is not installed, but MechjebRPM is and gets loaded fine). If you're using one of the MechJeb dev versions that may not be the case, but it should work with the official release.

Edit: Too slow:(

Share this post


Link to post
Share on other sites

Great job! I am a bit out of the loop though, so... can I have that MFD thingy in any commandpod, or do I need the one you mention in the first post? And does it have features that help me plan a pinpoint descent, besides showing the map?

Share this post


Link to post
Share on other sites
If you want to build RPM and SCANsatRPM yourself you'll need to download the source for SCANsatRPM v6 and use that in place of the code from Mihara.

As far as I know the only change is to that one line (which should read "map.resetMap(mapMode, 1)"), but I can't guarantee that.

When I download the latest official release of RPM and replace the included SCANsatRPM folder with that included in SCANsat v6 it works fine (MJ is not installed, but MechjebRPM is and gets loaded fine). If you're using one of the MechJeb dev versions that may not be the case, but it should work with the official release.

Edit: Too slow:(

I'll compare the two to make sure, but that's the only error it's throwing. Using dev mechjeb shouldn't really affect it, since the two don't reference each other in any way.

What's probably getting it is the fact that in order to get that to work, I end up with a different version number on the main RPM plugin, which the SSRPM *does* reference. In theory, it should work building off your code directly as long as that is referencing the same version of the main RPM plugin that I'm using, which it should just from building it on my setup.

Also, that pretty much confirms it. It's using a rectangular map for the little map window, no wonder it turns useless at the poles.

Share this post


Link to post
Share on other sites
I'll compare the two to make sure, but that's the only error it's throwing. Using dev mechjeb shouldn't really affect it, since the two don't reference each other in any way.

What's probably getting it is the fact that in order to get that to work, I end up with a different version number on the main RPM plugin, which the SSRPM *does* reference. In theory, it should work building off your code directly as long as that is referencing the same version of the main RPM plugin that I'm using, which it should just from building it on my setup.

I modified the ssRPM file, and the only change is for resetMap.

The next version of SCANsat and ssRPM will reference MechJeb to get landing target information and rover target information; but we'll cross that bridge when we get to it.

RPM, ssRPM, and mjRPM all have no declaration of assembly version -- which implies that they are set to 0.0.0.0 and behave as hard coded. There is some other file 'sharedassemblyversion' in the git repo which does have a stated version (0.17.*) -- which will indeed change every time it's built, but I don't know what it's used for.

Are you one of those users who wants to build his add-ons himself? Or are you doing this because it used to be necessary to get things to work?

Also, that pretty much confirms it. It's using a rectangular map for the little map window, no wonder it turns useless at the poles.

Yes. In my mind, either SCANsat's internal hardcoding of the aspect ratio of the map OR RPM/ssRPM's use of maps which do not have said aspect ratio is a bug. I don't know which I think is more incorrect yet.

Edited by technogeeky

Share this post


Link to post
Share on other sites
Great job! I am a bit out of the loop though, so... can I have that MFD thingy in any commandpod, or do I need the one you mention in the first post? And does it have features that help me plan a pinpoint descent, besides showing the map?

You can use any official or unofficial sensor you like, as long as you activate the sensor then SCANsat should operate normally.

The Orbit button will show you where your orbit descends to the surface, but only after you do your de-orbit burn.

A near future version of SCANsat should have support for the MechJeb landing reticle and the rover target reticle.

Share this post


Link to post
Share on other sites
I modified the ssRPM file, and the only change is for resetMap.

The next version of SCANsat and ssRPM will reference MechJeb to get landing target information and rover target information; but we'll cross that bridge when we get to it.

RPM, ssRPM, and mjRPM all have no declaration of assembly version -- which implies that they are set to 0.0.0.0 and behave as hard coded. There is some other file 'sharedassemblyversion' in the git repo which does have a stated version (0.17.*) -- which will indeed change every time it's built, but I don't know what it's used for.

Are you one of those users who wants to build his add-ons himself? Or are you doing this because it used to be necessary to get things to work?

I prefer NOT building them myself, but found it preferable to having to use out of date versions of the mods.

And actually, after getting about 1/3rd of the way through the files, I got bored and decided to do something else instead. Namely, the first 10 seconds or so of glancing at the code for your version of SSRPM enabled me to figure out how you got it to work as a drop-in on the pre-built release of RPM: you changed the RPM project reference to referencing the pre-built RPM dll instead. (I should've thought of that.)

So I installed release RPM, used your SSRPM, and then used the same trick on MechjebRPM to get it to work as a drop-in. It *seems* to work, but I'm in the process of inquiring if I applied the fix correctly.

And yeah, it's pulling the version # through sharedassembly.cs somehow; your SSRPM has a ver of 0.0.0.0, for example. SA.cs only specifies the first two fields, however. I don't know where it's getting the 3rd and 4th, but they're the ones that have been the problem as far as drop-in replacements (the pre-built release and the source of the release come up with different numbers in those two fields.)

The version only matters when one of the .dlls is used as a reference, though, so it's the version of RasterPropMonitor.dll that matters, not the versions of SSRPM or MJRPM. As long as SSRPM is built with the same version of RPM.dll that the user has, it'll work as a drop-in. If the user's got a different version, it'll blow up (which is why it didn't work on mine originally.)

Edited by Tiron

Share this post


Link to post
Share on other sites

I wanted to detect anomalies with the normal antennas, reasoning the anomalies would give out some distortions and/or wideband signals.

Adding the MODULE to all antennas was easy.


@PART[*]:HAS[@MODULE[ModuleDataTransmitter]]
{
//antennas can detect anomalies//
MODULE
{
name = SCANsat
sensorType = 16
fov = 5
min_alt = 5000
max_alt = 500000
best_alt = 250000
power = 0.01
scanName = multispectral scan
//animationName = Multi_Antenna
}
}

But can I also bind the activation of the scan to the activation of the antenna?

Share this post


Link to post
Share on other sites

?Hi guys,

Great job picking up the pieces after Damny went MIA! I'm very happy that scansat will live on.

I'm sorry if you guys have addressed this already, but I have a question: have you considered making some general purpose scanners so you can do more maps than just the biome map? I'm thinking specifically of linking into the Open Resource System (ORS) that Fractal_UK has written. Interstellar mod is using that for various maps and now the Modular Kolonization System is going to start supporting those resource maps. Is there any chance you guys will be linking into this?

Thanks again!

Share this post


Link to post
Share on other sites
You can't change the small map to show biomes. It either shows high resolution or low resolution altimetry, depending on the scanner.

Will you plan to add such feature?

Share this post


Link to post
Share on other sites
Will you plan to add such feature?

The small and large maps live in two different worlds.

Adding biome maps (and slope maps) would technically be possible for the small map, but I'm not sure how useful they would be. The borders used on the biome map don't come out well at such a small scale. You can shrink the big map down to almost the size of the small map (400 pixels wide vs. 360 pixels for the small map), and already it's clear that the biomes just get crushed into a bunch of white borders.

Share this post


Link to post
Share on other sites

is eve a scannibal planet with scan sat v 6 as all i get is a blank screen at an altitude of 2500m

Share this post


Link to post
Share on other sites
is eve a scannibal planet with scan sat v 6 as all i get is a blank screen at an altitude of 2500m

2500m is way inside the atmosphere.. do you mean 2500km? Because that's too high for any of the scanners..

Share this post


Link to post
Share on other sites

here is a screen on what i am trying to do Ive left it for a few orbits and both the biig and small maps are blank my earth mun and duna satellites are working fine though

2b14p3.jpg

sorry for the edit i have got both low res scanner and biom scanner on this sat

Share this post


Link to post
Share on other sites
here is a screen on what i am trying to do Ive left it for a few orbits and both the biig and small maps are blank my earth mun and duna satellites are working fine though

You're orbiting far too high for your sensors to be effective.

Share this post


Link to post
Share on other sites

That's too high for even the hi-res scanner to work - that has a ceiling of 800km. You're about fives time too high for the scanners you have to work.

I hope that satellite has some way of getting closer.

EDIT: Oh and see the 'LO', 'BIO' and 'ANOM' under the small map there? As it say in the OP, "the solid ORANGE tells you that you are not scanning -- your altitude is too high for this scanner." They need to either be flashing orange/green (not ideal but it'll work) or solid green (ideal altitude). The altitude of the scanners is found in both the OP and ingame in the part list.

Edited by ObsessedWithKSP

Share this post


Link to post
Share on other sites

thanks thought i had it wrong but was not sure i finally saw my mistakes and brought her down to a far more reasonable height

thanks again for the help

Share this post


Link to post
Share on other sites

The operational altitudes for all scanners are visible in-game in the "right-click for more info" window in the VAB/SPH.

Share this post


Link to post
Share on other sites

thanks again for the help

so i got the low rez map working but am now unable to get the biome or the anomalies to scan

Share this post


Link to post
Share on other sites

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.