DMagic

SCANsat has a relatively rudimentary slope map implementation (compares altitude from 2 neighboring pixels on a map to determine slope). It is very simple to generate if you already have altitude data, but not very useful on a full planet map, a neighboring pixel may be several kilometers away. But if used with some type of zoom map it becomes very useful. It also has a mouse-over tooltip with map information, I believe that uses a much more accurate (but prohibitively expensive for a full map) method for slope information.

Cool mod

I think the mod users are the best source of that information. Last I heard everything is working fine.

Yes, there are extensive map color customization options. The GitHub page has some documentation on this (the images may be a little out of date, but the overall process is accurate). https://github.com/S-C-A-N/SCANsat#top-12a-terrain-colors-and-options

Yeah, I'm not aware of any major issues. A few part loading errors or MM errors for deprecated parts doesn't really affect anything. I'm sure that there are some bugs and issues in here, but I think most of those are pre-existing and not due to KSP updates.

SCANsat takes its data directly from the PQS system (basically the same system used by anything that gives you terrain height data). Its terrain data is generated by querying KSP for terrain height at each pixel of the map. The same for biomes and resources. Everything comes directly out of what KSP's systems provide. Any properly configured planet pack should work fine (gas giants don't have terrain, and should show a static nosie terrain map, but they can have biomes). The only problems tend to arise from scanning altitude issues for planets that are significantly different in size from stock planets. Though, that doesn't seem to be an issue here.

The contracts in this mod don't use contract configurator, so you can't do much with that. Most of these contracts have some basic requirements that have to met before they generate, but those are generally pretty simple, like reach orbit once, or a few other basic signals of progress. And to have the relevant parts unlocked. There are extensive config files to modify most aspects of the DMOS contracts in the mod folder. Otherwise they should generate over time.

I seem to remember having various fixes lined up for US2 that hadn't been released. I think everything is up on the dev version folder of the repo. Assuming everything is still working there it should be fine to take over and fix this up for 1.12.

Tracking Station Evolved Version 7.0 is out; get it on Space Dock. This update fixes the hidden sorting buttons at the top of the vessel list, they were hidden underneath the new stock alarm UI element. It also fixes a bug related to changing the stock vessel type filters if all vessels should be hidden. I was not able to replicate any issues with vessels not being able to load, as mentioned above. Let me know if anyone else runs into this or any other new issues.

It's a problem with the way the BTDT works that has never been dealt with... The part needs a full overhaul in the way it works, but it's always been too much trouble. The only easy work around is to change the max altitude in the part config.

Probably some changes to how the vessel lists work in 1.12.2. This mod kind of pokes around in the stock tracking station functions, so changes to those might be breaking things here. I'll try to look into what's causing it.

The orange color readout on the bottom of the map indicates that you haven't scanned the Mun with the anomaly scanner at the position if the mouse cursor over the map. Keep in mind that the anomaly scanners require the surface to be in daylight during scanning. You can turn off this requirement in the settings menu if you don't want to deal with it.

If it needs updating I will do so, but I haven't seen any problems yet. Do you have some planet packs or planet rescale packs installed? It looks like the scan status indicators on the small map are solid orange, which generally indicates being too low or too high. The SCAN menu part of the right click menu should indicate what is going on.

Yes, that's the general pattern. The high resolution scanners mostly have lower fov than their lower resolution counterparts.

@linuxgurugamer I commented on Github about it. FOV is a bit convoluted, but basically the scanning map is a 360*180 array of the whole number lat/long coordinates for the surface. The FOV defines how many whole number degrees around the vessel that will be scanned. https://github.com/S-C-A-N/SCANsat/blob/release/SCANsat/SCANcontroller.cs#L2539-L2611

No they are saying this mod isn't supported anymore and won't work with newer versions of KAS. The Breaking Ground expansion provides a set of parts that are more or less the same as these (but without some of the hassle), so there isn't much of a point updating and supporting this mod.

CKAN questions go to the CKAN topic.

SCANsat version 20.4 is out; get it on Space Dock. This version prevents the overlay window from opening when it shouldn't.

The reappearing overlay window will need a hotfix. Should be out in a few days.

