[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[DMagic]

I see nobody yet provided info about the above question.

Thanks. MeCripp also mentioned the Modular Kolonization System that I think adds four Kethane Resources, though one of them is Ore, and I'm not sure if that's the same as the one used by Extraplanetary Launchpads. So that's a lot of potential resources...

Am I right that ORS has no persistent method for storing or displaying resources? There is no in-game map, it just shows you resources that you are currently picking up with the scanner (and apparently some kind of indicator texture of some sort)?

If so that should greatly simplify adding support for it. I wouldn't have to worry about pulling any data out of some ORS database or re-syncing said database with the SCANsat record after background scanning. I'm actually thinking that it might not even require any dependency on the ORS plugin (or the KSPI plugin, or whatever it uses).

On the other hand, it looks like ORS is designed to allow for the .dll to be distributed with other mods. It should be simple enough to include the ORS .dll, allowing me to add a hard dependency on the assembly; it wouldn't have any affect if you don't have any ORS resources, and it wouldn't require any awkward solutions like RPM, or what codepoet has been discussing with connected living space and ship manager. I'll have to look at it more to figure out what would work best.

[technogeeky]

I checked out the latest release on my regular, full installation of KSP. I put a bunch of vessels in orbit (without cheating!) with different sensors at difference altitudes. I checked scanning for all of the different sensors, everything seems to be working, both for regular scanning and background scanning. All of my attempts to break the big map failed, so that's a good sign.

I also did some brief testing without Toolbar and that was working fine.

There are a handful of very minor issues and one slightly less minor issue that I found. All of which, I think, can wait for another major update to fix.

The MapTraq has a non-functional "analyze data" action group available in the VAB, and the BTDT has both the action group and the right-click event for "analyze data", all of these should be removed. The commented out lines in SCANcontroller (437-439) that change the fov calculation also make it so the blinking orange/green light never goes away, at least I think that's what's happening. It doesn't affect scanning though. Also, I'm not sure if anyone really cares about this, but the MapTraq and BTDT are kind-of sunken into the part they connect to.

The line in their part.cfg file should be: node_attach = 0.0, -0.1, 0.0, 0.0, -1.0, 0.0, 0, currently it's: node_attach = 0.0, 0.1, 0.0, 0.0, -1.0, 0.0, 0 (flip the sign on the second value).

The less-easy to fix problem is that when the big map overwrites low resolution altimetry data with high resolution data it only changes the color. The blockiness of the low resolution data remains until you rebuild the big map cache (just change the size a little bit). This isn't a big deal, it's easy enough to rebuild the cache and it's probably not all that common to scan with a low resolution scanner, then do it with a high resolution scanner in such quick succession. I also discovered that the big map cache is persistent through vessel and scene changes, which is nice.

Also, I would hold off on adding caching to SCANsatRPM. It's resetting the map size every time the map rebuilds, so a cache wouldn't do anything but take up space in memory. I'm not entirely sure how it decides what size to set the map, so I don't know if this can be worked around easily. I'll try to test it out with RPM at some point and see if I can't get it to tell me what size it's setting the map at.

Otherwise I think it's fine, everything seems to be working correctly.

Well, the one person I trust the most says the v6 version is free of major bugs!

Anyone else using the v6 release and can report no major problems?

[phoenix_ca]

Thanks. MeCripp also mentioned the Modular Kolonization System that I think adds four Kethane Resources, though one of them is Ore, and I'm not sure if that's the same as the one used by Extraplanetary Launchpads.

Well I listed off all of them. Ore in MKS is exactly the same as in ExPL, so they share that resource.

Am I right that ORS has no persistent method for storing or displaying resources? There is no in-game map, it just shows you resources that you are currently picking up with the scanner (and apparently some kind of indicator texture of some sort)?

Yes.

Honestly at this point, from an end-user perspective, I'd say that if you guys can pull-off mapping for Kethane and ORS resources, it wouldn't matter if those mods had their own mapping systems. ScanSat would be a good enough replacement for the entire thing. ScanSat's already well established too (okay, sorta), so anything done with SS is going to be almost guaranteed to be more refined and feature-complete than anything added by Kethane or ORS.

Edited May 14, 2014 by phoenix_ca

[futrtrubl]

        public enum SCANtype
        {
            Nothing = 0,         // no data
            AltimetryLoRes = 1, // low resolution altimetry (limited zoom)
            AltimetryHiRes = 2, // high resolution altimetry (unlimited zoom)
            Altimetry = 3,     // both (setting) or either (testing) altimetry
            //Slope = 4,        // slope data
            Biome = 8,        // biome data
            Anomaly = 16,        // anomalies (position of anomaly)
            AnomalyDetail = 32,    // anomaly detail (name of anomaly, etc.)
            Everything = 255    // everything
        }

I don't even know what the heck the Altimetry = 3 setting is for, but last time I checked 3 isn't a power of 2.

The 3 is 0b00000011 ie both 1 and 2, the Lo and Hi res Altimetry, like the 255 is 0b11111111 for everything.

Can you not say have scanner 64 be a Kethane type scanner, and then look in the KethaneDetector MODULE on the part for the defined Resource{}s instead of trying to make one for every resource?

Edward

Edited May 14, 2014 by futrtrubl

[technogeeky]

The 3 is 0b00000011 ie both 1 and 2, the Lo and Hi res Altimetry, like the 255 is 0b11111111 for everything.

Can you not say have scanner 64 be a Kethane type scanner, and then look in the KethaneDetector MODULE on the part for the defined Resource{}s instead of trying to make one for every resource?

Edward

Yes, I'm aware of that. It's not that I don't know how bitmasks work; it's that it doesn't need to be defined if we are using this enum as a bitmask AND I didn't know where in the scansat code we actually use 3.

As for your suggestion; I don't know. Yes. If we continue to use this as a bitmask, then 4, 64, and 128 are available; so we could just take one. As for looking in the detector module -- no, that does not make sense. There is no reason to believe every kethane detector will detect every kind of kethane resource; regardless of that, you want to be able to see a map of each kind of resource regardless of the presence of such an able detector on your vessel.

Edited May 14, 2014 by technogeeky

[LameLefty]

Anyone else using the v6 release and can report no major problems?

I haven't invested a whole lot of time but (for reasons) I just did a 100% scan of Minmus with the SAR radar and the Big Map doesn't seem to be showing anomalies (or orbit tracks, craft icons or anything other than the map itself, despite button clicks to the contrary).

[technogeeky]

I haven't invested a whole lot of time but (for reasons) I just did a 100% scan of Minmus with the SAR radar and the Big Map doesn't seem to be showing anomalies (or orbit tracks, craft icons or anything other than the map itself, despite button clicks to the contrary).

If I had bothered to even launch the game after my last build, I would have seen this. I'll check it out.

I have had basically only an hour a day for some time to work on this. Happily, I have an extended weekend and all week next week off. So v7 should be pretty special.

[DMagic]

Can you not say have scanner 64 be a Kethane type scanner, and then look in the KethaneDetector MODULE on the part for the defined Resource{}s instead of trying to make one for every resource?

Edward

To be clear, these scanType shenanigans are only necessary for background scanning, simply adding an overlay doesn't require any of this.

And as for doing this for background scanning, it's basically what technogeeky said. Scanning data is recorded in an array that is stored in the persistent file. So once you have data scanned with any given scanner type it will be persistent and anything that refers to that scanType will see the same record. Even if you could delete the record for just that type of scanner this would still only allow for background scanning of one resource at a time.

TG's suggestion of using a different scanType enumeration is probably the best idea. That way nothing about the regular version would need to be changed and the new types could use all 255 available values.

In any event it's the dependency issue that really needs to be worked out, though I've just had some ideas on that, but I probably won't get anywhere soon.

[DMagic]

I haven't invested a whole lot of time but (for reasons) I just did a 100% scan of Minmus with the SAR radar and the Big Map doesn't seem to be showing anomalies (or orbit tracks, craft icons or anything other than the map itself, despite button clicks to the contrary).

The SAR scanner shouldn't pick up on anomalies anyway. I didn't have any problems with the orbit track, but I'll check on this some more.

[technogeeky]

I haven't invested a whole lot of time but (for reasons) I just did a 100% scan of Minmus with the SAR radar and the Big Map doesn't seem to be showing anomalies (or orbit tracks, craft icons or anything other than the map itself, despite button clicks to the contrary).

I suspect this is because we've introduced an incorrect check on the status of a boolean, scanning.

Can you check for me: activate/turn on any sensor on the vessel you had problems with, and see if the overlays work then (orbit icons, flags, markers, asteroids, etc)

edit: in addition, the buttons for stop/starting are behaving incorrectly for me. they seem to get stuck after one use. I am testing by using an existing craft on the launchpad.

edit edit: This behaviour (stop/start buttons not working "properly") seems to be related to my ship not having power. Similarly with the first thing comment.

So, LameLefty: does your ship have enough electric charge?

DMagic: however, there is a bug here. Steps to reproduce:

1. With some charge, start a scanner.

2. Allow the scanner to drain out the charge. (It goes blank before the static shows up; which is also incorrect)

3. While having no charge; turn off that scanner. The model will retract.

4. (Cheat): fill up your electric charge.

5. The scanner is consuming charge, but shows as off.

Edited May 14, 2014 by technogeeky

[DMagic]

DMagic: however, there is a bug here. Steps to reproduce:

1. With some charge, start a scanner.

2. Allow the scanner to drain out the charge. (It goes blank before the static shows up; which is also incorrect)

3. While having no charge; turn off that scanner. The model will retract.

4. (Cheat): fill up your electric charge.

5. The scanner is consuming charge, but shows as off.

I see it, I think I know why it's happening, it might be an underlying bug. I'm checking version 5 now.

I also rechecked the big map in Minmus orbit. The ground track and current vessel icon worked fine on the big map.

Edit: V5 works fine. I see the problem, it's because of this loop thing that it goes through with onUpdate checking for power usage. I just need to add one line to the stopScan event.

Edited May 14, 2014 by DMagic

[technogeeky]

I see it, I think I know why it's happening, it might be an underlying bug. I'm checking version 5 now.

I also rechecked the big map in Minmus orbit. The ground track and current vessel icon worked fine on the big map.

#5 should be amended to say "the scanner is consuming charge (and is still scanning), but shows as off"

The static does correctly come on when the electric charge hits 0.00, on more careful examination.

I don't remember if the bigmap overlays were drawn when all scanners were turned off before.

[DMagic]

I don't remember if the bigmap overlays were drawn when all scanners were turned off before.

I don't believe the big map was ever affected by power. I'm not sure that it should be, it would really just be annoying.

I fixed the problem, I just added the powerIsProblem line:

          [KSPEvent(guiActive = true, guiName = "Stop RADAR Scan", active = true)]
	  public void stopScan () {
          unregisterScanner ();
          powerIsProblem = false;
	  animate (-1);
	  }

My copy (or copies to be accurate) of the code are a total jumble right now, so I can't push it to Github. But I can make the other fixes to remove the analyze data buttons tomorrow and include everything together.

[technogeeky]

I don't believe the big map was ever affected by power. I'm not sure that it should be, it would really just be annoying.

I fixed the problem, I just added the powerIsProblem line:

          [KSPEvent(guiActive = true, guiName = "Stop RADAR Scan", active = true)]
      public void stopScan () {
          unregisterScanner ();
          powerIsProblem = false;
      animate (-1);
      }

My copy (or copies to be accurate) of the code are a total jumble right now, so I can't push it to Github. But I can make the other fixes to remove the analyze data buttons tomorrow and include everything together.

The big map overlays are currently affected by no active scanners. That is what I was asking about.

[DMagic]

The big map overlays are currently affected by no active scanners. That is what I was asking about.

I see what you mean now. That's how it's always been.

Adding the powerIsProblem line will fix the problem with the retracted-but-active scanner. The old version simply didn't allow you to retract the scanner while you didn't have power. I suppose doing it that way is another option, but personally I think it's annoying when you can't turn something like that off when you are out of power. After all, you can extend solar panels without power, so you should probably be able to turn off the scanner without power too.

[frik]

I understand correctly that SCANsat stores results in persistence file, so removing whole SCANsat v5 folder and replacing it with v6 won't mean I have to scan everything I already scanned once again?

[diomedea]

Am I right that ORS has no persistent method for storing or displaying resources? There is no in-game map, it just shows you resources that you are currently picking up with the scanner (and apparently some kind of indicator texture of some sort)?

If so that should greatly simplify adding support for it. I wouldn't have to worry about pulling any data out of some ORS database or re-syncing said database with the SCANsat record after background scanning. I'm actually thinking that it might not even require any dependency on the ORS plugin (or the KSPI plugin, or whatever it uses).

Definitely InterStellar (KSPI)/ORS have no persistency in displaying resources. But storing is another story.

Those 4 land geo-localised resources are each depicted on a pgn map (if InterStellar is installed, to be found in /GameData/WarpPlugin/PlanetResourceData), for each planetary body (currently, 37 maps come with KSPI 0.11, as some resources are only valid for some bodies, not all). Map dimensions are variable, most are 640 x 480, some less. All rectangular projections. I am no expert, but those maps appear to just be monochromatic, 255 levels of grey to show relative abundance of a resource at any given geographic coordinates. White dots on those maps are used to mark the spots that are revealed by KSPI scanners.

Scanning in KSPI is not persistent. Each resource is shown (directly over the body surface) only when a scanner is active and close enough. When moving away beyond some distance, the resource disappears.

Having a mapping tool like SCANsat would certainly help because of the persistency (though, I will then seek how to reduce the range of KSPI detectors to balance gameplay).

[technogeeky]

I understand correctly that SCANsat stores results in persistence file, so removing whole SCANsat v5 folder and replacing it with v6 won't mean I have to scan everything I already scanned once again?

This. Is. Correct.

[Tiron]

Good News Everyone! Someone reported the problem with the new build number system on the Mechjeb Dev Builds breaking hard dependencies, and it's been changed as of build #254, so dev builds of mechjebs are now drop-ins on RPM again (Tested successfully with #255). There was a change in the name of the 'target orbit' function in one of the dev builds, so it might not work *quite* right, but it doesn't completely blow up at least.

So one more RPM Rebuild and I should hopefully not have to do another one for a very, very long time. Never if Mihara stays on top of things.

I also want to suggest...that it would probably be a good idea to start a new post for SCANSat v6, since you can't get it in the first post of this thread. Call it 'SCANSat continued' or something seems to be the usual solution.

[technogeeky]

Good News Everyone! Someone reported the problem with the new build number system on the Mechjeb Dev Builds breaking hard dependencies, and it's been changed as of build #254, so dev builds of mechjebs are now drop-ins on RPM again (Tested successfully with #255). There was a change in the name of the 'target orbit' function in one of the dev builds, so it might not work *quite* right, but it doesn't completely blow up at least.

So one more RPM Rebuild and I should hopefully not have to do another one for a very, very long time. Never if Mihara stays on top of things.

I also want to suggest...that it would probably be a good idea to start a new post for SCANSat v6, since you can't get it in the first post of this thread. Call it 'SCANSat continued' or something seems to be the usual solution.

As I have mentioned: I am not going to start a first post until I am confident that the release is free of serious bugs. This is for many reasons, but among them are:

1. This will be the first Add-On Showcase release, so lots of new people will see it. I don't want to besmirch the reputation of SCANsat.
   
2. This will be my first official release of any kind, so I don't want to start off with a bad reputation.
   
3. There will be a new Showcase thread for the released version, and a new Dev thread for the upcoming version. This doubles the precariousness of #1 and #2.
   

I want to make a new thread as soon as possible too; especially because this will free me to start working on my own additions to SCANsat instead of making sure the existing product works as desired.

[phoenix_ca]

I am no expert, but those maps appear to just be monochromatic, 255 levels of grey to show relative abundance of a resource at any given geographic coordinates. White dots on those maps are used to mark the spots that are revealed by KSPI scanners.

You're right, mostly. The one caveat is that the resource maps can be defined using either a logarithmic scale or an linear one. This shouldn't actually matter for mapping as long as all you plan on doing is using a legend of 0-255. If you wanted to standardize it to some unit, you'll need to grab the scale values from the PLANETARY_RESOURCE_DEFINITION for that resource and do some math on it. This'd actually be great for users trying to figure-out relative abundance between different resources.

Also strictly speaking the hot spots aren't triggered by values of 255, but rather by absolute abundance times the displayThreshold value which will mark any spots with abundance higher than the result as hot spots.

HOW Fractal visualizes this at all so that he can make passable maps with reasonable scales is beyond me. I imagine a fair amount of math was done. That or a fair bit of tweaking. The benefit of his implementation is that it's very easy to adjust the entire map up or down with a config edit, and in a way that doesn't affect persistence files at all.

Edited May 14, 2014 by phoenix_ca

[Mecripp]

The maps in RPM look like there drawing or refresh is slower now in v6 and on a descent the orbit lines are behind the craft where in v5 they still showed about were you was landing.

[technogeeky]

I checked out the latest release on my regular, full installation of KSP. I put a bunch of vessels in orbit (without cheating!) with different sensors at difference altitudes. I checked scanning for all of the different sensors, everything seems to be working, both for regular scanning and background scanning. All of my attempts to break the big map failed, so that's a good sign.

I also did some brief testing without Toolbar and that was working fine.

There are a handful of very minor issues and one slightly less minor issue that I found. All of which, I think, can wait for another major update to fix.

The MapTraq has a non-functional "analyze data" action group available in the VAB, and the BTDT has both the action group and the right-click event for "analyze data", all of these should be removed. The commented out lines in SCANcontroller (437-439) that change the fov calculation also make it so the blinking orange/green light never goes away, at least I think that's what's happening. It doesn't affect scanning though. Also, I'm not sure if anyone really cares about this, but the MapTraq and BTDT are kind-of sunken into the part they connect to.

The line in their part.cfg file should be: node_attach = 0.0, -0.1, 0.0, 0.0, -1.0, 0.0, 0, currently it's: node_attach = 0.0, 0.1, 0.0, 0.0, -1.0, 0.0, 0 (flip the sign on the second value).

The less-easy to fix problem is that when the big map overwrites low resolution altimetry data with high resolution data it only changes the color. The blockiness of the low resolution data remains until you rebuild the big map cache (just change the size a little bit). This isn't a big deal, it's easy enough to rebuild the cache and it's probably not all that common to scan with a low resolution scanner, then do it with a high resolution scanner in such quick succession. I also discovered that the big map cache is persistent through vessel and scene changes, which is nice.

Also, I would hold off on adding caching to SCANsatRPM. It's resetting the map size every time the map rebuilds, so a cache wouldn't do anything but take up space in memory. I'm not entirely sure how it decides what size to set the map, so I don't know if this can be worked around easily. I'll try to test it out with RPM at some point and see if I can't get it to tell me what size it's setting the map at.

Otherwise I think it's fine, everything seems to be working correctly.

The following fixes are in:

* part.cfg changes for MapTraq and BTDT

* re-enable lower-than-ideal-altitude penalty (also fixes blinking)

* MapTraq and BTDT have been stripped of their Analyze events and actions

I went with values of 0.05 for 2nd component of the part.cfgs.

edit: nevermind that

Edited May 14, 2014 by technogeeky

[technogeeky]

The maps in RPM look like there drawing or refresh is slower now in v6 and on a descent the orbit lines are behind the craft where in v5 they still showed about were you was landing.

Checking on these two...

[DMagic]

The following fixes are in:

* part.cfg changes for MapTraq and BTDT

* re-enable lower-than-ideal-altitude penalty (also fixes blinking)

The part.cfg changes do not look right: now the scanners float above the surface upon which you are attaching them.

I don't know precisely what you mean about the VAB action groups, but I see nothing in the context menus for MapTraq or BTDT.

Those attachment node fixes probably aren't very important. The models aren't any good anyway, so it doesn't really matter if they sink in or float a little (also note that some of the stock parts have bad colliders, which make many parts float above their surface).

For the BTDT and MapTraq the analyze data action group is available to be set to a hot key while in the VAB. The fix for that is simple, though not very important.

I tested the fix for the no power bug a little more. It seems to be working, you can start and stop scanning with no power, the animation plays and the part behaves properly after power is restored. Maybe changing this so that you can only enable or disable scanning on EVA while there is no power would be a better idea. But for now it works.

I'm not sure why the ground track would be affected by any changes in v6, but I can see how the map update may be a little slower. I think there is some room to improve this in general beyond caching the IVA map. But that too can wait.

It seems that the map is always set at 640 * 640 pixels, at least the square map is. Do you need the ALCOR capsule to get that rectangular version of the map? Or am I missing something in the regular 1-man command pod? Either way, the map is pretty small, a cache should only take up a 1 or 2 MB of space. But I would like to figure out how it sets the screen size before I do anything to that, and more changes will be needed to make caching actually work.