[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[technogeeky]

Silly question ... is anyone still actively developing this Mod? Looks like it's been 4 months since it was updated. Are there problems using it with 0.23.5 and the newest Unity version?

I am developing this mod actively. I have not yet released any new versions to the public yet. I intend to fix a few small bugs, and add both minor and major enhancements.

As far as I know, the mod generally works quite well. I have personally tested all of the sensors that ship with SCANsat, and they all still work. They all produce fine maps. The maps can be exported to PNG just fine.

[Virtualgenius]

Hi could you advise Mihara over at the Rastor prop monitor thread of any changes so he can compile a new scansatrpm, and its awesome your doing some development on this

Thanks

[BudgetHedgehog]

Hi could you advise Mihara over at the Rastor prop monitor thread of any changes so he can compile a new scansatrpm, and its awesome your doing some development on this

Thanks

I don't think Mihara has any plans to support anything other than the 'official' dll, due to either breaking SCANsatRPM for people who have the normal SCANsat or the trouble of maintaining two versions of SCANsatRPM. Don't get me wrong, if danmy says technogeeky can take it over, his will be the official build so everyone will be happy. Until then though, RPM will only support build 5 of SCANsat.

[Virtualgenius]

Technogeeky are you taking over officially from danmy ?

[Hexaphobia]

I noticed a small bug since the 23.5 update. I dont know if someone has reported it and honestly im too lazy to go threw 125 pages worth of posts to find out but.... it seams the ship icons are messed up? satellites show as rovers. ships as landers.... all of the mixed up. Im assuming this is because of the asteroids adding a new ship type and thus is throwing it off? It has effected Targetron as well, all my satellites have a rover icon. has this been discovered? if so is there a fix?

[Rioliki]

Im assuming this is because of the asteroids adding a new ship type and thus is throwing it off?

Precisely.

if so is there a fix?

Yes. Here it is. Also there are version with toolbar integration.

[Hyperlynx]

Update: I've just been able to radar scan Pol, and get science for it. If I switch to my Jool radar satellite, clicking the "analyse" button still doesn't do anything.

If that's by design, I disagree with it. Scanning a planet and not getting any data is still a scientific result. How would the scientists on Kerbin know there's nothing to see on radar until they tried it?

I don't get the impression it is by design, though, given that you get science for multispectral scans of Duna and Eve even though they don't have biomes.

[Mecripp]

Update: I've just been able to radar scan Pol, and get science for it. If I switch to my Jool radar satellite, clicking the "analyse" button still doesn't do anything.

If that's by design, I disagree with it. Scanning a planet and not getting any data is still a scientific result. How would the scientists on Kerbin know there's nothing to see on radar until they tried it?

I don't get the impression it is by design, though, given that you get science for multispectral scans of Duna and Eve even though they don't have biomes.

Jools is a gas planet ksp doesn't have anything for scansat to read on it as it just pulls the info from ksp guess you could us a mod to add something.

[Hyperlynx]

Jools is a gas planet ksp doesn't have anything for scansat to read on it as it just pulls the info from ksp guess you could us a mod to add something.

Yes. As I said, Duna and Eve don't have biome data either. Yet you can still analyse and get science for a map that is 100% static, from Duna and Eve multispectral maps, so why should I not be able to analyse and get science for a radar map of Jool that's 100% static?

[BudgetHedgehog]

Where are you all getting your science from?

Wait, really? Every time I try and analyse, I get the normal recover/transmit like a standard experiment, but all the numbers are 0...

[Hyperlynx]

Where are you all getting your science from?

Your guess is as good as mine...

Silly question, but you are analysing with a full map, right?

[BudgetHedgehog]

Your guess is as good as mine...

Silly question, but you are analysing with a full map, right?

If I say 'no', will I look extremely silly?

[DMagic]

Yes. As I said, Duna and Eve don't have biome data either. Yet you can still analyse and get science for a map that is 100% static, from Duna and Eve multispectral maps, so why should I not be able to analyse and get science for a radar map of Jool that's 100% static?

But there is a technical difference between not having a biome map, which the game reads as being an empty biome, and not having any terrain data. Conducting a scan (and having the science collection mechanism recognize that scan) would require some kind of special case for the sun and Jool. It's not that it can't be done, it's just that this probably isn't a high priority.

[alphaxerosyx]

Just returning with an update. I managed to get my Multispectral scan going. I installed the Action Group Manager mod, and added the part to its own action group while in Duna orbit. Didn't need to click on it for that, because AGM has a parts list. So I have the map, and all is well.

[technogeeky]

Technogeeky are you taking over officially from danmy ?

I haven't even asked him yet. I am preparing some bugfixes and changes so that when I do ask him, the decision will be a no-brainer.

[technogeeky]

Yep, the new "SpaceObject" and "Unknown" (I think that one is new) VesselTypes screw it up. A simple recompile fixes it.

Replace the SCANsat.dll file in the GameData\SCANsat folder with this one and it should work: http://www./download/a4v6v8r0d96ao89/SCANsat.dll

Though I make no promises about the reliability of this replacement, I didn't change anything and it should work fine.

DMagic:

Can you provide a link to the source of your version? You say you didn't change anything, but SCANsat keeps a local enum representing all of the possible orbit icons. So I suspect it needs to be changed to include the new types. And it may need a re-ordering to pick out the correct section of the texture for icons.

I figured out on my own that the addition of SpaceObject is probably responsible for some bugs (Flags not appearing). I don't know if Unknown is new or not (I don't think it is?). Either way, I don't understand how to get the enumeration from MapView and/or the OrbitIcons, and I don't quite understand how to know which icons are in what places in the appropriate texture. I asked a question about that in the plug-in development forum, and accidentally posted 'decompiled code' -- which got me an 'infraction.' Evidently the fact that MonoDevelop provides this (useless, honestly) information to me without me asking for it is not justification enough.

