[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[TinyPirate]

Can't we have a few options? Sounds perfect to me.

[15nelsoc]

This is a great mod. I modded it by sticking all the modules into the part model for the Kethane eye scanner. All three scanners work fine when activated. Wicked sweet. I'll be using this a lot in the future and I'll be sure to toss out any bugs/glitches I find (though some may be my forcing a combo into one part, but it works so far)

Do you mind posting the code you added to the config to get it to work?

[BananaDealer]

Do you mind posting the code you added to the config to get it to work?

Just copy and paste the modules from the SCAN scanners into the .cfg of the Kethane detector...

[15nelsoc]

Just copy and paste the modules from the SCAN scanners into the .cfg of the Kethane detector...

Thanks, just wanted to make sure there was nothing else going on.

[Dodecadevin]

I accidentally hid the map in such a way that the button is now off-screen. How can I reset the map window's position?

[OrtwinS]

I accidentally hid the map in such a way that the button is now off-screen. How can I reset the map window's position?

It doesn't reset upon reboot of KSP?

As prevention: Position limits for UI elements, so that the icon never leaves the screen, and maps (big&small) always have a piece of their title-bar in reach (mind the KSP UI itself!).

[damny]

I've uploaded build 4 here.

I want to stabilize SCANsat based on this build, so that I can move it to the showcase forum once all the bugs that are invariably going to pop up in build 4 are fixed. I haven't been able to implement everything I would want to have, and certainly not everything that has been brought up in this thread, but I think SCANsat is in an overall useable state now where small feature requests also shouldn't necessitate, say, save file structure changes anymore.

That said, this build does change the save format, so maybe it's a good idea to make a backup of your save game before switching. In theory it should be fine, but you know. Note that some changes will only become effective once you switch to your existing vessels for the first time.

The main changes in this build are related to sensor efficiency at different altitudes (making that configurable in the part file is what necessitated the save format change), as well as slightly better integration with career mode.

The most visible change to efficiency is that the high resolution altimetry sensor now only produces poor results at altitudes where the low resolution sensor still works. This slightly increases difficulty, but that's at least partially balanced by more accurate recording during time warp. I'm hoping that the configurable parameters are useful for people making their own parts; on that note, there's also an animationName property now that you can set to make the plugin try to play an extend/retract style animation when a sensor activates or deactivates.

As far as career mode goes, I have to say that the R&D system is a nightmare to work with if you want to do something other than just "push button, get science". I've tried to integrate it as much as possible, so that gathering science works in a similar way as doing experiments. However, all of the math is guesswork and it seems that implementing the right interface for a science container isn't enough to make recovery work either. So don't forget to put an antenna on your satellite so you can transmit results back. Since science is awarded based on completion, you don't need to report from the satellite that actually did the mapping; it just has to be something with the right parts in the right system. I'd be interested in bug reports about getting the wrong amount of size credited after transmission (before transmission is a different story, even certain stock experiments show the wrong numbers there...)

Full changelog:

Build 4 - 2013-11-10
--------------------

- Ground track should not fail anymore on certain escape trajectories.

- The SAR sensor has been replaced with a multispectral sensor, and the
  high resolution altimetry sensor has been replaced with a SAR sensor.
  (Naming change that doesn't affect gameplay.)

- All sensors had their minimum, maximum, and optimal altitudes as well
  as their fields of view adjusted slightly. These parameters are now
  configurable in the part.cfg files.

- A sensor's field of view degrades linearly below the optimal altitude, 
  and remains constant between optimal and maximum altitude. Parameters
  are scaled based on planet radius and SoI size, so you can still map
  Gilly.

- The sensor changes affect the save format. Existing saves should still
  work, but sensors will use a default set of parameters until the vessels
  they're on become active for the first time after the update.

- To balance the now greater need to set up a reasonable orbit for mapping,
  the temporal resolution of the scanning process is now adaptive and 
  will increase during time warp to reduce spottiness of the resulting
  tracks.

- Turning off sensors no longer closes the SCANsat UI, but the small map
  and vessel list as well as map overlays are only displayed when some 
  device on board can provide that information.

- If you run out of power, the minimap shows static and a lot less
  information is displayed in most windows. (OrtwinS)

- Flags on the big map have their own toggle button now. (Thourion)

- The minimap shows the area covered by the active sensors on your current
  vessel as a percentage.

- The "Forget Map" button has been relocated to a new settings window.
  A new button "Reset all data" is also available that resets all data
  for all celestials.

- The anomaly marker and the close widget character are now configurable
  in the new settings window. (drtedastro)

- Scanning can be restricted to the SoI your current vessel is in with the
  "Scan all active celestials" option in the new settings window. 

- Scanning can also be disabled for individual celestials. For your
  convenience, completion is shown as a percentage for each celestial.
  (Includes Altimetry, Biome, and Anomaly scans.)

- The temporal resolution of scanning while time warp is active can be
  configured in the new settings window. Higher resolution means more
  locations along a satellite's orbit are sampled. 

- Some sensors had experimental instrument readouts added that can be
  enabled via a button. Vessels equipped with a MapTraq device can also
  access some of this information if it has previously been recorded.
  The BTDT's instrument display reacts to the scroll wheel, although 
  that's only really relevant at the KSC...

- If a part has an animation set via the animationName property, the
  plugin will attempt to play it for activation and deactivation of the
  part. 

- Dragging the minimized main window doesn't maximize it anymore. (Thourion)

- If the main window is minimized or maximized close to the edge of the 
  screen, it will try to stay at that edge. (Thourion)

- A colour legend is available for height maps. (OrtwinS)

- Parts have been moved around in the tech tree a bit.

- Science data can now be collected from parts for applicable fields, based
  on how much terrain of the planet the vessel is currently in orbit around 
  has been covered. This science data must be transmitted using a suitable
  communications device like other science experiments; however, recovery is
  not possible at this time. (OrtinS, Draft, BananaDealer)

[Astral_Nomad]

OK stupid question what is BTDT? Secondly good work.

BTDT = Been There Done That. Its the name of one of the scanners.

[drtedastro]

Excellent.... Lots of great work Damny... I am looking forward to testing it immediately...

[skbernard]

this is the fastest, most competently created and iterated development cycles i've seen here in a while - i applaud your dedication and skill, good work damny

[Thourion]

...I got a Holy Mother Of Changelog [thourion's edit]... "but I haven't been able to implement everything I would want to have, and certainly not everything that has been brought up in this thread"...

..I cant even begin to imagine, what on Kerbin this update would have on, if the above went like you wanted. I mean it is already insane full of stuff.

EDIT: After a very quick run, i didnt see any problems. Really cool addition of the Legend in the map, and im not entirelly sure, but i think overall the plugin has even more smooth feel, gameplay wise, than build 3.

Edited November 10, 2013 by Thourion

[BananaDealer]

So is there any profit from higher orbits? I wanna set-up some geosync satellites...

Also Damny, can I take a look at that science generation code?

Edited November 10, 2013 by BananaDealer

[damny]

So is there any profit from higher orbits? I wanna set-up some geosync satellites...

Not that kind of benefit. Synchronous orbits aren't that great for mapping...

Also Damny, can I take a look at that science generation code?

It's all on github. And it probably looks messy because I tried about 500 different things.

[DMagic]

This looks very good. Performance is great all around, rendering seems faster, but maybe that's just me, and the issues with overlays are gone.

Scanning at different altitudes works well. I like how different scanners are have very different ideal orbits. I would suggest adding something about the effective orbital range of each part to their description though. You might not need to put the ideal altitude, but it would be nice to put something like "SAR functions from ~100km - ~750km." And the variable scan width works well too.

I don't know the specific color combinations that cause problems with some people, but since you have options for markers you might also want options for the color of text. Yellow with a black border works well most of the time, but it can get lost in the slope or altitude maps sometimes.

It's good to be able to keep the small S.C.A.N. Instruments window open without the small map, but a separate close button for this window would be nice too.

The BTDT window is cool, but a little wonky. It's probably my mouse, but sometimes it requires two scrolls to register and sometimes only one. It zooms the camera in and out too; maybe next/previous buttons on the window would help.

Those are all minor issues though, this works great.

[BananaDealer]

Not that kind of benefit. Synchronous orbits aren't that great for mapping...

It's all on github. And it probably looks messy because I tried about 500 different things.

I'll skim over it now... I'm trying to actually make the Data Storage module to work right now and at the same time learning C#... Fun times...

Also, half hour ascent with a SSTO, building the Cabana Corp. Facility...

[MOARdV]

Scanning at different altitudes works well. I like how different scanners are have very different ideal orbits. I would suggest adding something about the effective orbital range of each part to their description though. You might not need to put the ideal altitude, but it would be nice to put something like "SAR functions from ~100km - ~750km." And the variable scan width works well too.

I'll second this proposal: it'd be nice to look at the part description and get an idea of what range of orbits it operates at, instead of having to switch out of the game and read the config file.

[Thourion]

I'll second this proposal: it'd be nice to look at the part description and get an idea of what range of orbits it operates at, instead of having to switch out of the game and read the config file.

I agree with you, but since you can already go and read the cfg. files and the values, that mean you can also edit the desc yourself pretty easily, no?

[MOARdV]

I agree with you, but since you can already go and read the cfg. files and the values, that mean you can also edit the desc yourself pretty easily, no?

Of course. But I'm providing feedback to the mod maker for improving the usability of the mod for others. I suspect that not all players are comfortable poking around in config files.

[OrtwinS]

Oh damny, you did it again... Soooooo many features.

This plugin is already legendary, even though most players don't know it yet

Any particular reason why you merged the biome and anomaly sensor?

Tech-wise I think detecting structures/objects is quite a different thing than "oh, this 10x10 km region is different from the next".

Is the software side of the biome-anomaly detection still separate? Can I still get the seperate functionality by changing the 'sensortype=X' setting?

PS I had a look at the todo list on Github and I'm running out of ideas to add. Stress-testing and (attempted)-UI-breaking will now commence.

'Big Map' name suggestions (I noticed you didn't like the name ): 'Grand Map', 'Macro Map', 'Advanced Map', 'Overlay Map' (not entirely accurate), 'Display Map' or just 'the Map' (as opposed to the far less-advanced mini-map).

I vote for 'the Map', simple and effective.

[MOARdV]

'Big Map' name suggestions (I noticed you didn't like the name ): 'Grand Map', 'Macro Map', 'Advanced Map', 'Overlay Map' (not entirely accurate), 'Display Map' or just 'the Map' (as opposed to the far less-advanced mini-map).

I vote for 'the Map', simple and effective.

"Detailed Map"? It provides more details than the thumbnail map.

[skbernard]

Hi-res Map?

[sharpspoonful]

I Like Zoom Map

[johnsonwax]

Atlas - implies bigness

[damny]

I would suggest adding something about the effective orbital range of each part to their description though.

Good point. For some reason I managed to remember doing this for electrical charge, but not the other things you can set in the configuration file...

I don't know the specific color combinations that cause problems with some people, but since you have options for markers you might also want options for the color of text. Yellow with a black border works well most of the time, but it can get lost in the slope or altitude maps sometimes.

I'm putting it on my list, but I'm thinking it would almost have to be something you can switch on the fly as it's not that easy to find a color that can be seen well on a background that could have any color of the spectrum anywhere.

The BTDT window is cool, but a little wonky. It's probably my mouse, but sometimes it requires two scrolls to register and sometimes only one. It zooms the camera in and out too; maybe next/previous buttons on the window would help.

I can't seem to stop the camera from doing that. I can consume the event but it seems the camera doesn't care, perhaps it queries the scroll wheel independent of the event system.

However, only the KSC seems to be this detailed anyway (the information is based on which objects have distinct names for crash reports).

Any particular reason why you merged the biome and anomaly sensor?

I just couldn't come up with a good way to distinguish them. Also, both biomes and anomalies don't exist on every planet.

Tech-wise I think detecting structures/objects is quite a different thing than "oh, this 10x10 km region is different from the next".

Actually, no - sensors that can see terrain types can typically also see buildings. SAR is one example, differences in RADAR reflectivity make different terrain have different intensity on SAR images, but at the same time, buildings or vehicles have very obvious and telling RADAR shadows. SAR can also be used to image things that would be hidden to optical sensors, for example, lower frequency SAR can penetrate foliage or even the soil to some extent, so it could detect buildings that are partially hidden. That's why the biome/anomaly sensor was based on SAR in the first few builds.

I've changed it to a multispectral one now, an example of that would be Landsat. Obviously, manmade structures are visible on multiple levels here, but data from the infrared bands also correlates to things such as soil moisture or vegetation age more closely than visible band data. I think one of the more famous color schemes for Landsat images is the one where vegetation is red, and cities are blue. Those are shifted so that red maps to near infrared intensity, green maps to visible red, and blue maps to visible green. In these images, old vegetation appears dark red and young vegetation (e.g. crops) appears bright red. Real-life Landsat wouldn't be useful to find monoliths, but that's purely a resolution issue. And if we pretend that these anomalies emit some particular radiation unique to them, then it would be easy to have a multispectral sensor that also detects that separately.

Is the software side of the biome-anomaly detection still separate? Can I still get the seperate functionality by changing the 'sensortype=X' setting?

It should work, of course I haven't tried it since those have been one sensor from the first build.

Edited November 11, 2013 by damny

[Mmmmyum]

I have a bug, for some reason mine isn't scanning. I had a lower satellite that was taking too long, so I deorbited it (that's No. 1 on the map, a strut survived reentry heat and the impact), yet neither of my other 2 mapping satellites work. No 2 is at a perfect 1000x1000 orbit with a inclination of 90 degrees, and the other is at a perfect 3000x3000 at an inclination of 85 degree. This is all the info from the third one:

Mods used: FAR, Deadly Rentry, Planet Factory, KW Rocketry, B9 Aerospace, City Lights and Clouds, Kerb Town, Kerbin City, IonCross Life Support, Mechjeb, Kethane, and Procedural Fairings

The Satellite has the Multispectral Sensor, SAR, RADAR, and the MapTraq (which doesn't seem to be doing anything). It has more than enough electricity as well

Edited November 11, 2013 by Mmmmyum