[1.10.1] SCANsat [v20.4] -- Real Scanning, Real Science, at Warp Speed! [September 9, 2020]

[HaydenTheKing]

Scan Sat RPM how do i change different bodies within cockpit? I can only change overlay, and zoom.  I used to be able to cycle through bodies

Edited September 11, 2017 by HaydenTheKing

[tomf]

Is there configuration (a MM patch?) that would make the KSPI-E specific resources like nitratine show up in scansat?

[sh1pman]

Is the "Require Narrow Band Scanner" option still bugged? I can't get it to generate the precise resource data, even though it's in an ideal orbit. Everything works fine if I turn the option off.

output_log.txt

Spoiler

 

Edited September 15, 2017 by sh1pman

[DMagic]

@Kilo60 Did you scan that anomaly from orbit first? I should probably make sure that the orbital scan and the BTDT scan match up better.

@Duke Leto I have no idea about the accuracy of the Best Orbits calculations. If anyone is familiar with how they are calculated and wants to fix them that would be great, but otherwise I will remove the link.

@E Gadd A post a few pages back covers this: 

@HorusKol I'll have to look into contracts, but they were working fine for me the last time I checked.

@LN400 You can right-click on the waypoint itself (not the icon in the SCANsat maps) and delete it.

@HaydenTheKing Changing planets from RPM has never been supported. There aren't enough buttons on the standard MFDs. Making a separate display screen to handle this and maybe other functions would be an option, but I've never really looked into it.

@tomf KSPI planetary resources should all be supported by SCANsat. Non-planetary resources aren't supported by SCANsat maps. If KSPI has added more resources then support can be added, but SCANsat is running out of space for different scan types, so only a few more can be supported.

