[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[lincourtl]

I just got to try out v6rc1, and it works really well. Great work!

I know you're working on just getting a release out, but here's what I'd like to see in upcoming releases...

1) Better coloring as was suggested earlier in the thread.

2) Normalized coloring. For instance, here's the elevation map for Bop, below. There's not a lot of visual information there. If the color maps were normalized to the min and max heights, then the maps would be a lot more useful, visually.

3) The ability to export larger maps than are displayed on screen, perhaps with the ability to specify the exported size in settings.

4) For markers, grids, orbits/groundtracks, and map keys to be included on exported maps.

5) The ability to export map data which could be used with GIS software

AHEM. COUGH. COUGH.

SCANsat v6rc1 for KSP [0.23.5]

SCANsat v6rc1 for KSP [0.23.5] SOURCE

Build 6 - 2014-04-28
--------------------


+ [REQUIRED] Update for KSP version 0.23.5. This version of SCANsat now requires KSP 0.23.5.

+ [ADDED] Added support for showing the vessel icons for Asteroids in orbit around the same
mainBody.

+ [OPTIONAL] Toolbar support. Built against 1.7.1. TOTALLY OPTIONAL. Though the experience
is better and more consistent with the Toolbar. [thanks DMagic!]


- [REMOVED] Removed the old expanding/contracting floating SCANsat button. Replaced instead with
either a Toolbar toolbar or with nothing, but maps become visible upon starting a scan. [thanks Dmagic!]


- [REMOVED] Non-animated parts no longer show an 'Extend' option in EDITOR. [... Dmagic is doing all the work!]


+ [COMPATABILITY] "Change access modifiers to allow for more control from RPM".
Yes, it's in quotes because I trust Dmagic THAT much.
[thanks Dmagic!]


- [BUGFIX] Scanning high inclinations with wide-enough FOV scanners
(ie, Multi, RADAR, but not SAR) will no longer reveal the opposite polar region. [thanks DMagic!]
[example orbit]: Minmus 250.000x250.000km @ 91.0 degrees


+ [HUMOR] This file is different, and so is TODO.txt.

+ [dev] Support for changing what you define as 'sea level'. Compiled to be default (ie, 0).
- [dev] Removed all unused declerations
+ [dev] switched to unix line endings.
+ [dev] switched to custom, but uniform formatting (for now done by MonoDevelop).
- [dev] removed windows commands in .csproj and .sln.
+ [dev] added unix commands. I will be happy to have both if I can be shown how.
+ [dev] added debugging and profiling support. Includes dummy executable.
+ [dev] [requires] that the SCANsat.dll be put directly in place (ie, GameData\SCANsat\.)
for debugging to work

[Virtualgenius]

Why not talk to Akatze who made the calypso scansat its very realistic performs well and looks good he might be interested in expanding his lineup page 64 post 640

http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping/page64

[technogeeky]

I just got to try out v6rc1, and it works really well. Great work!

I know you're working on just getting a release out, but here's what I'd like to see in upcoming releases...

1) Better coloring as was suggested earlier in the thread.

OK.

2) Normalized coloring. For instance, here's the elevation map for Bop, below. There's not a lot of visual information there. If the color maps were normalized to the min and max heights, then the maps would be a lot more useful, visually.

OK.

3) The ability to export larger maps than are displayed on screen, perhaps with the ability to specify the exported size in settings.

OK. I have thought about the "supersampling" technique that the B.O.S.S. (something something something screenshot) uses. I wonder if that technique is amenable to this kind of thing.

I suppose I already have several text field boxes (all integers so far, as it turns out) that I would need to add. I suppose two more wouldn't hurt.

4) For markers, grids, orbits/groundtracks, and map keys to be included on exported maps.

OK.

5) The ability to export map data which could be used with GIS software

Whoa, whoa, whoa! I'm not a supergenius.

Just kidding. I don't really even know where to begin on that one. The other four I can wrap my head around.

...

OK. They seem like reasonable feature requests.

[technogeeky]

Why not talk to Akatze who made the calypso scansat its very realistic performs well and looks good he might be interested in expanding his lineup page 64 post 640

