technogeeky

Ugh. I give up for tonight. I'm tired of fighting the forums. Anyway, after looking at some of this data. I think there are *several* pretty significant performance enhancements that are low hanging fruit. I think for sure that the bigmap can be improved easily. Especially all of the (probably unnecessary) color function calls.

More output since I can't seem to edit my previous post... edit: This output was badly formatted and could not be recovered.

Here are some examples from the profiling output. I am using one of the ideal scanning altitudes, allowing it to run in 1000x until (roughly) the time of completion stated by the orbit. Along the way, I have the small map and the big map up, orbit enabled, and I press the Altimtery (since I'm scanning with SAR) button once in a while (not very scientific, I know) to update the big map. The resulting profile is 12MB. This is the orbit I ran (on the Mun, SAR, ideal 750k, max 800k): 79 41/74 (1.07) [B]519.466[/B] km 1.61 km [B]83.79[/B] [B]154h 09.0m +31.1m[/B] 5.2 0.03 90.74 m So ~ 25 days later, I ended up with 83.3 % coverage. Tons of gaps. I am taking a hit because I'm below the ideal altitude, which really kills the SAR. I'm thinking about exempting the SAR from this effect just to please the ideal orbit calculator (or at least to verify its correctness). Here is the first reasonable statistical profile sample I got (just a few functions listed, in order of highest overall percentage of time). 3.95% (7202) SCANsat.SCANdata.updateCoverage () 7202 calls from SCANsat.SCANcontroller.scanFromAllVessels () 0.81% (1476) SCANsat.SCANui.drawOrbit (UnityEngine.Rect,SCANsat.SCANmap,Vessel) 20938 calls from SCANsat.SCANui.gui_bigmap_build (int) 1 calls from UnityEngine.GUILayout/LayoutedWindow.DoWindow (int) 6596 calls to Orbit.getPositionAtUT (double) 4710 calls to SCANsat.SCANui.drawOrbitIcon (int,int,SCANsat.SCANui/OrbitIcon,UnityEngine.Color,int,bool) 2211 calls to UnityEngine.Color.op_Inequality (UnityEngine.Color,UnityEngine.Color) 1169 calls to CelestialBody.GetLongitude (Vector3d) 1025 calls to UnityEngine.Color.get_clear () 952 calls to CelestialBody.GetLatitude (Vector3d) 440 calls to UnityEngine.Texture2D.SetPixels (int,int,int,int,UnityEngine.Color[]) 424 calls to SCANsat.SCANui.drawLabel (UnityEngine.Rect,UnityEngine.Color,string,bool,bool) 336 calls to UnityEngine.Texture2D.GetPixels (int,int,int,int) 318 calls to CelestialBody.GetAltitude (Vector3d) 206 calls to UnityEngine.Color.op_Equality (UnityEngine.Color,UnityEngine.Color) 137 calls to SCANsat.SCANmap.projectLongitude (double,double) 102 calls to UnityEngine.Color..ctor (single,single,single,single) 84 calls to SCANsat.SCANmap.projectLatitude (double,double) 84 calls to SCANsat.SCANui.mapPosAtT (UnityEngine.Rect,SCANsat.SCANmap,UnityEngine.Rect&,Vessel,Orbit,double) 82 calls to UnityEngine.Color.op_Implicit (UnityEngine.Color) 73 calls to UnityEngine.Color.get_black () 61 calls to UnityEngine.Color.Lerp (UnityEngine.Color,UnityEngine.Color,single) 58 calls to SCANsat.SCANmap.scaleLongitude (double) 55 calls to double.ToString (string) 45 calls to Orbit.getObtAtUT (double) 41 calls to UnityEngine.Color.get_white () 34 calls to SCANsat.SCANmap.scaleLatitude (double) 33 calls to string.memcpy (byte*,byte*,int) 28 calls to System.Math.Atan2 (double,double) 0.43% (784) UnityEngine.Color.get_clear () 1025 calls from SCANsat.SCANui.drawOrbit (UnityEngine.Rect,SCANsat.SCANmap,Vessel) 78 calls from SCANsat.SCANui.gui_bigmap_build (int) 319 calls to UnityEngine.Color..ctor (single,single,single,single) 0.26% (470) SCANsat.SCANdata.drawHeightScanline (SCANsat.SCANdata/SCANtype) 4918 calls from SCANsat.SCANdata.updateImages (SCANsat.SCANdata/SCANtype) 3384 calls to SCANsat.SCANmap.heightToColor (single,int) 306 calls to PQS.GetSurfaceHeight (Vector3d) 175 calls to SCANsat.SCANdata.isCovered (double,double,SCANsat.SCANdata/SCANtype) 156 calls to UnityEngine.Texture2D.GetPixels (int,int,int,int) 115 calls to SCANsat.SCANdata.isCoveredByAll (double,double,SCANsat.SCANdata/SCANtype) 96 calls to UnityEngine.Color.get_black () 82 calls to UnityEngine.Color.Lerp (UnityEngine.Color,UnityEngine.Color,single) 67 calls to UnityEngine.Texture2D.SetPixels (int,int,int,int,UnityEngine.Color[]) 39 calls to UnityEngine.Color.get_grey () 12 calls to UnityEngine.Color..ctor (single,single,single,single) 4 calls to SCANsat.SCANcontroller.get_controller () 3 calls to UnityEngine.Mathf.Clamp (single,single,single) 3 calls to System.Math.Round (double,int) 1 calls to UnityEngine.Mathf.Clamp01 (single) 1 calls to Vector3d.get_normalized () 1 calls to string.memset (byte*,int,int) 1 calls to UnityEngine.Color.get_white () 1 calls to PQS.Mod_OnVertexBuildHeight (PQS/VertexBuildData) 1 calls to string.memcpy (byte*,byte*,int) 0.15% (277) SCANsat.SCANcontroller.get_controller () 4546 calls from SCANsat.SCANmap.heightToColor (single,int) 306 calls from SCANsat.SCANui.gui_bigmap_build (int) 300 calls from SCANsat.SCANui.get_c_good () 188 calls from SCANsat.SCANui.gui_infobox_build (int) 131 calls from SCANsat.SCANui.gui_show () 126 calls from SCANsat.SCANsat.OnUpdate () 68 calls from SCANsat.SCANui.drawLegend () This isn't actually about SCANsat at all, it's about MechJeb. But I'm saving it here for the moment. 1.42% (2579) GameDatabase.GetTexture (string,bool) 9711 calls from MuMech.MechJebModuleMenu.SetupToolbarButton (MuMech.DisplayModule,bool) 7 calls from MuMech.MechJebModuleMenu.SetupToolBarButtons () 5975 calls to string.op_Equality (string,string) 711 calls to System.Collections.Generic.List`1.get_Item (int) 454 calls to string.Equals (string,string) 0.26% (470) SCANsat.SCANdata.drawHeightScanline (SCANsat.SCANdata/SCANtype) 4918 calls from SCANsat.SCANdata.updateImages (SCANsat.SCANdata/SCANtype) 3384 calls to SCANsat.SCANmap.heightToColor (single,int) 306 calls to PQS.GetSurfaceHeight (Vector3d) 175 calls to SCANsat.SCANdata.isCovered (double,double,SCANsat.SCANdata/SCANtype) 156 calls to UnityEngine.Texture2D.GetPixels (int,int,int,int) 115 calls to SCANsat.SCANdata.isCoveredByAll (double,double,SCANsat.SCANdata/SCANtype) 96 calls to UnityEngine.Color.get_black () 82 calls to UnityEngine.Color.Lerp (UnityEngine.Color,UnityEngine.Color,single) 67 calls to UnityEngine.Texture2D.SetPixels (int,int,int,int,UnityEngine.Color[]) 39 calls to UnityEngine.Color.get_grey () 12 calls to UnityEngine.Color..ctor (single,single,single,single) 4 calls to SCANsat.SCANcontroller.get_controller () 3 calls to UnityEngine.Mathf.Clamp (single,single,single) 3 calls to System.Math.Round (double,int) 1 calls to UnityEngine.Mathf.Clamp01 (single) 1 calls to Vector3d.get_normalized () 1 calls to string.memset (byte*,int,int) 1 calls to UnityEngine.Color.get_white () 1 calls to PQS.Mod_OnVertexBuildHeight (PQS/VertexBuildData) 1 calls to string.memcpy (byte*,byte*,int)

Yes. That sentiment is very interesting in the context of this game. I wouldn't say useless. I would say: neither mod (chatterer and KerbQuake) add that much information to your experience. Chatterer chatter is meaningless, of course. And most of the shaking doesn't need to be happening to tell you what is going on with your craft. But the amount of immersion that is added is disproportionately increased. Small information, huge immersion. I love these kinds of mods.

I hope the above is meaningful enough to get the idea of the question I'm asking. I included the TimeControl.FlightScene.Update() example to show an example that most other functions from other mods (or indeed from KSP itself) have far fewer calls and far fewer runtime-invokes. edit: I've had enough KSP mod development struggle for today. Time to fire up the 64-bit version and play!

OK. I'm happy to report also, that I have Mono profiling working, and was able to capture some initial data on the (relative) performance of SCANsat. One of my goals is to try to speed up the redrawing of the Big Map, and the FPS loss associated with it (and especially with showing the Orbits). Is it easy/possible/trivial to get profiling going in Windows? I think you develop on windows...

This might be a bad question, but are you guys using profiling on MechJeb (the plugin or the parts)? I ask because I finally got profiling working. (using the legacy statistical profiler, on Linux). And my testing scanner craft for SCANsat happens to use the MechJeb probe. In terms of percentage of total time, and after discarding the first few largest percentage items (because they are native things like object.runtime_invoke_void_this, etc ... the first few high percentage items wereMuMech.MechJebPod.Update (mostly MuMech.MechJebPod.AdvanceAnimationTo with ten thousand calls) with 13% of all calls, then MuMech.MechJebCore.OnGUI(), then DrawGUI(), with 12.22% of all calls. Another way to look at this data set is to example the calls to object_runtime_invoke_void_this(), where MechJeb has a factor of 2 to 10 more calls than any other caller. In other words, I wonder without knowing anything about MechJeb code if some of these functions are running more often than is ideal. Isn't there some vague technique where you want to only make/allow calls when something has changed (and merits a redraw or something)? Pardon me, as I'm really speaking out of ignorance here. This is my first set of 'clean' profiling results (clean as in, does not contain all of the loading and is a nice 30 second sample). I was just surprised to see so many calls to MechJeb functions compared to... everything else. In some cases, it appears to be an order of magnitude difference. Obviously, if you want the profiling results I can try to put them up somewhere. The capture file is ~ 7 MB (even for only 30 seconds). I really need to strip out all of my mods for my dev environment version of KSP. edit: It's really hard to get good output that I can copy/paste, since emveepee doesn't allow it. There is a tool to dump some of the output into a text file, which I have done, but it does not have the same ordering. So I will just paste some random profile results: 0.00% (4) MuMech.MechJebPod.AdvanceAnimationTo (UnityEngine.Animation,string,single,single,single) 10746 calls from MuMech.MechJebPod.Update () 10724 calls to UnityEngine.Animation.Sample () 16 calls to UnityEngine.Animation.get_Item (string) 1 calls to UnityEngine.Mathf.MoveTowards (single,single,single) 1 calls to UnityEngine.AnimationState.set_weight (single) 0.00% (0) MuMech.MechJebPod.Update () 10891 calls from object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) 10746 calls to MuMech.MechJebPod.AdvanceAnimationTo (UnityEngine.Animation,string,single,single,single) 0.00% (0) UnityEngine.Animation.Sample () 10724 calls from MuMech.MechJebPod.AdvanceAnimationTo (UnityEngine.Animation,string,single,single,single) 89 calls from TimeOfDayAnimation.Update () 4 calls from ModuleLandingLeg.AnimationInitialState () 10816 calls to UnityEngine.Animation.INTERNAL_CALL_Sample (UnityEngine.Animation) 1 calls to [/media/ssd/steam/SteamApps/common/Kerbal Space Program/KSP.x86](UNKNOWN) 0.02% (16) MuMech.MechJebModuleMenu.SetupToolBarButtons () 9684 calls from MuMech.MechJebModuleMenu.DrawGUI (bool) 1 calls from MuMech.MechJebCore.OnGUI () 7523 calls to MuMech.MechJebModuleMenu.SetupToolbarButton (MuMech.DisplayModule,bool) 1072 calls to MuMech.DisplayModule.isActive () 880 calls to System.Linq.QuickSort`1/<Sort>c__Iterator21.MoveNext () 130 calls to MuMech.MechJebCore.GetComputerModules () 41 calls to MuMech.MechJebModuleMenu.SetupMainToolbarButton () 4 calls to System.Linq.OrderedEnumerable`1.GetEnumerator () 3 calls to MuMech.DisplayModule.get_showInCurrentScene () 3 calls to [UNKNOWN MEMORY REGION] 2 calls to UnityEngine.Object.op_Equality (UnityEngine.Object,UnityEngine.Object) 2 calls to GameDatabase.GetTexture (string,bool) 1 calls to MuMech.MechJebModuleMenu.CleanName (string) 1 calls to MuMech.MechJebModuleThrustWindow.isActive () 1 calls to MuMech.UserPool.RecursiveUser (object) 1 calls to MuMech.MechJebModuleSettings.GetName () 1 calls to System.Linq.QuickSort`1/<Sort>c__Iterator21.System.Collections.Generic.IEnumerator<TElement>.get_Current () 1 calls to System.Linq.Enumerable.Cast (System.Collections.IEnumerable) 1 calls to object.stelemref (object,intptr,object) 1 calls to MuMech.MechJebModuleRendezvousAutopilotWindow.GetName () 0.01% (11) MuMech.MechJebCore.OnGUI () 10163 calls from object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) 9738 calls to MuMech.MechJebModuleMenu.DrawGUI (bool) 214 calls to MuMech.MechJebCore.GetComputerModule () 169 calls to MuMech.MechJebCore.GetComputerModules () 8 calls to MuMech.VesselExtensions.GetMasterMechJeb (Vessel) 8 calls to MuMech.GuiUtils.CheckSkin () 4 calls to System.Collections.Generic.List`1/Enumerator.MoveNext () 3 calls to UnityEngine.Matrix4x4.get_identity () 2 calls to [UNKNOWN MEMORY REGION] 1 calls to MuMech.MechJebModuleMenu.SetupToolBarButtons () 1 calls to UnityEngine.Vector3.get_zero () 1 calls to UnityEngine.Screen.get_width () 1 calls to UnityEngine.GUI.set_depth (int) 1 calls to UnityEngine.Matrix4x4.TRS (UnityEngine.Vector3,UnityEngine.Quaternion,UnityEngine.Vector3) 1 calls to UnityEngine.GUI.get_skin () 0.01% (9) TimeControl.FlightScene.Update () 479 calls from object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) 247 calls to int.ToString () 122 calls to KSP.IO.PluginConfiguration.SetValue (string,object) 88 calls to string.Concat (string,string,string,string) 6 calls to string.Concat (string,string) 2 calls to object.__icall_wrapper_mono_object_new_ptrfree_box (intptr) 1 calls to string.InternalAllocateStr (int) 1 calls to string.CharCopy (char*,char*,int) 1 calls to UnityEngine.Mathf.Pow (single,single) 1 calls to KSP.IO.PluginConfigNode.SetValue (string,object) 1 calls to System.NumberFormatter.NumberToString (int,System.IFormatProvider) 0.01% (7) MuMech.MechJebCore.Update () 601 calls from object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) 472 calls to MuMech.MechJebCore.OnSave (ConfigNode) 111 calls to MuMech.MechJebModuleThrustController.OnUpdate () 3 calls to UnityEngine.Object.FindObjectOfType (System.Type) 3 calls to MuMech.VesselExtensions.GetMasterMechJeb (Vessel) 2 calls to UnityEngine.Object.op_Inequality (UnityEngine.Object,UnityEngine.Object) 2 calls to UnityEngine.Object.op_Equality (UnityEngine.Object,UnityEngine.Object) 1 calls to UnityEngine.Input.GetKeyDown (UnityEngine.KeyCode)

I'm not sure I understand what's really going on. It's obvious that there is something listening on the right port (12345) but it does not do anything, nor does it send back OK or ERROR. I don't know why the telnet server in the "stat" debugger would not work. I can't find much documentation about it either. If you change MONO_PATH to be the lib directory of different versions, (and you use the associated KSP plugin) you have varying results: 1. /usr/lib/mono/4.5 shows "Off" and it works! Except you must use RightShift + RightAlt + F10 to toggle. 2. /usr/lib/mono/4.0 shows "Off" and it works! with the same exception. 3. /usr/lib/mono/3.5 shows nothing at all 4. /usr/lib/mono/2.0 shows "ERR" then nothing 5. /usr/lib/mono/2.0-compat shows "Off" and it works! With the same exception. edit: It works! You need to use RightShift + RightAlt + F10 to toggle the profiler. Unlike the other, always-enabled debug logs, I see my modules (and MechJeb, and all of the other mods I use... tsk tsk!) using significant (5-10%) of the time in the profiler. This means, I think, that I was just profiling when I had the green On text, and was not otherwise. Success! Also, you need to use the version 4.0 runtime with emveepee (as stated above). I used the version4.5 library in my run32-prof script, and that seems to work fine (4.0 might work fine too). But you must use 4.0 for emveepee, or it crashes.

OK. I have the emveepee and mprof-heap-viewer working fine. Though I don't see anything useful coming from mprof-heap-viewer, yet. All I did was pass the paramter --runtime=v4.0 to mono (in emveepee.sh for instance). It runs fine. It seems to "just" be the same output that mprof-decoder gives, except it's in a nice selectable GUI window. Off to try and figure out how to toggle on/off the profiler so I can get useful profiling data.

I'll take a look today. If everything is easy to understand to me (and it should be, I have spent a lot of time reading and commenting SCANsat code) then I'll incorporate it and release both toolbar and no-toolbar versions. At least with the toolbar version out there it will be easy, at a later date, to stop supporting the non-toolbar version IFF we add features that really need toolbar. I overestimated the ability for me to use the Toolbar functions from their DLL. All of the code in there is stuck in the Toolbar namespace, so I suppose it doesn't make sense for me to make use of it in SCANsat. I mainly wanted some of the window resizing / window clamping / window edge detection / version checking features. But I will just copy the relevant functions and include them in SCANsat instead.

I said it would be something stupid, didn't I? Yes, yes I did!

Thanks very much for this. I hope it will help me improve the performance of my mods. I am having trouble getting the toggleable profile...toggled. I'm in Linux, using your binary distribution. The run32-prof-control allows me to connect, but nothing happens no matter what I type in. Furthermore, the FPS plugin works great, and the profiler status appears as expected, but it is impossible to change with either Alt and F10.. or any other combination of keys I tried. Also, I am a little confused on how to get emveepee working. mprof-decoder works fine. But when I launch either emveepee or mprof-heap-viewer, I get: Missing method System.Type::op_Inequality(Type,Type) in assembly /usr/lib/mono/2.0/mscorlib.dll, referenced in assembly /usr/lib/mono/gac/gtk-sharp/2.12.0.0__35e10195dab3c99f/gtk-sharp.dll Unhandled Exception: System.MissingMethodException: Method not found: 'System.Type.op_Inequality'. at Gtk.Window..ctor (System.String title) [0x00000] in <filename unknown>:0 at Mono.Profiler.Gui.MainWindow..ctor () [0x00000] in <filename unknown>:0 at Mono.Profiler.Gui.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0 [ERROR] FATAL UNHANDLED EXCEPTION: System.MissingMethodException: Method not found: 'System.Type.op_Inequality'. at Gtk.Window..ctor (System.String title) [0x00000] in <filename unknown>:0 at Mono.Profiler.Gui.MainWindow..ctor () [0x00000] in <filename unknown>:0 at Mono.Profiler.Gui.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0 I'm sure these are errors on my fault (like I'm not pointing something to the appropriate lib, or I don't really have mono installed correctly or something). Can you perhaps point me in some direction? It will be difficult to make sense of the profiling results if they are obfuscated by all of the loading process and whatnot. I haven't yet tried the debugger, and I expect more boneheaded things to happen there -- so I reserve the right to ask again edit: I also should add: On Ubuntu 12.04, I needed to install autoconf for the mono perl build script to even get started. It hasn't finished successfully yet either, so I may need more deps. edit2: and bison. and gettext. and libglibmm-2.4-*. And that was all I needed to run the ./configure script for mono.

That is an excellent question. In general, no. The tolerance for that orbit is what it says. There should be a way to only get results whose tolerance is at least x kilometers, though. I'll look at that.

hehe. Obviously I knew they were logical fallacies. I had to look up their names. That's why I put "over varying correctness." Those reasons were essentially jokes.

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.

Considering this thread started only on April 14th, and it now has 48 pages of posts... Perhaps we should give the author a break before we burn him out!

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!

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).

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.

Confirmed. Eek!

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.

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.

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?

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.

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.