@sh1pman Does it work with any of the resources? Have you scanned the planet with both types of resource scanners, or just the high resolution scanner (it shouldn't matter, you can scan with either sensor without using the other one)? It's possible that something weird happened with the MM patches that is prevented from being recognized by the zoom map. 

[sh1pman]

@DMagic It didn't work with any of the resources. I've scanned the planet with both M700 and surface scanner. Not only the zoom map didn't show the accurate data, but the big map didn't show it as well, only rounded numbers. Again, all of these problems were solved when I turned off the narrow band scanner requirement, at which point I was able to get accurate readings for all resources on both maps.

[DMagic]

@sh1pman Probably something wrong with the MM patch then.

With the stock scanning enabled SCANsat just looks for the KerbNet module that covers that resource (which is basically always the Narrow Band Scanner). With the stock scanning off it looks for the SCANsat module. When the narrow band requirement is off it just ignores all of that.

Those displays in the right-click menu (Ore [Surf]: 12.27%) come from a different SCANsat module, which is probably why they seem to be working fine.

[sh1pman]

@DMagic maybe it's somehow related to the GPP planet pack I'm playing with? 

[Kilo60]

3 hours ago, DMagic said:

@Kilo60 Did you scan that anomaly from orbit first? I should probably make sure that the orbital scan and the BTDT scan match up better.

@Duke Leto I have no idea about the accuracy of the Best Orbits calculations. If anyone is familiar with how they are calculated and wants to fix them that would be great, but otherwise I will remove the link.

@E Gadd A post a few pages back covers this: 

@HorusKol I'll have to look into contracts, but they were working fine for me the last time I checked.

@LN400 You can right-click on the waypoint itself (not the icon in the SCANsat maps) and delete it.

@HaydenTheKing Changing planets from RPM has never been supported. There aren't enough buttons on the standard MFDs. Making a separate display screen to handle this and maybe other functions would be an option, but I've never really looked into it.

@tomf KSPI planetary resources should all be supported by SCANsat. Non-planetary resources aren't supported by SCANsat maps. If KSPI has added more resources then support can be added, but SCANsat is running out of space for different scan types, so only a few more can be supported.

@sh1pman Does it work with any of the resources? Have you scanned the planet with both types of resource scanners, or just the high resolution scanner (it shouldn't matter, you can scan with either sensor without using the other one)? It's possible that something weird happened with the MM patches that is prevented from being recognized by the zoom map. 

Hmmm, How do you Scan an Anomaly from obit First as it only shows up on the Map view as a "?"

[TheKurgan]

I have a question, I have created a couple of config files to enable the scanning and displaying of Karborundum through Scansat, and it works perfectly.

I want to use the mod "The Gold Standard" but the scantype is the same as what I have used for Karborundum (2^29)

So I changed the scantype of GoldOre to:

Spoiler

SCANSAT_SENSOR
{
    name = GoldOre
    SCANtype = 4294967296 //2^32
} 

and I changed the corresponding MM patch for the Orbital Scanner to:

Spoiler

@PART[OrbitalScanner]:FOR[SCANsat]:NEEDS[TheGoldStandard]
{
    MODULE
    {
        name = ModuleSCANresourceScanner
        sensorType = 4294967296
        fov = 3
        min_alt = 10000
        max_alt = 500000
        best_alt = 260000
        scanName = GoldOre Scan
        RESOURCE
        {
            name = ElectricCharge
            rate = 0.4
        }
    }
    
    MODULE
    {
        name = SCANresourceDisplay
        sensorType = 4294967296 
        ResourceName = GoldOre
    }

But it doesn't work... the option to start scanning for GoldOre exists in the Orbital scanner interface, but It will not "start"

and the option to display GoldOre on any of the Scansat maps doesn't exist. 

I'm lost, anyone know what I could be missing?

[DMagic]

@Kilo60 The ? on a SCANsat map means it has been scanned from orbit. With only that scan, when you are close the anomaly the Instruments window should show "Unknown Anomaly", with the BTDT scan and the orbital scan it should show the name of the anomaly, and the little anomaly window.

@TheKurgan 2^31 is the max value.

[TheKurgan]

54 minutes ago, DMagic said:

2^31 is the max value.

 

@DMagicIt can only be a power of 2? Or a multiple of 2? Can I use 500? It seems to be working.

Edited September 18, 2017 by TheKurgan

[DMagic]

@TheKurgan Yes, you can replace any that you don't want (except for a few of the lower values that are reserved for standard SCANsat scans).

@sh1pman I think I see the problem. There is just a bug where the narrow band scanner requirement only works for scanners with just one resource. So for stock, with just Ore it would work because the scanner type matches exactly. Whereas with MKS, with its 10 or so resources all on a single scanner, they don't match exactly, so it doesn't work.

I have an update almost ready, it should fix this, along with some inconsistencies with how the anomaly scanners work, a few other bugs, and it makes some changes in how color palettes are defined. I'll probably wait for 1.3.1, just to make sure nothing breaks with that update.

[TheKurgan]

using scantype = 500 seems to be working... but I am messing with stuff I don't know too much about.

I don't want to modify the Scansat files, I'd rather use a patch. I know how to use MM to remove modules from a part, but I don't know how to make one to remove a scansat sensor.

 

[DMagic]

@TheKurgan 500 shouldn't work right, 512 (2^9) should be okay, that's SolarWind, a KSPI resource, 64 (2^6), Kethane, should also work.

[TheKurgan]

Ok thank you for your help, I appreciate it.

Any idea on the Module Manager patch to remove SolarWind?

[DMagic]

@TheKurgan You would just need to target the right node:

SCANSAT_SENSOR[SolarWind]
{
	@name = GoldOre
}

That should work, I think. Renaming a node after using the name to locate should work fine.

[TheKurgan]

Awesome, thank you again!!

[Gilph]

17 hours ago, DMagic said:

I have an update almost ready, it should fix this, along with some inconsistencies with how the anomaly scanners work, a few other bugs, and it makes some changes in how color palettes are defined. I'll probably wait for 1.3.1, just to make sure nothing breaks with that update.

Hi,

I had mentioned in a prior thread about the possibility if something like a Lander Finder. I'm playing GPP, and they are not big fans of flat spaces. No matter how I play with the slope color palette, I cant really find sections that have < 2 degree slope easily. Mousing over a zoomed in window with my mouse set to the slowest speed is not fun.

Will the color changes support defining something that will help?  If not, is there an easy way of exporting slope information? I realize there are zoom and height considerations, but I think some standard defaults can apply.  Maybe inputting a lat and lon and dumping slope values in 1degree increments in a square around that point into a log?

What do you think? Thanks

[DMagic]

@Gilph Slope maps are a real problem for SCANsat. The slope maps are basically the minimally acceptable accuracy for displaying slope information, they use very little data in calculating that information, and so they can't be relied upon too much. Generating more accurate slope data is a performance problem because of how the terrain data is obtained. The other slope readouts, the mouse-over for the map, and the data in the instruments panel, are much more accurate, they use a lot of data for a very localized position (8 points in a 5m grid around the center), but they only apply to either the center of the current pixel or the current vessel position.

The problem with slope is that it is very highly localized. The slope for one area can be significantly different from that 20m away. So when you represent slope on a map each pixel could easily represent several km on the surface, so a low slope at the center of a given pixel doesn't really tell you much about the actual terrain. You could theoretically export a data set with more accurate slope information (or take the already available terrain height export data and do slope calculations yourself), but again, at a reasonable resolution you would only end up with only a very rough estimate of the slope at any given area.

Zooming in very close to a location is the only real way to get any kind of accurate information about an area. But even then the standard terrain map (since the terrain colors are recalculated based on the local min and max terrain height) is basically as useful as the slope map.

[Gilph]

2 minutes ago, DMagic said:

@Gilph Slope maps are a real problem for SCANsat. The slope maps are basically the minimally acceptable accuracy for displaying slope information, they use very little data in calculating that information, and so they can't be relied upon too much. Generating more accurate slope data is a performance problem because of how the terrain data is obtained. The other slope readouts, the mouse-over for the map, and the data in the instruments panel, are much more accurate, they use a lot of data for a very localized position (8 points in a 5m grid around the center), but they only apply to either the center of the current pixel or the current vessel position.

The problem with slope is that it is very highly localized. The slope for one area can be significantly different from that 20m away. So when you represent slope on a map each pixel could easily represent several km on the surface, so a low slope at the center of a given pixel doesn't really tell you much about the actual terrain. You could theoretically export a data set with more accurate slope information (or take the already available terrain height export data and do slope calculations yourself), but again, at a reasonable resolution you would only end up with only a very rough estimate of the slope at any given area.

Zooming in very close to a location is the only real way to get any kind of accurate information about an area. But even then the standard terrain map (since the terrain colors are recalculated based on the local min and max terrain height) is basically as useful as the slope map.

Thanks for the response.

Since scouting for locations is often biome dependent (based on resources), one thing that may help is some sort of ability to zoom in very close and do mouseovers in an area. Wen a slope is below a certain number, the lat/lon and slope value gets written to a log. Today, I find a fairly flat slope in the middle of chaos, and if I move my hand slightly, I lose it and have to find it again. I've started writing an Autohotkey script to move the mouse one pixel at a time inside the zoomed window every .5 sec.  If I get a good slope number, I pause it and write it down. There has to be a better way.

Even when I set the slope slider to the lowest value to get the most contrast, a zoomed in window does not show much contrast between a 20% slope and a 2% one. Maybe an inverse setting to make flat parts a more intense color?

Thanks

 

[Kilo60]

On ‎9‎/‎18‎/‎2017 at 4:18 PM, DMagic said:

@Kilo60 The ? on a SCANsat map means it has been scanned from orbit. With only that scan, when you are close the anomaly the Instruments window should show "Unknown Anomaly", with the BTDT scan and the orbital scan it should show the name of the anomaly, and the little anomaly window.

@TheKurgan 2^31 is the max value.

OK... However, its not showing the name of the Anomaly at all for some reason when it has been scanned from orbit and on the ground with the BTDT scanner in close proximity?

 

What could be causing this?

[DMagic]

@Kilo60 I went back and actually looked at your screenshot. It's working exactly as it should. The name of the anomaly is MSL, its distance is 25.5m. The "No structures found" part is just an effect of this anomaly being different in some ways from others. I should probably change it to just leave that line blank if nothing is found for it.

[drtedastro]

Hello DMagic,

I just wanted to stop by and say hello and to see if you had thought any more on how we could have the ability to create, modify, save and use different pallets for the altimetry  plots in SCANSAT.  It would really, REALLY be useful to be able to do this, well at least for me... lol....

Thanks again for all of the great work and effort that you have / do put into this and your other mods.

Cheers.

[Geschosskopf]

Here's a strange one....  I'm using the Alternis Kerbol system, where all the stock planets have been moved around and given new, custom surfaces, but still all have the same names.  In this system, everything works EXCEPT the Big Map.  The small map works fine, fills in during scans, etc., and displays the custom terrain.  The % complete works and so do the science reports of the various scanners.

The problem with the Big Map is that the "Celestial Bodies" drop-down only lists the sun and Jool.  For instance, I just scanned Bop (a moon of Kerbin).  I watched this happen in the Small Map and all looks fine.  However, when I opened the Big Map, Bop wasn't on the list so I can't see the map there.  I've used SCANsat with other custom planet sets like OPM and never had this issue.

Is this a known thing with a workaround?  Thanks.

Edited September 24, 2017 by Geschosskopf

[drtedastro]

If i remember correctly, and boy that is a stretch.  I had problems with some of the planet packs showing until the major planet of that group was scanned.  I don't know if that will help, but it was a work around for me earlier.  so for your example, scan Kerbin and i 'think' bop will then be in the list.

for what it is worth...

Good luck