Anyway, I'm sure I'll include the toolbar changes and whatever else you have working into my first release. I also plan on SCANsat showing a specified number of future/past orbits on the Big Map, so ideally you can see 'at a glance' if your current orbit/inclination will cover the map or not. I may also try to include the optimum orbit calculator (which is currently written in Octave/Matlab code) directly into the SCANsat library.

[DMagic]

The source is included in my toolbar version download. http://www./download/u5egmogu8nisctq/SCANsat_Toolbar_V0_2.zip

I downloaded the SCAN-master.zip from Github, added my own class then repackaged everything for the download, so it should be identical to the Github version aside from my changes.

I actually looked at that OrbitIcons enum in SCANui and I couldn't quite figure it out either. It's clear that MapView has a method for retrieving those textures (MapView.OrbitIconsMap), but I'm not clear on how the SCANsat code takes an input from the OrbitIcons enum and translates it into something the MapView can use. I can see how it gets from a VesselType to an OrbitIcon, but there is some step after that that isn't clear.

I think it's not only the addition of a new VesselType that screwed up the orbit icons, but that those new types were added to the front of the enum, instead of the end. If it were the other way around (which to me makes more sense) I'm not sure that this would have caused problems in the first place. And yes, I think it's just SpaceObject that's new, since there is a reference to VesselType.Unknown in the existing SCANsat code (it just might not have ever been used).

I'm guessing that you don't have to worry about re-ordering the OrbitIcon enum to add in SpaceObject, since it is already a jumbled list of VesselTypes and other icons.

About the toolbar code. Adding a hard dependency on Toolbar is really simple, but since some people seem dead-set on not using Toolbar you'll probably need to allow for the default behavior to work too. I commented out the code necessary for generating the minimized probe icon, and made the UI ask whether the small map has been closed or not before drawing the window.

The probe texture code probably doesn't need to be commented out regardless of what you change (I did that before changing the window drawing behavior), but you probably will need to make some changes to allow for the default minimized icon to be used instead of the toolbar icon. The only other changes I made were to some access modifiers (from private to internal) and I changed the 'minimode' int to -2 instead of 2 when launching (maybe that's a bit of a personal thing, but I think windows should never start out opened by default).

Edit: Just had a minor epiphany. What if MapView.OrbitIconsMap doesn't get individual textures for every icon, but instead generates one big texture with each individual icon located on a grid within that texture? Then the texCoords from the GUI.DrawTextureWithTexCoords determines where on the grid the texture should be drawn from. That would explain why the OrbitIcon enum is used only for the tc_icon Rect.

Edited April 21, 2014 by DMagic

[technogeeky]

Edit: Just had a minor epiphany. What if MapView.OrbitIconsMap doesn't get individual textures for every icon, but instead generates one big texture with each individual icon located on a grid within that texture? Then the texCoords from the GUI.DrawTextureWithTexCoords determines where on the grid the texture should be drawn from. That would explain why the OrbitIcon enum is used only for the tc_icon Rect.

