DMagic

You should complain more vigorously in the MM thread. I opened up an issue on the MM GitHub page. MM isn't triggering this plugin, it's simply overwriting every .sfs file in the save folder when certain circumstances trigger it. The original files should all still exist in a newly created backup folder. Nevertheless this should not happen. If MM wants to overwrite the persistent.sfs file and generate a new backup file that's fine, but it should never overwrite every .sfs file in the save folder, including the quicksave.sfs file.

I updated this again, it should really be working with quick load plugins this time.

I updated this again. It should finally work better with different quick-load plugins. Previously it seemed to work with some but not others. It uses xEvilReeperx's KSPAddonImproved to allow it to start in multiple different scenes. It still only generates a backup once per game, but can be reset by going back to the main menu scene.

I updated this again. It now starts up after the Main Menu scene. Using xEvilReeperx's KSPAddonImproved, the plugin can start in any scene and should now overwrite any science parameter changes made by other mods. It is also possible to put the ScienceParams.cfg file anywhere in the GameData folder, though only one config file will be loaded.

You can edit the potatoroid part.cfg file to change the rescale factor and mass right? I think I've seen people do this before and get bigger asteroids. Can you make a second potatoroid part, just copy the first and change the name, and direct the spawning code to that part instead, or alternate between spawning with both parts.

Tried the second paragraph, or the third? Take a picture of the big map with the vessel in question active, the scanner on, and the 'orbit' overlay on and post that. If your equatorial crossings overlap or are tightly clustered then you will only scan the same strip of terrain over and over again. It's very easy, and very normal, to get into an orbit with this kind of resonance, that's why the equatorial crossing markers are there. Very little is generally required to change your orbit sufficiently to prevent this.

That should be possible, just store the new data in a separate field in the scenario module. Right now I'm taking the existing data (if there is any) and passing it through a one-time conversion from a byte array to an integer array, using only one byte for each integer value. After the first time loading SCANsat data the process is switched to a method that converts between byte and integer arrays using four bytes per integer (the compression program requires that the data be in a byte array). There's no reason why the existing data couldn't be left in place (and would never again be changed) while the new data is stored alongside it. There would still be a one-time conversion between the two methods on the first load, but this way would probably be much safer. I'll look into it.

I'm looking for some guinea pigs. I'll PM anyone interested with the link. In changing how the scanner type works some changes were necessary in how scanning data is stored and loaded from the persistent file. This requires a one-time conversion from the old method to the new method and I'm a little worried about releasing this too widely. I would like to get a few more people to test this out, ideally coming from v6 (or earlier), from v7, and starting out fresh. Any resource scanning that you have from earlier releases of v7 will be lost , but regular SCANsat data should be recovered. This release also implements Kethane resource scanning (Kethane and Ore, from Extraplanetary Launchpads, for now), so I would also like some feedback from users with and without Kethane installed. The package includes the updated SCANsat.dll file, the SCANsatKethane.dll (necessary for all Kethane scanning), the OpenResourceSystem_1_1_0.dll (which must be included somewhere in your GameData folder), and four Module Manager configs. These include scanners for the two default Kethane sensors, EPL's ore magnetometer, all three KSPI resource scanner modules, and the Modular Kolonization System scanners (ORS-type only, I'm not sure what the story on continued Kethane support for these resources is). The MM configs aren't necessary for displaying existing Kethane data on a SCANsat map, but they are necessary for all background scanning and for any kind of scanning with ORS resources. The Kethane grid doesn't update nicely after background scanning. You have to push the "Rebuild Kethane" button on the big map, then either save/load, cycle the grid on/off from the map view, or maybe just wait a while for the grid to update. Let me know if anyone runs into any bugs, especially as concerns recovering old scanning data and any problems when playing without Kethane installed.

Yeah, I just deleted the background color (and remade the SCAN icon), I can upload them later.

You mean like this: That's something I've been meaning to get around to. The KSP style button isn't perfect with the "SCAN" icon, but I think it's ok.

Yep, some of the experiments have a science reports written specifically for the default pack of the custom biomes mod, but they will work with any biome pack.

What is a geocentric orbit, aren't all Kerbin orbits geocentric? Geo-synchronous, or geo-stationary (which would be the world's worst mapping satellite)? The scanners have maximum altitudes, you can check them in the info tab for each part in the VAB.

On the topic of colors, I'm wondering if the overlay should always have a background shade to help differentiate resource areas from empty areas. I think this would be helpful, not only for color-blind support, but for making it easier to see what areas have and haven't been scanned. The ORS resources overlays currently don't do this; I think those need a better method for assigning a resource concentration cutoff first. Right now the cutoff is just the scaleFactor * scaleMultiplier and doesn't consider the display threshold value. I'm also thinking that the grey scale map should stick with one color/shade for all resources, and only the color map should use different colors. Using a grey background for empty areas would probably help in finding compatible colors for that map too.

You can try out v7, but it is primarily for testing, and the released version has a number of bugs, only some of which were fixed in the update described above.

