DMagic

@Sigma88 The default min and max values are the fallbacks for planets that don't have a node in that file. SCANsat attempts to figure out the actual values whenever a new planet is encountered, so they should never actually be used. The range above and below values are used to set the min and max extent for the terrain height sliders in the SCANsat color management window. So if a planet's max height is 8000m and the range above max is 10000, then the slider will go up to a max of 18000m. You can change these values with MM if you want (though it's less of a problem now that SCANsat generally has reasonable values for any new planets), just don't use multipliers; if you want to increase the range just set it to 20000 instead of 10000, or something along those lines.

@Sigma88 Those are the existing values, they define the default min and max terrain heights for each planet (and if you want to set the "clamp" height, like for ocean planets), which SCANsat uses when assigning colors to different terrain heights. The multipliers are used to adjust those values (and the values stored in each save file) when drawing the maps. So if you want to scale the max terrain height by 2 for each planet, just set the maxHeightMultiplier = 2 in a MM config. Don't do anything to the min and maxHeightRange values. When someone saves the SCANcolors.cfg using the in-game function it always sets those values to 1, so that the MM config doesn't get carried over each time the file is saved (internally the multipliers set by the MM config is preserved when saving the SCANcolors file). Existing save files will probably be a bit screwed up, but they can be reset in-game pretty easily.

Version 1.3.1 is out; get it on Space Dock. It includes a new KSPedia entry with information on the requirements and conditions for each experiment, asteroid experiments, non-standard instruments, contracts, and some information about use with other mods. It also fixes a bug with the asteroid scanner, adds an indicator for which experiments can be used with asteroids in the VAB/SPH info window, and removes some... potentially offensive and/or rule breaking science results. * Some of the panels are not quite up-to-date with the release version.

SCANsat 16.2 is out; get it on Space Dock. It is updated for KSP 1.1.3. It contains a few minor GUI performance optimizations, clarifications on scanning status, new terrain color palettes, and some minor changes and additions to the KSPedia entry. A new silent science collection function has been added that will prevent the results window from opening: for KOS support (@erendrake or @hvacengi) see the source here. For planet rescaling mods, such as Sigma Dimensions, some new terrain height multiplier values have been added to the SCANcolors.cfg file. Each planet now has three multipliers: SCAN_Color_Config { SCANsat_Altimetry { Item { name = Kerbin index = 1 minHeightRange = -1500 maxHeightRange = 6500 clampHeight = 0 ----> maxHeightMultiplier = 1 ----> minHeightMultiplier = 1 ----> clampHeightMultiplier = 1 paletteName = Default paletteSize = 7 paletteReverse = False paletteDiscrete = False } } } @Sigma88 Module Manager configs should reference these values (probably the maxHeightMultiplier is the only one that will need to be changed) instead of the min and max height range values. This will prevent errors when saving these values from in-game (the values have also been clamped so that extreme min and max terrain heights won't break the SCANsat maps). Existing configs and save files may need to be reset to their default values for each planet. This can be done in-game using the Color Management Window and selecting the default values button for on the terrain tab. Support has also been added for Planetary-only resource configs (stock resource configs that don't include a Global Resource node; ie Karborundum) if you want to manually add in SCANsat sensor support for any such resources. Biome-only configs remain incompatible with SCANsat resource maps.

Capcom version 2.3 is out; get it on Space Dock. It is updated for KSP 1.1.3 and fixes an issue caused by non-default date time formatters (RSS Date Time Format). It also moves the Settings.cfg file to a PluginData folder, this will fix an issue that caused the Module Manager cache to reset. CKAN will take a little while to update the meta data for its dependencies (without these updates the date time fix above won't apply).

Version 6.4 is out; get it on Space Dock. It is updated for KSP 1.1.3 and fixes an issue caused by non-default date time formatters (RSS Date Time Format). CKAN will take a little while to update the meta data for its dependencies (without these updates the fix above won't apply).

@Adam.A It sounds like you left a planetary overlay map on, just turn it off. @the Monkeys Uncle Are you using an old version of Toolbar? That has caused similar problems in the past. @basila That sounds like a Kopernicus problem. Maybe a screwed up config or a missing height map. @Apurva Kawthalkar Click on the target select button then click somewhere in the map window, but outside of the map itself.

It's fixed on my end, I'm just waiting on 1.1.3 to update.

@Jansn67 I'm sure that it's possible in one way or another, though I suspect it's more complicated than config files or deleting KSPedia entries. In any event, it's not something that would be covered in this thread. @jandcando I added links to the second version of your planetary wiki.

@einstein72 Nope. @Apurva Kawthalkar Right click on the magnetometer when it's deployed, it will show the magnetic field read-out, though you're better off using something like SCANsat to find anomaly locations.

The powder X-Ray diffractometer in my set is used to study the exact mineral composition of surface samples. I'm not really sure what an X-Ray Mass Spectrometer, mentioned by @Jeb1969, is. An Alpha particle X-ray spectrometer is used to study surface composition also, though the method is completely different, and doesn't really have anything to do with measuring mass. It is more in line with Curiosity's ChemCam, in that it provides an estimate of elemental composition (the sample is 20% O2, 15% Fe, 50% SiO2, etc...), not the identity of the actual mineral makeup of the sample. There are APXS instruments on most of the Mars landers, but Curiosity is first time an X-ray diffractometer has been used on Mars. I also don't know what a Microwave mass spectrometer is, but there are many different types of microwave instruments. There are the microwave radiation observatories that map out the microwave background of the universe, there are microwave limb sounders that are used to study the composition and properties of the upper layers of the atmosphere, there are soil moisture sensors that are sort-of like a radar that measures the water content in the very top layers of the surface, there are surveillance satellites that catch stray microwaves used by line-of-sight microwave transmission towers, and probably many, many more.

Launch set for Sat at 1:58 EDT. I guess we'll have to satisfy ourselves with this morning's Proton launch.

Launch set for 5:58 EDT (21:58 UTC) now.

That will only work until the cache needs to be rebuilt. You'll need to find whatever config file is changing things to solve the problem. The log files give a list of every MM config and what it is being applied to, just search for SCANsat and you should see them somewhere during the loading process.

Yes, but it's not the cache that you have to worry about, it's the config file.

@Carrot I need to see log files and or a save file to help. You might want to check the settings window to see if background scanning has been disabled. @schedar Sounds like a Module Manager config changing things around somewhere. Search your GameData folder.

A Delta IV Heavy is scheduled for liftoff today carrying a classified NRO payload: NROL-37. Launch is scheduled for 1:59 PM EDT (17:59 UTC). The ULA broadcast is set to begin at 1:39PM: http://www.ulalaunch.com/webcast.aspx Launch set for this Saturday now, at 1:51 PM EDT (17:51 UTC). Any ideas on what the payload is? Wikipedia lists the mission as Orion-9, so I'm guessing a signals intelligence satellite. The last NRO launch carried what was supposedly the last KH-11 spy camera, so I'm not sure what else would require such a big rocket.

The next release of SCANsat will have a science gather method similar to what I added for Orbital Science, it will allow for science collection without opening the results window. It will require explicit support from KOS, but at least the option will be there. https://github.com/DMagic1/SCANsat/commit/ce2be8fc375ba12d59c06efa6bd12b39d3328f16

@ZooNamedGames Reloading the database does not reload mods, it just reloads config files, parts and textures (well, it does sort of reload assemblies, but the actual .dll file is in use, and can't be altered). @Alshain So all mod developers don't support CKAN, or just a few? How many are required to support it before it becomes valuable? Given the amount of downloads that come from CKAN (it's obvious to track the difference between an update that is reflected in CKAN's database and one that isn't) I would say that plenty of people find it extremely useful.

The rescue contracts save a "partID" field, that might be the flight id of the part itself, but I don't think there is anything specific about the vessel. So I guess you could watch the onNewVesselCreated event and check for that id, but the only way to actually get that id is to manually parse the save file (HighLogic.CurrentGame.config), which can be a bit of a pain.

@JewelShisen Post log files.

I think Kernel Maps has that info. You could also use SCANsat to export CSV files with the terrain data and find the min and max.

Can people start posting released KSPedia entries on the other KSPedia thread, it would be helpful: I've already added links to all of the entries in this thread. It will be easier to keep things organized there, and easier for people to find the links, since I don't want to add anything to the first post of this thread that isn't related to the tutorial itself.

The number of biomes is probably good, though I'm not sure how you want to handle fake biomes like the Duna craters, or the repeat biomes like on Tylo. I would think that the actual biome names might not be a good idea, a lot of people might not want that information right away. High and low points of the terrain might also be interesting. Also, some advice about the layout, try putting some padding between the borders of the pages and the content. Text and images that run right up against the edge look a bit funny, and the blue grid background emphasizes this even more.

@Sigma88 & @`Orum The current method for handling this is not very good. I'm planning on adding a dedicated multiplier value for the terrain ranges (multipliers for each value and each planet). This will be multiplied by the values in the config file and the save file (the actual values used in-game are stored in the save file, the config file is used for default values and new saves), and for dividing when saving new values. I expect the next SCANsat update will be released shortly after 1.1.3. The scanning part altitude values should work fine with MM configs, those can just be multiplied by whatever value you want; these are completely independent of the color config values. The only caveat is that the VAB/SPH info tab is generated before MM runs, so the values shown there won't be accurate.