Yes. I knew all along that it was a single texture (after all, it's a texture, not a list or array of textures). I think the Enum was created by hand, by inspecting the icons texture visually and assigning numbers. You can see in the SCANsat code where multiplies / divides the value 'icon' by 5 and/or subtracts from 4. I think he's choosing the specific icon from the grid.

I would need to do the same thing so I could see the grid myself. I don't see a serious way to automate this process, and I just want to get it to work so I can move on to other things.

I'll be back later tonight to work on it. Hopefully you'll be around.

[DMagic]

Yes. I knew all along that it was a single texture (after all, it's a texture, not a list or array of textures). I think the Enum was created by hand, by inspecting the icons texture visually and assigning numbers. You can see in the SCANsat code where multiplies / divides the value 'icon' by 5 and/or subtracts from 4. I think he's choosing the specific icon from the grid.

I would need to do the same thing so I could see the grid myself. I don't see a serious way to automate this process, and I just want to get it to work so I can move on to other things.

I'll be back later tonight to work on it. Hopefully you'll be around.

Unity asset explorer to the rescue, once again. I think you'll need to open with photoshop or some equivalent. Just make sure the alpha channel is turned on and it probably needs to be flipped vertically. I pulled it out of sharredassets7.assets. I checked the file in a 0.22 installation I have and it looks like the SpaceObject icon is the only new one, located at 3 down, 4 across (starting with 0).

Edit: Or maybe you don't need to flip it, so it's 1 down and 4 across, or 19 in the enum.

Edit: Zap

Edited April 22, 2014 by DMagic

[Codey737]

I have a small problem,why is my altimetry map in gray when color is enabled?

[Starstrider42]

I have a small problem,why is my altimetry map in gray when color is enabled?

Low-resolution altimetry is always grey. To warn you that it's low-resolution, I presume.

[technogeeky]

Here is one of the "features" (hacks) I've been working on.

From this post we see that there should be a somewhat ideal orbit for the SCANsat SAR scanner:

95  32/55  (1.14)  748.550 km  1.53 km  80.58 173h 31.2m +25.3m    7.5  0.04  0.131 km

Here is the plugin in my development state.

Notice:

1. Asteroids now show up, with an icon and identifying name.

2. In the first picture, only the past component of the orbit is shown (minus the parts that I turned off the scanner).

3. The size of the orbit dots (roughly) matches the size of the swath width.

4. This orbit supposedly has a 32/55 resonance, so let's see how our coverage will be 35 or so orbits.

5. And how about 55 orbits?

Sure enough, it projects that "full coverage" (minus the part at the poles that we'll never get with this inclination) will require 55 orbits and it looks about right:

I have done some other re-factoring. For instance, I have moved all color definitions and color-related functions to a seperate file, so if people want to suggest alternate color schemes it should be much easier to do.

Thanks for DMagic for solving the icon problem for me.

I'll keep chugging away tomorrow.

Edited April 22, 2014 by technogeeky

[technogeeky]

One feature I thought of but rejected (for multiple reasons) was:

1. Make the size of the asteroid icon proportional to its class.

But I don't see how this would be useful, since we won't be scanning asteroids (yet, at least) and it's not that interesting to know what an asteroid is doing. So I don't know why it would be useful to know what the size of the asteroid at a glance.

What other suggestions / bug fixes need to be in the next release?

[diomedea]

The idea of making the orbit dots match with the swath width is neat.

However quite often I am interested to actually see the already scanned map, and those large dots get in the way. Would it be possible to allow the user to choose between dots of minimal size (just to represent the orbit) and the large ones you did?

[technogeeky]

The idea of making the orbit dots match with the swath width is neat.

However quite often I am interested to actually see the already scanned map, and those large dots get in the way. Would it be possible to allow the user to choose between dots of minimal size (just to represent the orbit) and the large ones you did?

Yes. I am currently using the same code pathway as the (current/next) orbit to draw an arbitrary number of future orbits. I am just doing this so I can see (at a glance) if my code to *predict* the number of orbits needed to cover is correct or not (it's not totally correct ). But this should really be a separate thing: there should be one button for the last/next orbit, and another button for orbit coverage prediction.

I think, if possible, that both icons should be sized according to the FOV of the current smallest scanner. But one should only show the previous/next orbit (as before) and be attached to one button (ie, the current Orbit button). The other should be attached some other button (say, an Orbit Predictions button).

The code is not correct yet either. First, the future orbits should be blue, not orange. And actually, I want the future orbits to be a rainbow of colors. I have already input the colors from Solarized. There are some clever ways to combine elements of that color palette. In reality, the code is currently backward-projecting all of the orbits in orange -- and blue just shows the one next orbit, no matter how many you ask it to produce.

Also the farther backward or forward you go, the more the opacity of the button should be diminished (perhaps in addition to having multiple colors). You can see some of the opacity reduction working here, but it's clearly not working correctly yet. I am just getting my feet wet.