DMagic

Overlays are only one-at-a-time for now. For ORS resources it might be possible to add more than one (though it seems like it would have to be limited to some degree), but I'm afraid things will just end up looking muddled. It's doubtful that a reasonable method for viewing multiple Kethane resources, or viewing both types together, will be added. Kethane has much more significant performance issues to deal with and the big map is already slow enough. Color-blind support is an issue in several areas. I'm thinking it might be best to find some suitable color/shade to use for the greyscale map and use that for all resource types (assuming that only one type is displayed at a time).

These kind: http://forum.kerbalspaceprogram.com/threads/80661-0-23-5-DEV-SCANsat-v-7-0-Real-Scanning-Real-Science-at-Warp-Speed%21 SCANsat maps use those colors heavily. The slope map is almost entirely yellow, and the biome map is varying shades of green. The altimetry map is somewhat of a lost cause for picking ideal colors. Depending on the planet pretty much any color can be present, so using the grey scale map works better there. But for Kerbin at least (and other planets with similar surface heights) the colors skew to the blue, green and yellow side.

Here's my list of ORS planetary resources so far: ORS_1 Uranium - KSPI ORS_2 Thorium - KSPI ORS_3 Alumina - KSPI ORS_4 Water - MKS ORS_5 Ore - MKS ORS_6 Minerals - MKS ORS_7 Substrate - MKS ORS_8 Reserved - Unreleased At some point down the line I think I can add support for more resources in SCANsat using a config file, but for now each type is hard coded. Did I miss any? It's only planetary have the map right, so the KSPI version of water isn't needed here? I'd also like to know if it's possible to include some kind of color definition in the resource file. Kethane resources define their color that way, so it's easy to assign each resource its proper color. ORS has no such system, so we're stuck with either the default pink (which shows up pretty well on SCANsat maps) or me hand-selecting alternate colors. If anyone wants a specific color keep in mind that greens, yellows and reds aren't going to show up well overlayed on top of a SCANsat map.

When you say the R&D center is closed do you mean you can't open it from the spacecenter screen? Or that when you collect science data you get the generic, sandbox science results? Or both? Do you see any errors in the debug menu (alt+F2)? Can you send the ksp.log file (in the main KSP directory)?

Your scanner doesn't have the SCANsat modules attached to it (or at least they aren't loading properly). See the posts above about adding it manually or using a MM config.

If anyone is wondering, the resourceType field in the new SCANsat part modules is not needed for older parts. It defaults to 0 and is only used for resource scanners.

If you want to add support for the Interstellar planetary resources you need to add these modules to the Gamma Ray Spectrometer part.cfg file. MODULE { name = SCANsat sensorType = 64 resourceType = 21 fov = 10 min_alt = 5000 max_alt = 500000 best_alt = 100000 scanName = Uranium Scan power = 0.4 } MODULE { name = SCANsat sensorType = 64 resourceType = 22 fov = 10 min_alt = 5000 max_alt = 500000 best_alt = 100000 scanName = Thorium Scan power = 0.4 } MODULE { name = SCANsat sensorType = 64 resourceType = 23 fov = 10 min_alt = 5000 max_alt = 500000 best_alt = 100000 scanName = Alumina Scan power = 0.4 } If someone wants to make a Module Manager config file for that it would be great. I don't have much experience with MM configs, so I don't want to do it myself. And once again, use all of this at your own risk...

It should be noted that this version is only intended for testing right now. Everything is mostly stable, but there have been some changes to the way data is stored in the persistent file and upgrading from an old version, or downgrading from this version to v6 may cause problems. Only use this on a new save file or a file that you've backed up. Also, there are a few things to keep in mind about the resource overlays. Most importantly, Kethane resources are not currently supported. The options are all there in the UI, and selecting them should not hurt anything, but none of them work. The earlier images were all proof-of-concept demonstrations. The release version will need have a workaround for the dependency issue (which I'm working on now) as well as some way of getting around the performance issues. The Open Resources System (ORS) support is mostly working. There are some issues with the scanners having spotty coverage (which goes away once you get a complete, or near-complete map) and they all use a generic pink color, but otherwise they work fine and there is essentially no performance impact for turning the overlay on and off. The primary issue with ORS scanners is that the parts themselves need to have custom SCANsat modules attached to them. I've been doing it manually, but a MM config would be best. I'll try to release some guidelines at least for how to properly create the part modules. The default Interstellar scanner has all three scanner modules on it, so adding three more SCANsat modules is going to make things very clunky, but that's really an Interstellar issue.

Don't delete anything. There are threads on how to convert a sandbox save to a career save (I think). Check them to see if there is something in your persistent file that can be changed to fix it. I'm not sure how SCANsat could cause this problem by itself though.