http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping/page64

Interesting. I'm not sure I think it's better looking than the other ones, but that's not for me to decide.

Here are the parameters for the original SCANsat satellites:

Name    FOV    HalfFOV    AltitudeMin    AltitudeIdeal    AltitudeMax    LongName
RADAR    5.00    2.50    5000.00        5000.00        500000.00    SCAN RADAR Altimetry Sensor
Multi    4.00    2.00    5000.00        250000.00    500000.00    SCAN Multispectral Sensor
SAR    2.00    1.00    5000.00        750000.00    800000.00    SCAN SAR Altimetry Sensor

However, it clearly has totally different height profile:

MODULE 
{ 
    name = SCANsat 
    sensorType = 24 Altimetry + Biome
    fov = 4 
    min_alt = 5000 
    max_alt = 12000000 
    best_alt = 750000 
    power = 3.5 
} 
MODULE 
{ 
    name = SCANsat 
    sensorType = 1 [B]RADAR[/B]
    fov = 4 (down from [B]5[/B])
    min_alt = 5000 
    max_alt = 12000000 (up from [B]500000[/B])
    best_alt = 750000 (up from [B]5000[/B])
    power = 0.1 
} 
MODULE 
{ 
    name = SCANsat 
    sensorType = 2 [B]SAR[/B]
    fov = 4 (up from [B]2[/B])
    min_alt = 5000 
    max_alt = 12000000 (up from [B]800k[/B])
    best_alt = 750000 
    power = 1 
} 

Hmm...

Edited April 29, 2014 by technogeeky

[DMagic]

On the topic of parts, make sure to check out this post about fixing the hard-to-click multispectral scanner: http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping?p=1105732&viewfull=1#post1105732

It would be better just to get the Unity file and move the colliders, but failing that I think this will make it a little bit easier to use.

[frango9000]

hello im just about to test your v6rc1 but i was wandering, if i unify these values in the part.cfg for all sensors and place them on a sat will it work?

fov = x min_alt = x

max_alt = x000

best_alt = x

i dont want to have 3 or 4 sats scaning, just 1 per planet, maybe im just an idiot who missed something in the readme or in the OP but given that the documentacion of RCs aren't always perfect just cut me some slack

PS:Thanks for your work on the mod, it is great! Ill test v6rc1 and folowings as much as i can!

[technogeeky]

hello im just about to test your v6rc1 but i was wandering, if i unify these values in the part.cfg for all sensors and place them on a sat will it work?

i dont want to have 3 or 4 sats scaning, just 1 per planet, maybe im just an idiot who missed something in the readme or in the OP but given that the documentacion of RCs aren't always perfect just cut me some slack

PS:Thanks for your work on the mod, it is great! Ill test v6rc1 and folowings as much as i can!

I'm not sure I totally follow what you are asking, but I can give you the facts as I know them:

1) No matter what you choose for FOV, the settings in the .dll will never allow it to be higher than 20*.

2) You can just set the best altitude to exactly the minimum altitude, so everything above it will get the best FOV possible.

3) You can set the maximum altitude to whatever you want. 1,500 km should do.

I think you should be able to "unify" them (I take this to mean that you are adjusting all four sensors to have the same values -- not that you want to have one sensor only).

[frango9000]

I'm not sure I totally follow what you are asking, but I can give you the facts as I know them:

1) No matter what you choose for FOV, the settings in the .dll will never allow it to be higher than 20*.

2) You can just set the best altitude to exactly the minimum altitude, so everything above it will get the best FOV possible.

3) You can set the maximum altitude to whatever you want. 1,500 km should do.

I think you should be able to "unify" them (I take this to mean that you are adjusting all four sensors to have the same values -- not that you want to have one sensor only).

