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

[DStaal]

2 minutes ago, Mapoko said:

Why I can't see any anomalies ?

I've scanned everything in Kerbin system and I have drones flying towards Duna and Eve. But I can't see the anomalies.
Why ?

What scanner are you using?  The anomalies are picked up by one of the biome scanners.

(Also: Make sure you have the latest version of the mod.  There was a bug recently where anomalies weren't picked up.)

[overkill13]

On 1/28/2019 at 2:11 PM, DStaal said:

What scanner are you using?  The anomalies are picked up by one of the biome scanners.

(Also: Make sure you have the latest version of the mod.  There was a bug recently where anomalies weren't picked up.)

Which version had the bug?  I'm using Scansat v18.9 with KSP 1.5.1 and my biome scanner hasn't found any anomalies either.

[DStaal]

50 minutes ago, overkill13 said:

Which version had the bug?  I'm using Scansat v18.9 with KSP 1.5.1 and my biome scanner hasn't found any anomalies either.

18.9.   Technically if you had a part that was only an anomaly scanner it should work, but there aren't any such...

Try 18.10.  (Or possibly 18.8.)

[overkill13]

Ah, so that multiple sensor bug.  Alright, I'll give 18.10 a shot in 1.5.1. 

[overkill13]

For anyone interested.  18.10 seems to be functioning fine in KSP 1.5.1.

[MrSystems]

First, let me say I love this mod! It feels like doing real science.

Second, let me lodge a slight complaint: the maximum altitude for biome scanning is above the height of the atmosphere (580km) for the Saturn-equivalent in the OPM mod. I had to mod a config file to scan it. I don't use RSS, but if I did I'd have to do the same thing to scan Titan (atmosphere height 600km) and the four gas giants.

Might it be better for the optimum scanning altitude to be a function of the body's radius? The pixel resolution on completed scans, judging from my save file, is the same for all bodies large and small, and it might make sense if the optimum height returned a constant fraction of the body's surface. The optimum altitude would change linearly with body radius, so 250km over Kerbin is equivalent to 25km over Minmus, 208km over Laythe, 290km over Eve, and 2,200km over Sarnus.  Only Gilly (5.4km) would calculate at an unsafe altitude. Or at least in the code check the minimum safe altitude or atmospheric altitude for the body and set the max height to some multiple of that.

Thank you!

[BlackHat]

4 hours ago, MrSystems said:

Might it be better for the optimum scanning altitude to be a function of the body's radius? 

<snip>

Or at least in the code check the minimum safe altitude or atmospheric altitude for the body and set the max height to some multiple of that.

Part of the value for Optimum Altitude is the FOV. And the FOV is the same for a small body or a large body, because its based on the scanner. *Thus the height would be the same for Optimum Altitude.  So a large body might take 50 orbits to get 100% scanned and a small body can be done in 5. 

IF you set the Optimum Altitude to a % of radius, then all bodies would need 50 orbits to get 100% scanned. (Your closer and can see only a small piece of the body and therefore need more orbits)

BUT I do agree there should probably be an Atmosphere height check included in the calculation. (But I cant remember the values right now, I think all the scanners have a Min, Max and Optimum? I cant remember if the Optimum is the same as max. Maybe all we need to do is raise the Max to account for deep atmospheres. You can still surface scan, your just above the optimum)

Edited February 5, 2019 by BlackHat

[MrSystems]

1 minute ago, BlackHat said:

Part of the value for Optimum Altitude is the FOV. And the FOV is the same for a small body or a large body, because its based on the scanner. *Thus the height would be the same for Optimum Altitude.  So a large body might take 50 orbits to get 100% scanned and a small body can be done in 5. 

IF you set the Optimum Altitude to a % of radius, then all bodies would need 50 orbits to get 100% scanned.

BUT I do agree there should probably be an Atmosphere height check included in the calculation. (But I cant remember the values right now, I think all the scanners have a Min, Max and Optimum? I cant remember if the Optimum is the same as max. Maybe all we need to do is raise the Max to account for deep atmospheres. You can still surface scan, your just above the optimum)

I was arguing precisely that--that the number of orbits across all bodies should be roughly the same to complete a scan.  If you look in your saved game files, you will find the SCANsat readouts for each body that tell what has and has not been scanned. 

There's a section called SCENARIO { name = SCANcontroller } that tracks all the SCANsatting, and in that section there is a subsection called Progress that looks like

Body
			{
				Name = Kerbin
				Disabled = False
				MinHeightRange = -1500
				MaxHeightRange = 6500
				ClampHeight = 0
				PaletteName = Default
				PaletteSize = 7
				PaletteReverse = False
				PaletteDiscrete = False
				Map = CAABAAAA-----0AHQAAA...

The Map value continues on for about 3,972 characters, the same length for every body in the game. That means, Kerbin and Minmus get scanned at the same resolution, and one pixel of Kerbin's scan is therefore much larger in terms of surface area than one pixel in terms of Minmus' scan, proportional to the square of body radius. At 250,000m and 4° FOV you're looking at about 950,000,000m², which is 1/4700 of Kerbin but 1/47 of Minmus (and nearly 1/2 of Gilly).  Yet for all scans the same number of pixels are stored, so your scan of Minmus is 100x more detailed than your scan of Kerbin.  

So my argument is, continue using 4° FOV, or whatever it already is for all the different parts and types of scans, but set the altitude so that the FOV gives a certain surface area in proportion to the detail on the map.  If a pixel of Kerbin's scan is worth, say, one hundred thousand square meters, and a pixel of Minmus' scan is one thousand square meters, then you should have to get √(100)= ten times closer to Minmus to scan at that resolution. Doing so will also solve the issue with atmospheric height in any current or future planet mod with reasonable planets; by that same math the optimum scanning height for the Saturn-equivalent in OPM is 2,200km, nearly 4x the height of the atmosphere.

[BlackHat]

I dont know about the numbers in the save,

But I do know that when I scan Kerbin at 250km it takes a lot more orbits than it takes for Minmus at the 250km.

Which makes sense. IF your FOV is 50km wide at 250km, then it should not take as many orbits to do a smaller body at the same Altitude.

AND that's the effect I see in game.

[eatU4myT]

I don't know enough about modding to know whether this question is best posted here, or in the ProbesPlus! thread, so I'll ask it here for now!

Firstly, I love SCANSat, thanks for all your hard work!

After a bit of a break from KSP I'm starting a new 1.6.1 career and collecting together the mods I can't seem to live without (OPM, SVE, Scatterer, Distant Objects, Snacks! etc...)  SCANSat is on the essentials list, and I'm trying ProbesPlus! as well for the first time, as it looks as though there are some lovely part models in there.  I've noticed there are some alternative models for SCANSat parts, and I've paid the Entry Purchase fee for their version of the low-res scanner to build it into my next satellite.  However, I noticed that this hasn't met the condition in the Contracts screen that the "SCAN RADAR Altimetry Sensor" must be unlocked.  Its a very minor thing (I can cheat myself the funds to pay the Entry Purchase fee for the original SCANSat part, and then go ahead an use the ProbesPlus! part), but I wondered if there was a way of amending this contract so that unlocking the equivalent part from ProbesPlus! would meet the contract condition?

Thanks in advance for any responses.

Edited February 5, 2019 by eatU4myT
words are difficult

[DMagic]

@MrSystems @BlackHat The FOV value takes into account the celestial body's radius (based on the ratio of that body's radius to the home body's radius), so a scan of Minmus has a much wider scan width than that of Kerbin. But the variance is limited, I think the values are capped at an FOV of about 20, meaning a scan would uncover a 40x40 area on the surface (with maps for all bodies being divided into 360x180 unit grids), and the FOV will never go lower than the value in the config file when scanning at or above the ideal altitude (and below the max altitude).

The "resolution" or detail of the maps is basically irrelevant for everything by the low resolution altimetry scanner. All other maps are effectively infinitely detailed; you can zoom in to the point where you're looking at a few meters per pixel, or less.

Making the scanning altitude more complicated feels a lot like adding complexity for the sake of complexity. Having fixed altitude ranges means you never have to think about how high or low your orbit must be for a certain body. There are a few edge cases where modded planets are very large, but no MM patches are provided to adjust the SCANsat sensor altitudes, those cases would be best addressed by proving MM patches to do handle that.

 

@eatU4myT I think you would just have to add the other SCANsat parts to the Contract Configurator config files provided by SCANsat. I'm not really sure about the config format for allowing different parts to unlock the contract. Someone more familiar with Contract Configurator would have to handle that. It would probably be best to bring up the issue in the Probes Plus thread.

[eatU4myT]

25 minutes ago, DMagic said:

@eatU4myT I think you would just have to add the other SCANsat parts to the Contract Configurator config files provided by SCANsat. I'm not really sure about the config format for allowing different parts to unlock the contract. Someone more familiar with Contract Configurator would have to handle that. It would probably be best to bring up the issue in the Probes Plus thread. 

Thanks for taking a look.  I'll ask over there, as you suggest!

[MrSystems]

Thank you for the explanation, @DMagic.

I did look through the C++ code--not a language I'm fluent in--to see how the altitude was handled. It did not look to me like the body was referenced anywhere, and therefore any MM patches (like the one I wrote) would have to affect altitude equally across all bodies. Mine, for instance, just duplicated the part, called it "SCAN Multispectral Sensor Sarnus edition", and added a bit of cost and mass, but there would be nothing to keep me from using it at the new altitude over any other body. 

I would think any solution other than the cheat I came up with would have to involve reworking SCANsat.OnLoad in SCANcontroller.cs; it appears all the data in the foreach node_sensor in node_vessel loop would come directly from the part configs and there would be no way to use MM by itself to make a part function differently over different bodies unless the code were changed.

// starting at line 552
        public override void OnLoad(ConfigNode node)
        {
            ConfigNode node_vessels = node.GetNode("Scanners");
            if (node_vessels != null)
            {
                SCANUtil.SCANlog("SCANsat Controller: Loading {0} known vessels", node_vessels.CountNodes);
                foreach (ConfigNode node_vessel in node_vessels.GetNodes("Vessel"))
                {
                    Guid id = node_vessel.parse("guid", new Guid());

                    if (id == new Guid())
                    {
                        SCANUtil.SCANlog("Something Went Wrong Loading This SCAN Vessel; Moving On To The Next");
                        continue;
                    }

                    foreach (ConfigNode node_sensor in node_vessel.GetNodes("Sensor")) 
                    {
                        int sensor = node_sensor.parse("type", (int)0);
                        double fov = node_sensor.parse("fov", 3d);
                        double min_alt = node_sensor.parse("min_alt", (double)minScanAlt);  
                        double max_alt = node_sensor.parse("max_alt", (double)maxScanAlt);
                        double best_alt = node_sensor.parse("best_alt", (double)bestScanAlt);

                        registerSensorTemp(id, (SCANtype)sensor, fov, min_alt, max_alt, best_alt);

                        tempIDs.Add(id);
                    }
                }
            }

I might suggest (like I said, I've not used C++ or delved into the KSP API, so bear with me)

double min_alt = Math.max(node_sensor.parse("min_alt", (double)minScanAlt), 
                          SHIP:ORBIT:BODY:ATMOSPHEREHEIGHT);
double max_alt = Math.max(node_sensor.parse("max_alt", (double)maxScanAlt), 
                          SHIP:ORBIT:BODY:ATMOSPHEREHEIGHT * 2)
double fov = node_sensor.parse("fov", 3d) * Math.min(1,
                                                     node_sensor.parse("min_alt", (double)minScanAlt) / min_alt)

Something like that would narrow the FOV in the rare instance where the scanning altitude is raised but leave it unchanged otherwise.

[cyberKerb]

For the FOV value into the config, is it possible to set that value to less than 1 degree (eg, 0.75 degrees) or will it only accept whole numbers?

[Supermarine]

Hello!

I was wondering if SCANsat would work with Stock-Sized Real Solar System, but could not find any information anywhere.

I am aware that it works with the original RSS, though.

Sorry if this was asked before.

Thank you!

[DMagic]

@Supermarine It should work fine. It might be necessary to remove any existing SCANsat Module Manager patches from RSS. These would be required in regular scale-RSS for the SCANsat scanners to work at the higher orbital altitudes.

@wile1411 I don't think so. The FOV values eventually get converted to integer level numbers. So anything less than 1 would just get rounded up to 1, or maybe down to 0, which wouldn't help.

[Supermarine]

1 hour ago, DMagic said:

@Supermarine It should work fine. It might be necessary to remove any existing SCANsat Module Manager patches from RSS. These would be required in regular scale-RSS for the SCANsat scanners to work at the higher orbital altitudes.

@wile1411 I don't think so. The FOV values eventually get converted to integer level numbers. So anything less than 1 would just get rounded up to 1, or maybe down to 0, which wouldn't help.

Thank you DMagic!

[Jumberlack]

Hi, I'm trying to understand how this mod works, what is the reason behind the limited number of different resource channels and why must they be input in the cfg accompanied by a power of 2 up to 32? 

[DMagic]

@Jumberlack SCANsat uses a 32 bit integer array to store all of its scanning data. This allows it to specify which type of scan has been performed on each spot of a planet's surface. It also means that there are only 32 different scan types available (those values are 2^{^0} up to 2^{^31}). This could be switched to a 64 bit integer, but that would double the already significant amount of space in the save file required for saving all scanning data. It would also require a tricky one-time conversion of all old data to the new system. And it would probably affect overall performance of the mod, as this data storage array is constantly being accessed and updated.

The values are specified in the config file to allow users to set their own resource types if they are using something other than Community Resource Pack resources, or if they want some different combination of resources. 

[Loren Pechtel]

4 hours ago, Jumberlack said:

Hi, I'm trying to understand how this mod works, what is the reason behind the limited number of different resource channels and why must they be input in the cfg accompanied by a power of 2 up to 32? 

When you see things set up in powers of 2 like this you should automatically think bit flags--you can add together any combination of them and yet tell exactly what numbers were added together.  It's the most efficient method of packing such information and given that the author used it pretty much implies there was a lot of data to keep track of.

The storage units that such things get stored in have standard sizes of 8, 16, 32 or 64 flags, each of which uses twice as much memory as the next smaller size.  Also, KSP mods are written in C# and while it supports 64 bit unsigned values they can be a hassle to work with because the compiler is so strict about not allowing anything it thinks could possibly be wrong.

[infinite_monkey]

After trying out some WildBlueIndustries mods, I ended up with a different set of resources (ClassicStockResources instead of Community Resource Pack). Since I was already using MKS and WBI was messing up some resource converters, I deleted the WBI mods. While most other things work fine again, SCANsat still only shows ClassicStockResources. How can I fix that?

[UgoXT]

Hello all!

I apologize for such a simple question as I'm sure it's been answered here but I can't seem to find a post with a simple enough answer. I just recently came back to KSP after a few years and installed a few small mods to get me going again. Mainly Mechjeb and Scansat. However while Mechjeb seems to work with 1.6.1 despite giving me a compatibility error, Scansat does not. At least from what I can tell. 

I build and launch a satellite with what I think is required. M700 survey scanner, enough juice, and a comm antenna. Put it within the orbit requirements, 100k polarized. Yet none of the icons for Scansat appear in my UI nor does an entry get created in the KSPedia. I also added module manager yet the same issues remain. Any help is greatly appreciated as I'm fairly new to all of this again. Thanks!

[DMagic]

@UgoXT Do you have log files? Where did you download SCANsat from? How did you install it? It sounds like the problem is that it isn't installed right, as nothing is showing up.

[vardicd]

22 hours ago, infinite_monkey said:

After trying out some WildBlueIndustries mods, I ended up with a different set of resources (ClassicStockResources instead of Community Resource Pack). Since I was already using MKS and WBI was messing up some resource converters, I deleted the WBI mods. While most other things work fine again, SCANsat still only shows ClassicStockResources. How can I fix that?

I've run afoul of this one before, Dstaal explained to me how to fix it, but I can't remember if it will fix a save in progress or if you have to completely remove the scansat mod and stick a clean version in. {which would reset any scansat progress you've already gotten} Either which way, I give now to you:

The 'Classic Stock Resources' configs from Angel-125 override the 'Community Resource Pack' configs for ScanSat.  What you need to do is remove this file:

GameData/WildBlueIndustries/ClassicStockResources/Templates/Utility/Scanners_SCANsat.txt

Then you'll be able to use CRP resources again.

[DMagic]

At any time you can delete the scan data for any type of data.

If you change the existing scan types and want to reset the data, just go to the settings menu, choose the data type, and reset it for all bodies.