An empty biome map also generates static.

Nope. Unfortunately the sun is a little wonky. According to its celestial body data it does not have an atmosphere, however it does have a max atmosphere height. Despite this contradiction the science system treats the sun as if it has no atmosphere, so no atmospheric data can be collected there. To change the altitude for the transition from inspacelow to inspacehigh you need to change the "spacealtitude" value, not the data value.

It will work with both the next versions of my mod and DMModuleScienceAnimateGeneric (which I hope to update in the next day or so). Presumably Squad left those values out for a reason, but you never know if they'll use them, or remove them all together. MM should work, though I'm not sure if there's any reason to use a MM cfg rather than just changing the default config file. You can always delete the config and restart (the program, not a new save) if you want to go back to stock values. I might actually change the node names to something less generic so that there is less chance of some mixup.

The operational altitudes for all scanners are visible in-game in the "right-click for more info" window in the VAB/SPH.

The small and large maps live in two different worlds. Adding biome maps (and slope maps) would technically be possible for the small map, but I'm not sure how useful they would be. The borders used on the biome map don't come out well at such a small scale. You can shrink the big map down to almost the size of the small map (400 pixels wide vs. 360 pixels for the small map), and already it's clear that the biomes just get crushed into a bunch of white borders.

For stock part? It would be difficult. But I could (and now have) implemented this for my parts. It's a simple fix to return the proper value instead of relying on what the regular methods return. The only problem I can see is that it might interfere with the diminishing returns for repeated experiments.

There's no need to use additional uv maps or textures to get a specular map. You can use the alpha channel of your diffuse to texture to set the specular map.

One thing I can suggest is to make sure your maps match up on their left and right sides. It looks a bit goofy, especially in a polar projection, when there is a sudden dividing line where the resource distribution abruptly changes.

I don't suppose anyone has a master list somewhere with all of the resources that use ORS. I'm looking for planetary resources specifically, but anything would do. I need to explicitly add support for each resource type in order for it to work with SCANsat and to avoid any mix up between different resources. All I have so far are the four KSPI resources. The same goes for Kethane resources if anyone should have a list of those.

If you want to build RPM and SCANsatRPM yourself you'll need to download the source for SCANsatRPM v6 and use that in place of the code from Mihara. As far as I know the only change is to that one line (which should read "map.resetMap(mapMode, 1)"), but I can't guarantee that. When I download the latest official release of RPM and replace the included SCANsatRPM folder with that included in SCANsat v6 it works fine (MJ is not installed, but MechjebRPM is and gets loaded fine). If you're using one of the MechJeb dev versions that may not be the case, but it should work with the official release. Edit: Too slow:(

That's fine. I have barely been working on this mod, and primarily on back-end stuff. And by module I meant animation module, not the wedge. I'm sure I'll want to use the mesh itself.

I might borrow this one and see if I can come up with something more SCANsat specific.

I released a minor update (currently only available from the mediafire link). It is a little more fault tolerant when trying to add your own config files. The debug log will tell you which planets loaded correctly and which, if any, did not load (the failed planets are listed by their body_index value only). I also included an alternate config file with the default pack for Krag's Planet Factory created by Rokker. Simply replace the standard file, or copy and past the added Body {} entries yourself.

This is essentially what Interstellar does with its resource maps. MeCripp is right that you don't want to be adding a bunch of high resolution, 4k * 2k texture files, but if you stick to very small sizes it shouldn't have a huge effect. In the interest of not clogging this thread up with speculation and half finished features I'll only say that yes, such a thing can be incorporated into SCANsat and displayed on the map. And also, that the SCANsat imgur account is publicly viewable and anyone can see what has been uploaded there. When we have a WIP thread up I'll discuss more.

There have been no changes to the actual scanning mechanics (except for the bug fix where the scanner mixed up the south and north poles). Small changes in orbit can significantly alter the effectiveness of scanning. Make sure the equatorial markers shown on the 'orbit' overlay don't cluster together into a few groups. A very small burn is usually enough to break up these groups and improved the effectiveness of your orbit. And if you're altering your inclination every orbit you're doing something wrong. Many dozens of orbits are required to get a complete map. Find an orbit with a good spread of equatorial crossings and wait. Fixed, thanks.

Alternative SCANsat scanner parts should work fine, including the all-type scanners with sensorType = 255 field. The scanName field isn't strictly necessary, but it should be included. Without it the right-click and action group names won't be properly initialized and there is a slight chance that anyone upgrading from an existing install may not be able to analyze science data from that part. That said, just copy the scanName field from an existing part or make up your own, anything will do.