Sorry if i wasnt very clear, (English isnt my main language), but you understood correctly... thats precisly the info I needed, I just wanted to check if (and how to) placing all scaners on 1 sat, orbiting it to an efficient polar orbit that would scan for all diferent types of maps... (making 1 scaner part that scans for everything sould have the same effect but that is over my skill ATM, but that would be nice maybe for a new part that is far more advanced tchnologicaly and of course ulocked far later in the tech tree.

[lincourtl]

I have thought about the "supersampling" technique that the B.O.S.S. (something something something screenshot) uses. I wonder if that technique is amenable to this kind of thing.

I'd hate to see that, but only because my machine has just 2GB of memory. BOSS kills it every time. I took a look at the source code, and I'm having a really hard time understanding how ScanSat gets its data, and then creates a map. That's more a function of me being ignorant about how KSP and Unity works than your source code.

What exactly is it querying to get the height data of the surface? How do you decide on which color to use for a region? Are you averaging the heights for the circle enclosed by the base of the observation cone, or just using the center point of that circle as representative of the height of that region? What exactly is being stored in the persistence file, and how is it encoded?

Oh, and please don't take my previous list as a set of demands. It's just what I'd like to see. I want axial tilt, Van Allen Belts, and photon pressure too, but that doesn't mean I don't appreciate the game.

Thanks for all your work! It's fantastic to see this mod being worked on again.

Edited April 29, 2014 by lincourtl

[Ruedii]

I'm wondering if ScanSat should keep a cache of the data it's collected so far. This will save on time loading maps.

Additionally, I too would like to see a surface imagery scan. This one should probably just fetch directly from the textures. It should come in high-res and low-res varieties just like the altimeter, and possibly also have a "surface reflectivity scan" that only does the brightness. (This can be done by applying a color space conversion to the planet texture and selecting the Luminosity channel. If Unity doesn't have access to the graphic-acceleration of this color-space conversion option, you can do it with a shader.)

As a note, I really like the plugin.

[DMagic]

I'm wondering if ScanSat should keep a cache of the data it's collected so far. This will save on time loading maps.

It does, but if you mean it should keep a texture of each map cached then you would run right back into the problem that ISA had, huge amounts of memory usage.

What exactly is being stored in the persistence file, and how is it encoded?

If you really want to know about what is being stored and how it is encoded you can check out this Unity thread about the compression algorithm being used. http://forum.unity3d.com/threads/152579-LZF-compression-and-decompression-for-Unity

I'm not entirely sure what it's doing, but I think this is what's being used to convert the coverage map for each scanner, for each planet, into that string of gibberish stored in the persistent file.

Edited April 29, 2014 by DMagic

[lincourtl]

If you really want to know about what is being stored and how it is encoded you can check out this Unity thread about the compression algorithm being used. http://forum.unity3d.com/threads/152579-LZF-compression-and-decompression-for-Unity

Cool! Thanks, will do. I hadn't even considered it might be compressed data.

[technogeeky]

I'd hate to see that, but only because my machine has just 2GB of memory. BOSS kills it every time. I took a look at the source code, and I'm having a really hard time understanding how ScanSat gets its data, and then creates a map. That's more a function of me being ignorant about how KSP and Unity works than your source code.

I don't know yet either.

What exactly is it querying to get the height data of the surface? How do you decide on which color to use for a region? Are you averaging the heights for the circle enclosed by the base of the observation cone, or just using the center point of that circle as representative of the height of that region? What exactly is being stored in the persistence file, and how is it encoded?

I don't know yet.

Oh, and please don't take my previous list as a set of demands. It's just what I'd like to see. I want axial tilt, Van Allen Belts, and photon pressure too, but that doesn't mean I don't appreciate the game.

I very quickly learned to not worry about the intention of feature requests. I sorted the TODO.txt that came with v5 of SCANsat. I moved this item here, and that item there. I read every line and wondered what they were asking for.

Then I read some line about changing sea level and how some guy's wife liked a pink Mun, but he didn't.

I laughed at that request, assuming I would never do it.

Later that night, it was the first "new" feature I actually implemented and left in the code. .

So I'll take the lists in stride, try to understand the code quickly, and get to improving it.

Thanks for all your work! It's fantastic to see this mod being worked on again.

[technogeeky]

You can essentially ignore these: these are just screenshot dumps of variations on the theme of seeing more orbits. I want to delete them from my computer, so they go here:

http://imgur.com/a/1uh1O#0

Feel free to say if you like the look of any. Two of them includes experimental Solarized coloration, which I did incorrectly.

[technogeeky]

I think the best solution for drawing Orbits in general, is to divide up the current function into two (one which draws orbits, one which draws the equatorial crossings).

Then I can leave the default (read: small, not FOV proportional ) orbital tracks for the *vessels* themselves, and then overlay/underlay FOV tracks of significantly less opacity with FOV-proportional sized orbital tracks, for every available active scanner. This is necessary because they don't have similar FOVs.

[DMagic]

What exactly is it querying to get the height data of the surface? How do you decide on which color to use for a region? Are you averaging the heights for the circle enclosed by the base of the observation cone, or just using the center point of that circle as representative of the height of that region? What exactly is being stored in the persistence file, and how is it encoded?

Now that I've updated my mod I've been looking at this more carefully. I think my original post was basically correct. It stores a record of which regions of the map have been scanned and by which scanners. This is a grid 360 units wide and 180 units high with a value in each cell that shows which scanners, if any, have scanned each section of the map. Uncompressed this would use almost 65000 values for each planet, so it's a good thing this gets shrunk down.

This coverage map is used to determine which parts of the map can remain as the unscanned grey color, and which need to have values calculated. Both the small and the big map seem to use the same method for doing so, the big just does more of it.

Edit: Actually, it looks like the small map does cache the terrain height values, so it only has to build the map once after loading, then it can just repeat those cached values every time the scan line moves up the map.

For the small map the terrain height is queried for each degree of longitude as the red line moves up the map, so you get 360 calculations per line. For the big map it calculates values at every pixel along the red line, so you can easily have 1000-1500 calculations per line. Even shrunk down the big map is still 400-500 pixels wide. Maybe there is more of a difference, but I couldn't see it; they both seem to repeat the same code to calculate this instead of using a single method, so it's hard to say for sure.

The actual function used to calculate terrain height is provided by KSP's code. It takes a position and returns the terrain height from the center of the planet (so you just subtract the radius of the planet to get the height above "sea level"). The low resolution scanner seems to round off the lat/long values, while the high resolution scanner gives as much precision as possible.

The function requires some kind of conversion from spherical coordinates (latitude, longitude) to a vector. There seems to be a standard way of doing this that SCANsat doesn't exactly follow. It uses this method

Math.Cos(rlat) * Math.Cos(rlon), Math.Sin(rlat), Math.Cos(rlat) * Math.Sin(rlon)

Which is some kind of inverse conversion from spherical to Cartesian coordinates (actually, the x,y,z values * by the radius) using the equations in the wikipedia link above. This vector is then passed off to pqsController.GetSurfaceHeight.

The standard method that every other mod uses is

QuaternionD.AngleAxis(theta, Vector3d.down) * QuaternionD.AngleAxis(phi, Vector3d.forward) * Vector3d.right

That's about as opaque as it gets for me, but there might be some potential performance difference. At first glance I can see that the SCANsat method requires the extra step of converting every lat/long values from degrees to radians, maybe the second method does that later on, but it might make a difference.

I noticed it just a day or two ago, when switching from my full complement of mods to the development set. I didn't think about it at the time.

The Unity-to-KSP buttons definitely seems to be caused by other mods. I was testing Connected Living Space and Ship Manager when I saw this happen (and they seemed to be bugged out, not properly displaying their toolbar icons), after removing them it went away.

Edited April 30, 2014 by DMagic

[technogeeky]

Now that I've updated my mod I've been looking at this more carefully. I think my original post was basically correct. It stores a record of which regions of the map have been scanned and by which scanners. This is a grid 360 units wide and 180 units high with a value in each cell that shows which scanners, if any, have scanned each section of the map. Uncompressed this would use almost 65000 values for each planet, so it's a good thing this gets shrunk down.

This coverage map is used to determine which parts of the map can remain as the unscanned grey color, and which need to have values calculated. Both the small and the big map seem to use the same method for doing so, the big just does more of it.

Edit: Actually, it looks like the small map does cache the terrain height values, so it only has to build the map once after loading, then it can just repeat those cached values every time the scan line moves up the map.

For the small map the terrain height is queried for each degree of longitude as the red line moves up the map, so you get 360 calculations per line. For the big map it calculates values at every pixel along the red line, so you can easily have 1000-1500 calculations per line. Even shrunk down the big map is still 400-500 pixels wide. Maybe there is more of a difference, but I couldn't see it; they both seem to repeat the same code to calculate this instead of using a single method, so it's hard to say for sure.

The actual function used to calculate terrain height is provided by KSP's code. It takes a position and returns the terrain height from the center of the planet (so you just subtract the radius of the planet to get the height above "sea level"). The low resolution scanner seems to round off the lat/long values, while the high resolution scanner gives as much precision as possible.

The function requires some kind of conversion from spherical coordinates (latitude, longitude) to a vector. There seems to be a standard way of doing this that SCANsat doesn't exactly follow. It uses this method

Math.Cos(rlat) * Math.Cos(rlon), Math.Sin(rlat), Math.Cos(rlat) * Math.Sin(rlon)

Which is some kind of inverse conversion from spherical to Cartesian coordinates (actually, the x,y,z values * by the radius) using the equations in the wikipedia link above. This vector is then passed off to pqsController.GetSurfaceHeight.

The standard method that every other mod uses is

QuaternionD.AngleAxis(theta, Vector3d.down) * QuaternionD.AngleAxis(phi, Vector3d.forward) * Vector3d.right

That's about as opaque as it gets for me, but there might be some potential performance difference. At first glance I can see that the SCANsat method requires the extra step of converting every lat/long values from degrees to radians, maybe the second method does that later on, but it might make a difference.

The Unity-to-KSP buttons definitely seems to be caused by other mods. I was testing Connected Living Space and Ship Manager when I saw this happen (and they seemed to be bugged out, not properly displaying their toolbar icons), after removing them it went away.

Luckily, I am already familiar with quaternions (and not just their application to rotations in space). Though I doubt we'll see any performance increase.

I'll be sure to enable caching of the big map, where possible. I don't understand the decision to cache the small map but not the big map. There is a strange mix of re-use for both maps, and differences for both maps. It must be for hysterical raisins.

I also intend to break up drawing the map into the grid shown by Grid, and drawing each box individually (including a partial scanline, or something that looks good). That way, I can avoid re-drawing the majority of the map and just re-draw the components where active vessels have made changes. I also hope to make the red scanline go in both directions, maybe. Depending on the current direction of motion (towards the descending or ascending node).

Thanks for taking a look at it for me. I hadn't gotten that far yet. I still need to rescue a few Kerbin from the Mun before I switch my development install back in.

[DMagic]

I'll be sure to enable caching of the big map, where possible. I don't understand the decision to cache the small map but not the big map. There is a strange mix of re-use for both maps, and differences for both maps. It must be for hysterical raisins.

I also intend to break up drawing the map into the grid shown by Grid, and drawing each box individually (including a partial scanline, or something that looks good). That way, I can avoid re-drawing the majority of the map and just re-draw the components where active vessels have made changes. I also hope to make the red scanline go in both directions, maybe. Depending on the current direction of motion (towards the descending or ascending node).

Thanks for taking a look at it for me. I hadn't gotten that far yet. I still need to rescue a few Kerbin from the Mun before I switch my development install back in.

I was thinking that another height_map array for the big map could be used to at least store values for a given map size. Whenever the map size is changed the array could be recreated with dimensions set at the current width/height of the map. Storing values for different sizes doesn't seem feasible, but at least you could keep the data cached for simply rebuilding the map with the same size, and maybe with different map types.

It looks to me like the code for the two maps was created at different times since they seem to be so completely isolated. I'm guessing that the small map code has remained mostly the same while the big map has had many features added along the way.

Maybe it would be best to unify the two. Use the same methods to create both maps with the difference being that the small map is continually updated and uses a fixed size array.

[TomatoSoup]

I've noticed that SCANSat doesn't seem to work with background scanning anymore. Did I miss an update?

[DMagic]

This looks promising. I implemented a very simple caching system for the big map to store the terrain height values for any already scanned pixels on the map. It has to be recreated every time the map is resized, but when simply rebuilding the big map it cuts down the build time for a nearly complete, low-res scan from around 17 sec to around 8 or 9 sec. The big map in my case was nearly full screen, about 1200 or 1300 pixels wide, the difference should be less the smaller the map is and greater the bigger the map is.

RAM usage didn't seem to be affected. It bounced up and down from around 950 to 1130 MB the entire time while testing both the standard and the cached version.

This was all very quickly setup with minimal changes made, so there could be a lot of room for improvement, but it's a good sign so far.

It breaks changes in map projection mode, so it would have to be recreated for each projection too (or maybe each projection could be stored in a separate array). The big map obviously has a huge combination of different styles and modes, so it's probably not possible to cache every possibility, but there's obviously room for improvement.

[technogeeky]

I've noticed that SCANSat doesn't seem to work with background scanning anymore. Did I miss an update?

In what way does it not work? As I understand it (I haven't made the test for this yet, lazily...) all you need is:

1. At least two vessels with the same kind of scanner around the same mainBody.

2. Both need to have the scanners active, and have enough resources (battery/solar) to sustain them for the desired time warp.

So assuming you fulfill these basic requirements, it should work. Which KSP (I assume 0.23.5) and which SCANsat version (I assume v5 or v6rc) are you using?

[TomatoSoup]

In what way does it not work? As I understand it (I haven't made the test for this yet, lazily...) all you need is:

1. At least two vessels with the same kind of scanner around the same mainBody.

2. Both need to have the scanners active, and have enough resources (battery/solar) to sustain them for the desired time warp.

So assuming you fulfill these basic requirements, it should work. Which KSP (I assume 0.23.5) and which SCANsat version (I assume v5 or v6rc) are you using?

I mean they don't scan in the background: the vessel must be focused to scan.

You're actually wrong on point 1. Prior to 23.5 I did all my scanning with a single vessel. As for point 2, they both had full batteries and, as I understand, Kerbal doesn't track electric charge on unfocused vessels, so they should have kept functioning.

What I mean is: Vessels and techniques that worked perfectly prior to 23.5 no longer seem to work.

[technogeeky]

DMagic:

Can we sync whatever is necessary to get both of us developing from the same master (ie, mine)? I presume that will mean adding back whatever is necessary to the .csproj and .sln files for you to build. I also converted everything to Unix-like line endings, and I think such a change will persist normally.

You mentioned that you didn't expect to be able to debug and/or profile with ksp-devtools and Visual Studio, but I think you should be able to (without Professional, even). The worst case scenario is that you would have to use MonoDevelop for such things (which is a pretty bad case). But I was able to get profiling results (which I'm told actually do represent complete time intervals, and not just number of function calls -- modulo the RTDSC inaccuracies and recursive functions). And I was able to get the debugger working, and to add breakpoints and watches.

I also want to do something to automate a few other processes (though I'm unsure exactly how to do them, but I think it's a good idea):

1. The building of the "first post" for the module, including re-building it for updated versions

2. The inclusion and appropriate copying/installation/removal of an example scanning vessel and several savegames/scenarios that needed to be tested. I have spoken with Pshwan (the original creator of the scanner calculator that I am working on simultaneously) and we tend to agree on a minimal set of scanning scenarios that need to be tested to ensure that both SCANsat and the calculator are working correctly. I believe that these would be included with the developmental version, copied to the appropriate places as long as you are building the Debug version (as opposed to the Release version), and removed afterwards.

3. Using those (or perhaps different) savegames to build / harvest / upload screenshots that would naturally be included in #1. That way, I can avoid the outcome that SCANsat (and other mods) fall victim to: having out of date screenshots which do not represent the full glory of the current mod version.

4. Get a Jenkins CI buildbot going, so users can see what development is going on (especially since you are a more prolific SCANsat developer than I am, at this point) and decide for themselves if they want to get dev versions.

As for what I'd ask you to do most urgently... Either:

1.) Change your .csproj and/or .sln files so that you are building from Source *in place* OR at least change the target of your build to be GameData\SCANsat itself (ie, where SCANsat.dll goes). The default for me was ${ProjectDir}\build. As long as I have disabled "Local Copy" (which simply seems to copy all of the .dll files that are required to build SCANsat to that build directory), this setting would be almost perfectly valid -- even if "in place" means what it does for me:

Kerbal Space Program\GameData\SCANsat\Source\build

Except that this requires a post-build hook which copies SCANsat.dll to:

Kerbal Space Program\GameData\SCANsat

And then a second hook which deletes:

Kerbal Space Program\GameData\SCANsat\Source\build\SCANsat.dll

I don't like running any post-build hooks if I can avoid it, but I

really

don't like running ones which delete files. I'm OK with the ones which copy the .txt files (and soon, all of the images, models, textures, and config files). I'm OK with having two versions: one with xcopy for Windows, one with plain old cp for Linux. I'm sure some other hooks will be necessary to get my above list going smoothly, too.

2.) OR simply destroy/rebase/rebuild your copies of SCANsat with my latest one; modify my latest .csproj and .sln files to fit your desired deployment configuration (so I can clearly see your choices and don't make mistakes manipulating paths), and I will merge them into the master (either as they are, if possible, or under Windows Debug / Windows Release).

I will note that it seems to be mandatory that I have the target directory of the SCANsat project (but not necessarily the .sln) be my GameData\SCANsat folder for debugging to work. I haven't tried symlinks for this scenario (though I suspect they would work) -- but I don't even know if I know enough Windows junction to setup a similar situation in Windows.

You are the more experienced developer here, so tell me what I should/shouldn't do and what I can change to be most correct. But I would really like to be able to directly use git to directly import your code and changes (like, for example, your bigmap caching attempts). So far, I have done everything manually because of differences in these things (and in differences in Line endings). (Another reason for me doing things manually is because some of your changes were whitespace-only changes that despite all my attempts did not fall out the diffs.)

Thanks,

tg

[Mecripp]

I mean they don't scan in the background: the vessel must be focused to scan.

You're actually wrong on point 1. Prior to 23.5 I did all my scanning with a single vessel. As for point 2, they both had full batteries and, as I understand, Kerbal doesn't track electric charge on unfocused vessels, so they should have kept functioning.

What I mean is: Vessels and techniques that worked perfectly prior to 23.5 no longer seem to work.

Had same problem but then remember had to click open map on the MapTraq part which, I added to my probe cores so just clicked on probe core and open map and all good now scanning in background.

[technogeeky]

I mean they don't scan in the background: the vessel must be focused to scan.

You're actually wrong on point 1. Prior to 23.5 I did all my scanning with a single vessel. As for point 2, they both had full batteries and, as I understand, Kerbal doesn't track electric charge on unfocused vessels, so they should have kept functioning.

What I mean is: Vessels and techniques that worked perfectly prior to 23.5 no longer seem to work.

I don't mind being wrong. I may be the future maintainer of SCANsat, but I am certainly not the author and more than 50% of the code has never seen my eyes. And I will switch back to my dev environment tonight, so I will check the code myself. And the following may be wrong, but I want to be sure I say what I mean to say carefully:

1.) In order to take advantage of background scanning, your active vessel must have some type of SCANsat sensor on it (even if it's just MapTraq). I relent and submit this statement instead of the previous one (which is weaker than my previous statement that the active vessel must have the same kind of scanner on it). I say this because I don't see a way for any of the SCANsat code to run when the active vessel is not even loading SCANsat in the first place.

As for #2, I think you are probably right re: background vessels and resource consumption. I do know that the active vessel must have enough charge to survive the draining of the batteries; otherwise, SCANsat starts to display static on top of the small map (I'm not sure if the battery must be empty or nearly so, but I have seen the static happen when I forgot to deploy my panels).

I do not really doubt that I'm wrong, and I started playing KSP about three or four days before 0.23.5 came out, so I don't have any base of experience on prior versions.

Regardless of the above, I again ask: which version of SCANsat are you talking about? I presume from your lack including that information that you are using the latest official release (v5) and not my (v6rc). The only change that I'm aware of is that vessels can now be SpaceObjects (which did not exist prior to 0.23.5). I'm not sure why this would break anything related to multiple vessel scanning, but I will check tonight.