Version 20.3 is out; get it on Space Dock. This update fixes some issues with the big map data not being updated, drawing visual maps of the new gas giants, along with a few other bugs and issues related to resources, and some missing localization fields. It also includes some adjustments of part masses. It also includes new UI features related to resource overlays including small resource overlay color legends on the big map, zoom map, and planet overlay control window. The big map and overlay control window also feature quick tools to adjust the low concentration cutoff for resource overlays and a shortcut to the color settings for the current resource. There is a new resource setting option to hide resources in the UI ("Hide Unused Resources" in the Resource Settings tab of the Settings window) for planets that don't have any of that resource (this is not generally an issue with stock KSP resources). For instance, if there is a resource config that sets the Mun to have 0 Ore, then all of the resource selection menus will hide Ore for the Mun. This can keep the UI from getting cluttered with useless fields when using multiple resources. When this option is enabled the unused resources will always be hidden in the UI, regardless of whether you have scanned for resources on the planet. Since this could be considered a kind of cheat, you can disable this option. When disabled the unused resources will still be hidden, but only after scanning with either the low or high-resolution resource scanner to beyond the Scanning Threshold Level that can be set when stock resource scanning is disabled (you can disable stock resource scanning, change the threshold level, then re-enable stock resource scanning if you want to change this in the UI). There is also a new field in the settings file to disable visual maps. This could be useful for people having performance and crashing issues with SCANsat v20.x. If disabling visual maps solves the issue then it is a good sign that there are memory problems, as the visual map feature can consume a significant amount of memory. This field can be found in: GameData/SCANsat/PluginData/Settings.cfg. The file may not be present until you run KSP at least once with SCANsat installed. The field to change should be at the bottom of the list: VisibleMapsActive, set this to "VisibleMapsActive = False" to disable visual maps. There is no in-game method to change this setting.

Update for the map data issues should be out next week. Just had an endless series of minor issues that I've found with the new update that have delayed things. @omG?! The old part models won't be replaced. Any active vessels or craft files will still use the old models. The models and scanners are all new parts, most with significant difference in size and shape, so they can't really be a direct replacement. Regarding problems with RO and maybe other planet packs. I'm thinking this may be a memory issue related to the new visual maps. An option to disable them might at least be useful for troubleshooting purposes.

Slope is one of those tricky things that can get pretty complicated. It's highly localized and there are many different ways of calculating the value and reporting the value. SCANsat just asks KSP for the terrain height at a few points surrounding the center point, I think something like 5m distance. This is a little bit expensive to calculate, but not really significant in the scheme of things. (This is for the little instrument data window, the slope map is another matter, and is generally far less accurate). I think Engineer looks at the angle of the actual surface geometry relative to a flat surface. This requires that the terrain geometry (this could have changed at some point) is drawn, which means it will only work close to the surface. But it is fairly cheap to do and should give a precise value for a given point.

@Alex33212 I spent a long time trying to get this to work a few years ago. I remember discussing it with JPLRepo around the time ResearchBodies was updated with a similar feature. But for SCANsat I kept on running into two problems: Altering the visible maps like this required making lots of copies of the textures (of potentially several planets that could be in view at the same time) then altering them, which was memory intensive (maybe this isn't as important anymore). And a significant amount of the visible detail on a planet comes from the normal map. You can basically wipe out the main color map (shrink it something absurd, like 64*64 pixels) and with an untouched normal map some planets wouldn't look that much different. The problem is that normal maps don't do well with seams, so if you have a body that is partially scanned, then you have a partial normal map, with a big seam at the border of the scanned area, so it looked terrible. Maybe I'll look into it again when I finish with this update.

@RealKerbal3x Besides scanning characteristics (max scanning altitude, scanning fov) the two higher tech versions also scan for anomalies. Part mass is definitely something that can be adjusted. @MAFman It looks like the new Jool shader is quite a bit more complicated than the normal planet shaders. I can get pretty decent results with a simple fix: It's not as good as the real thing (Jool now has 5 8k * 4k textures making up its visible surface ), but not terrible either. The sun has a different set of problems, though I think it would be reasonable to assume that cameras meant to image a normal planet wouldn't be able to map the sun, so maybe I'll leave that alone. @Kepler452b It should work fine, I've tested in 1.8.1 while trying to track down the performance problems some people have seen in heavily modded installs of KSP (without any success in repeating those problems) and it seems to work fine. Also, lots of fixes and improvements are coming to the resource overlays in the next version: New resource overlay legends and quick adjustment tools (low right of the big map, and bottom of the overlay window), along with some changes to make handling installs with lots of resources a little easier.

@One eyed Smile @TaintedLion Does this problem happen with Kopernicus? I've seen something like it before, it is related to how Kopernicus unloads the height maps for bodies that aren't nearby. SCANsat forces it to load when a map is being drawn, but I think there are some cases where it doesn't always work right. Switching the map to another body, if one is available, will usually fix the problem. @RealKerbal3x Hi res scans always "overwrite" low res scans when the map is being drawn. The low res scanner still functions, though, for the purposes of science and contracts. You can see the low res scan progress in the new big map scanning coverage indicators.