I've reverted the changes I made to v7 for the Kethane side of things and fixed a number of bugs. It should initialize properly now, checking for the presence of any resources, and disabling the overlay if none are found. This will prevent the big map from freaking out if you don't have any ORS resources installed (it defaults to ORS resources, not Kethane). I've also fixed the problem I described above about switch from ORS to Kethane resources causing the same problem. I also fixed the screwed up map, the pixel color just needs to be re-initialized for each pixel, not each line. Most of these changes are separate from the problems I discussed about using different scanner types, so these things needed to be fixed anyway. This version still doesn't have any support for Kethane resources. TG: You can rebuild the v7-Resource-Overlay branch, leave out SCANsatKethane, like last time. It doesn't have any of the color palette changes, I just updated directly from the released version of the code. Changelog: - Big map should no longer break if no ORS resources are installed - Switching from a high-number ORS resource to Kethane should not break the big map - Incomplete big map should render properly - Spottiness of resource scanners may be improved, it's hard to say, maybe ok up to 100-1000X timewarp - Setting menu buttons don't change color anymore

I'll get on tonight. I've found a way to load up and convert the byte array stored in previous versions to a usable integer array (I think something like this was done in a previous SCANsat update), it's pretty simple, but it may need to be some kind of one-time thing. SCANsat can store the required information for this in its scenario module, but I'll need to find a way to handle new vs old saves.

This is what I was thinking. This would get around any issues of dealing with two coverage maps, and I think 32 sensor types is more than enough. I've been working on converting an Int32 array into a byte array that the compression algorithm can handle, I seem to have dealt with that, I just need to handle the reverse now. It's possible that it may affect existing data, I can imagine that in converting from a byte array to an integer array it might get confused about which values go where (ie the first four bytes get added to the first element of the array, instead of getting added to four consecutive elements). Using a second 2 or 4 byte array might better option for preserving existing data.

I've seen versions of this too. I don't think it has anything to do with the toolbar or any other mod, it's just SCANsat's GUI screwing with others (in a similar way that other mods can reset the GUI to the KSP style buttons rather than the Unity style). And gui_show is the all-purpose GUI handler for SCANsat, it's where everything seems to get collected before being sent off to the rendering manager. Are the people who are seeing this using both Kethane and ORS resources? Does it happen right away when opening the big map, or only after changing things in the settings menu? The one sure way that I know of to cause it (at least when I tried it) is to select "Open Resources" button, then select one of the last resources on the list, say Alumina, then change to the "Kethane Resources" button. Because Kethane only has one or two options something is getting confused and thinking that the third option is selected when it doesn't actually exist (presumably the same would happen in the reverse, but there are generally more ORS resources than Kethane resources). If you don't have Kethane resources installed then you'll notice that selecting the "Kethane Resources" button just shuts everything off, the toggle button above it disappears along with the overlay buttons on the big map. Doing something similar should be fairly simple when you have both resource types installed, probably just resetting the selection to the first resource option when changing types. And these UI elements are all temporary, I'm certain there are better ways of handling which resource you want to display. But if people are seeing this happen in other cases something else may be going on. I'd be interested to know if everyone else is seeing the same error in the debug log, that "system.collections.generic.list" line at the top may be the important part, the list in question being the list of available resources to display and the integer being which member of the list is selected. Did the map distortion weirdness persist through re-sizing it? I noticed that once, but just changed the size, and since I was checking something else didn't pay much attention to it. It's also possible that I didn't copy something right into that branch. You might want to try the v7 branch and see if the same thing happens, it doesn't include any of the color changes, but has all of my other updates.

Well fudge. This method of using a non-bitmask for the resource scanner type won't work. When the system registers a scan it looks at a position on the planet and the scanner type. It says at Long X and Lat Y the scanner type 2 (hi res altimetry) has scanned this area. So the array gets set to: [x,y] = 0000 0010. Now when scanner type 8 (biome) comes along to the same position the array gets set to: [x,y] = 0000 1010. So when we want to check if a position has been scanned we take our scanner type and check if it matches the array, position [x,y] = 0000 1010 so both the biome and hi res altimetry bits have been set, but the low res altimetry (type 1, 0000 0001) hasn't been set. When we use a non-bitmask enumeration to set the array this all breaks down. When resource sensor type 21 (uranium) passes over long x and lat y the array gets set to: [x,y] = 0001 0101. Now let's say we want to check if resource scanner type 1 (Kethane) has passed over this same location; we look at the array: [x,y] = 0001 0101 and see that the Kethane byte: 0000 0001 has been set, so we can say that the Kethane scanner has also scanned this area. This is obviously a problem. With the regular SCANsat sensors every sensor is assigned its own bit in a single byte. So we can unambiguously determine which sensor has passed over which location. With the resource sensors that doesn't work, each sensor is assigned more than one bit and so we can no longer determine exactly what has been recorded. I can try setting the standard coverage map to be a short or an integer array, that would give us 16 or 32 bits (meaning 16 or 32 different scanner types). For now there are five SCANsat sensors, two Kethane resources and eight ORS resources. So I'm thinking that a short would not be very wise. I'm not sure how much using an integer array will blow up the data stored in the persistent file. But I'm already storing two coverage maps, so maybe this won't be so bad. Hopefully the fact that many of the potential bits remain unused will keep the size of the string stored in the persistent file to a reasonable size (you can easily see the difference between the string for an unscanned vs. a scanned planet already). Of course, this could also simplify some things. I think doing it this way should get around some of the weirdness I've been seeing when trying to use a separate scanner type.

