[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[sarbian]

Nice to see someone working on this, I was a bit worried after month of no post from Damny.

[DMagic]

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

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

This would be tricky to do anyway. As far as I know the only identifier of asteroid class is the "size" value from DiscoveryInfo (0-4 for classes A-E). But regular vessels also have that value and once you dock to asteroid its value is overwritten by the vessel's size info, which I think defaults to 2. I'm getting around this by classifying asteroids by mass, but that only works once the actual asteroid part has been loaded at least once.

One thing that should definitely be added (because it gets asked about every other page on this thread) is to work the altitudes for each scanner into the VAB tooltip. I think putting them into GetInfo (the right-click-for-more-info button) would be the best idea since it would accurately reflect any changes made by users.

Maybe the MapTraq button should say "Start Scanners" or something to that effect instead of "Open Map", since it doesn't actually do that. Or you could make it actually open the map window.

Also, and I'm not sure if anyone cares about this, if you collect science results, save the game then quit, I think those results will be erased. I don't think this matters much, but if you didn't have a transmitter for some reason, or aren't able to transmit your results this would mean you would have to make a return trip to Kerbin without saving and loading (adding an EVA data collection method is also an option). It's very easy to save this information to the persistent file and pull it out again upon loading. There is also a better way of transmitting data, using the current method, if your transmitters are all busy when you try to transmit SCANsat data it just won't be sent. It's not difficult to add data to the transmitter queue the way it's supposed to be.

I'm sure there are some other things that will come to mind later.

[diomedea]

Thanks technogeeky for showing the plan. An orbit prediction feature indeed would be great, having it selectable (so to not always be shown, also because I suspect it may take some time to compute). Sure it will require a bit of time to find a perfect match of colors/opacity to render fine on the map.

Let me join others in telling, I'm happy to see somebody taking care for this absolutely needed mod (thanks to Dmagic, too). We can't say if, when, Damny will post again, and sure everybody is waiting more from him. But this mod has a lot of promise and it is a pity not to see it being further improved; if you are going to deliver some of what is possible with it (while keeping it as Damny would have done, and sticking with the license Damny chose), than I believe it is a service to the KSP community as a whole.

[technogeeky]

Thanks technogeeky for showing the plan. An orbit prediction feature indeed would be great, having it selectable (so to not always be shown, also because I suspect it may take some time to compute). Sure it will require a bit of time to find a perfect match of colors/opacity to render fine on the map.

Let me join others in telling, I'm happy to see somebody taking care for this absolutely needed mod (thanks to Dmagic, too). We can't say if, when, Damny will post again, and sure everybody is waiting more from him. But this mod has a lot of promise and it is a pity not to see it being further improved; if you are going to deliver some of what is possible with it (while keeping it as Damny would have done, and sticking with the license Damny chose), than I believe it is a service to the KSP community as a whole.

I'm happy to do it. To me, remote sensing is pretty much the most important step in space travel of any kind. The more information you can gather without sending our precious kerbals, the better! Well, they aren't so precious.

[CaptainKipard]

Could someone please explain what "Been there done that" does? Does it do anything that the Multispectral Sensor doesn't do?

[BudgetHedgehog]

Could someone please explain what "Been there done that" does? Does it do anything that the Multispectral Sensor doesn't do?

BTDT - senses and identifies anomalies (needs to be within rendering range)

Multispectral sensor - detects the different biomes (from orbit, can't remember ideal altitude)

[Hyperlynx]

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.

Gotcha. Thanks for the explanation

I've currently got four more radar sats en route to the Jool system, for the moons (Pol already has one), and one multispectral as a test case. Does this mean that I could scan Jool with the multispectral one, getting no data, but getting science from it?

[futrtrubl]

I have a bug to report. High inclination orbits with a large scan area causes it to scan the opposite pole. Eg. in my specific case, orbiting Minmus at 91 degrees inclination (ie slightly retrograde) at 250km circular orbit with the multispectral scanner, when I fly over the North Pole the corresponding Latitudes on the South pole are revealed as well. Ie it's treating it the body as a torus not a sphere.

Edward

[technogeeky]

I have a bug to report. High inclination orbits with a large scan area causes it to scan the opposite pole. Eg. in my specific case, orbiting Minmus at 91 degrees inclination (ie slightly retrograde) at 250km circular orbit with the multispectral scanner, when I fly over the North Pole the corresponding Latitudes on the South pole are revealed as well. Ie it's treating it the body as a torus not a sphere.

Edward

Confirmed. Eek!

[DMagic]

Confirmed. Eek!

I think this has come up before a few times. I'm guessing it's due to the shoddy way that KSP reports latitude and longitude. It doesn't limit the results to 0-180 and 0-360 (or -90 - 90 and -180 - 180) like it should. Sometimes it will tell you that you are at 450^o east instead of 90^o east for example.

It also might have something to do with the way SCANsat has to convert lat/long to integer values at some points during scanning rather than using more precise values. Maybe it's rounding values off in the wrong direction.

[technogeeky]

I think this has come up before a few times. I'm guessing it's due to the shoddy way that KSP reports latitude and longitude. It doesn't limit the results to 0-180 and 0-360 (or -90 - 90 and -180 - 180) like it should. Sometimes it will tell you that you are at 450^o east instead of 90^o east for example.

It also might have something to do with the way SCANsat has to convert lat/long to integer values at some points during scanning rather than using more precise values. Maybe it's rounding values off in the wrong direction.

I did not know that about KSP, but it doesn't sound wrong to me. I had to think about his original comment, and I'm not totally convinced, but I think he's right. As long as you're winding in one direction. It might be perfectly valid to get values above 360 or below 0 for longitude.. As you have seen, SCANsat has clamps on this value (though I don't notice as many on latitude).

I think (without writing down the examples and whatnot myself) that futrtrubi is describing it as properly as possible, though. It seems like somewhere SCANsat must be incorrectly doing edge identification for latitude. Looking at this page didn't help me think of the problem any better, but I think he's on the right track.

[DMagic]

It just needs a special case for very high latitudes. Check near the very end of SCANcontroller, where the fov value is being added to the current latitude to create the scan width before passing it off to data.registerPass. Adding or subtracting the fov value can result in latitudes higher or lower than +-90^o which creates this issue.

I added in this to get rid of it

            double laty = lat + y;
            if (laty > 90) laty = 90;
            if (laty < -90) laty = -90;

then replace 'lat + y' with 'laty' in the next line. It seemed to be enough to fix it for me. The same thing is happening for longitude, this shouldn't matter though since longitude uses a complete circle, not a half circle like latitude.

Edited April 23, 2014 by DMagic

[technogeeky]

It just needs a special case for very high latitudes. Check near the very end of SCANcontroller, where the fov value is being added to the current latitude to create the scan width before passing it off to data.registerPass. Adding or subtracting the fov value can result in latitudes higher or lower than +-90^o which creates this issue.

I added in this to get rid of it

            double laty = lat + y;
            if (laty > 90) laty = 90;
            if (laty < -90) laty = -90;

then replace 'lat + y' with 'laty' in the next line. It seemed to be enough to fix it for me. The same thing is happening for longitude, this shouldn't matter though since longitude uses a complete circle, not a half circle like latitude.

http://i.imgur.com/nqDg5lG.jpg

I confirm that your fix works. You're fixing more bugs than me and I'm the one claiming to be working on it!

You were right in more than one way -- the bug was related to rounding and truncating too (or at least, that is going on with f and f1 respectively).

[DMagic]

I confirm that your fix works. You're fixing more bugs than me and I'm the one claiming to be working on it!

Ha, I spent a lot of time in the SCANsat code when I was learning how to detect anomalies (though my method ended up being fairly different), since I didn't really know what was what I kind of looked around just about everywhere in the code. Also, there is a lot of SCANsat that is completely over my head, which was why I was hesitant to do much more than adding the toolbar support.

[technogeeky]

Ha, I spent a lot of time in the SCANsat code when I was learning how to detect anomalies (though my method ended up being fairly different), since I didn't really know what was what I kind of looked around just about everywhere in the code. Also, there is a lot of SCANsat that is completely over my head, which was why I was hesitant to do much more than adding the toolbar support.

All of your changes (minus some indentation changes which I have already overridden because of mass-commenting the code) are committed to release 6.

In addition, unless someone would like to explain precisely why I should not, I intend to make use of the toolbar plugin mandatory.

Reasons of various correctness follow:

1. [argument of toolbar's quality] I am pretty sure it can be included in the distribution and I believe the toolbar plugin claims to not conflict other versions of itself.

2. [argumentum ad populum] Many (most?) of us are already using the toolbar plugin.

3. [style] Having a separate, un-hideable button (as before) is incompatible with a notion of a well-integrated look and feel. This hurts our goals of eventual integration into KSP proper.

4. [user confusion] The old style button is also incompatible with the request by some to put SCANsat and/or MapTraq on all command pods. A floating button without an explanation of why it's there and no ability to remove it on all vessels could be confusing.

5. [Role Playing and/or IVA] The existing button is really 3 (or 4) functions in one. A user who wishes to see scanner values from Instruments but not the map itself can not currently do so.

6. [appeal to authority] I seem to be the only person to release a new version, and that makes me an authority. To whom I appeal. I choose toolbar only.

Also, dmagic: I think you neglected to give yourself (or someone else) credit for the toolbar icons. Nor did you grant us a license to use them. Shall I add the appropriate license and attribution?

Thanks for all the work!

Edited April 24, 2014 by technogeeky

[Virtualgenius]

Personally I hate the toolbar I have like 3 mods that must use it. Unless it's impossible to do personal choice is always best I feel

[likke_A_boss]

Personally, I love the toolbar and generally avoid mods that don't use it. They take up to much screen real-estate.

[technogeeky]

Personally I hate the toolbar I have like 3 mods that must use it. Unless it's impossible to do personal choice is always best I feel

It's not about possibility or impossibility. It's about economy. If I use the toolbar plugin, I get access to it and all of the useful stuff that he's already written (window positioning, labelling, window clamping, resizing, update checking, incomparability checking) as well as the potential to add new instruments, maps, and displays.

From my perspective it's a no brainer.

edit: And, like you said ... you already have it.

[Virtualgenius]

Yeah I am locked to it if i want crew manifest so its there, but i hate being locked to a dependency of another mod its like a game of dominos one falls they all fall if you know what i mean

[diomedea]

... unless someone would like to explain precisely why I should not, I intend to make use of the toolbar plugin mandatory.

Let me start telling, I am strongly in favor of using the Toolbar plugin. Your motives to choose to implement it are sensible to me.

However, there is no need to make the Toolbar mandatory. Generally the Toolbar is implemented with a wrapper, and it recognizes if the plugin is present or not, setting for use it in case. You only need to put code to call the wrapper and deal with button creation in both cases.

Believe you may also find this thread useful.

[Dweller_Benthos]

Since I'm already using the toolbar, making it mandatory doesn't concern me, so, vote yes! lol

[BudgetHedgehog]

Since I'm already using the toolbar, making it mandatory doesn't concern me, so, vote yes! lol

Likewise, but I think it'd be a bit unfair on people without it to make a hard dependency on it. I know plenty of other mods do but I feel the same way about them.

Also, I feel I must disagree with some of the various reasons technogeeky posted as justification. Argumentum ad populum and appeal to authority are both fallacies so they should not be used*. Regarding user confusion, I think it's fair to say that people voting to put SCANsat in all pods are not likely to be confused about the appearance of a satellite button on their screen. They know the reason they put SCANsat in all pods was to eliminate the need for the scanner part so I'm pretty sure they'd know why there is a scanning button but no part. As for roleplay/IVA useage, the current non-Toolbar button could be configured to provide a GIU menu on right click that shows the various options (small/big map, instruments, settings).

Like I said, I already use the toolbar, so forced integration has no impact on me, but I realise other people are in a different situation and might not appreciate it. I would suggest a poll or vote of sorts, but I don't think this thread is active enough to show correctly represented results. Maybe in the General Add-On Affairs board, I don't know. But saying you're coding it so any decision you make is the right one doesn't take the users opinions into account.

*Just because something is popular, doesn't mean it's right or the correct thing to do and "authorities are not necessarily correct about judgements related to their field of expertise". In this case, the field of expertise in question is coding a hard dependency on the Toolbar.

[Starstrider42]

Argumentum ad populum and appeal to authority are both fallacies so they should not be used*.

*Just because something is popular, doesn't mean it's right or the correct thing to do and "authorities are not necessarily correct about judgements related to their field of expertise". In this case, the field of expertise in question is coding a hard dependency on the Toolbar.

Actually, appealing to popularity is not a bad idea when it comes to interface design: http://en.wikipedia.org/wiki/Principle_of_least_surprise.

Edited April 24, 2014 by Starstrider42

[DMagic]

Also, dmagic: I think you neglected to give yourself (or someone else) credit for the toolbar icons. Nor did you grant us a license to use them. Shall I add the appropriate license and attribution?

Thanks for all the work!

Whoops, I forgot about that. This link has updated license info for the textures and the plugin (which is also included in the source), nothing else is changed: Edit: Go back to the original post if anyone wants to download this.

As for toolbar, I think I can easily solve that. The toolbar wrapper can easily be integrated into the code instead of making a hard dependency on the toolbar.dll. Rather than relying on the old icon, it should be simple to make the "open map" or "start scanning" buttons open the small map instead. I've already made a version that uses ToolbarWrapper, I haven't tested it much but I think it works ok. Allowing the buttons to open the map should not be an issue.

Edited April 25, 2014 by DMagic

[Zeroignite]

Toolbar integration would be one more step to having my UI be perfect. Another would be opening the Big Map and starting/stopping scan from within RasterPropMonitor displays.