My telescope does generate different reports from each biome. The version using the SCANsat module is no different, it just has the additional ability to make another science report using SCANsat's methods. SCANsat doesn't allow for different reports from each biome because that wouldn't make much sense. The total amount of science you get is based on how much of the planet you have scanned with each scanner type, where you trigger the "analyze" button makes no difference. I actually should remove those options from the ScienceDefs file, both the situation mask and the biome mask should be 0. I believe that a dedicated anomaly scanner also won't generate any science. It's only the two altimetry scanners and the biome part of the multispectral scanner.

I integrated my changes with yours. I think I got everything in right, though I had to rely on VS to catch some errors. The dev branch has the color palette updated version, the v7 branch has the non-color palatte version. Neither is ready for distribution.

Yeah, the end result would seem to be about the same. The offset scanning coverage would be slightly different, though it would probably just confuse the majority of users and would only be noticeable if you actually watch it scan. And also, scanning under high time warp relies on the high FOV creating a box around the vessel position to fill in the map without gaps. If we switched to a much narrower scan in one dimension it would complicate that. The only two reasons I've seen given are the electricity use and the technical complications of determining which Kethane cell is being scanned from an inactive vessel (high timewarp is a big factor here too). SCANsat ignores electricity for inactive vessels, and I'm not aware of anyone who know how to accurately do this with reasonably performance anyway, calculating solar panel electricity for an inactive vessel doesn't sound simple. Electricity is a problem even for active vessels at very high timewarps because of the errors in calculations of power usage vs power generation, SCANsat just ignores it at over 1000x timewarp. As for the technical complications, I think that's only a problem if you are trying to plot which cells fall under the vessel's orbit at any given time. If you just ignore all of that and only record which positions the vessel flies over (in lat/long) you can rely on the wide FOV to fill in any gaps and worry about Kethane cells later.

This is still far from being ready, but my new method seems to be working, or at least sort-of working. This uses a separate assembly to interface with Kethane. It mostly just watches for changes made to the SCANsat UI (ie pushing buttons on the screen) and sends data to SCANsat when needed. I'm getting around the performance hangups by intentionally slowing down some methods. It takes about nine seconds to read out data from Kethane's database and send it to SCANsat, which should only be necessary when loading or switch to a new planet. The process is slow enough that it doesn't seem to affect KSP. When the big map is rebuilt it is only necessary to update the resource values for each cell, which seems to be quicker, so I just run that at the same time the map rebuilds. This might cause problems if the map builds too quickly though, this all needs much more testing and tweaking. There is still some mismatch between what SCANsat is recording and what the Kethane grid is displaying, I think it has something to do with the offset values being used for long/lat. And I'm still not sure why the SCANsat side of things is giving spotty results, rather than the continuous bands that the regular SCANsat scanners produce. The results look basically the same as the old versions. You can see some of the mismatch here.

There are a few things to keep in mind: ORS scanners have no recording function, they only display the resources below your current position and display the little texture icons on a portion of the planet. To have any integration with SCANsat additional part modules are required. I'm using slightly different versions of the SCANsat module (with the resourceType field), which clutters up the persistent file a little bit more, but doesn't require any changes to the regular SCANsat scanners. It's surely possible to accomplish ORS scanning and background scanning some other way, but it seems best to build on the method we already have. For Kethane it is possible to use only the existing Kethane detectors and only pull information out of the Kethane database for generating the SCANsat overlay. The biggest problem with this is that it is very slow. Converting from position in latitude/longitude (which is how the maps are generated) to Kethane cells is slow, and when you need to do it tens of thousands to several million times per map reset it can really bog things down. The best solution seems to be adding our own part modules to the Kethane detectors and handling everything on the SCANsat side. There are still a few problems, one is that we need to pull the amount of resources in each deposit out of the Kethane database, and that we need to be able to update the SCANsat database with already existing Kethane scans (and to do the reverse for background scanning). The ORS method for checking how many resources each point on the map has is very quick, but the Kethane method is still somewhat slow (it requires at least some amount of converting positions to Kethane cells). There might be a way of simplifying this. Kethane is found in a small number of deposits on each planet, each with a fixed amount of resources, so it seems like there should be some way of getting around the Kethane cell problem and just directly reading out the amount of resources remaining in each deposit. As of yet I have no idea how to do that though.

Yes, the static types are very different. The small map static is constantly alternating between static and the regular display, that's why the map is still somewhat visible. The nothing-to-see static just generates pixels with a random shade of grey. From what I can tell it looks like an empty biome map is also supposed to return 0 science, but because the biome system doesn't quite work how damny was thinking it does, this isn't the case. Allowing both cases to return science, as they probably should, seems easy enough to do.