DMagic

The fix for resetting the map when changing Celestial Bodies is simple enough and seems to be working. Fixing the way that high resolution data overwrites low resolution data is much thornier. I'm not sure that I'll be able to come up with a reasonable method for doing so. But I think it's not a major problem; I don't think it's common to make a full low res scan, then do a high res scan and watch it the whole time. If you change celestial bodies it will go away and if you resize the map it will go away. It's also not very noticeable, you have to make the map fairly big or look very carefully. It can probably just be listed as a known issue. Your SCANsat.cs code worked fine for me, the events are disabled where they should be and the power thing doesn't cause problems anymore. I couldn't get the big map to break in the way you're describing. No amount of button pushes, while rebuilding, or while running out of power, and while closing and opening the map broke anything. I don't know why it includes all of those commits, they are just me re-syncing my fork to your master copy, so they don't change anything on your end, but it seems to want to include them anyway. Edit: Also, I'm not sure that any kind of caching is feasible for RPM. Since most of the maps are centered on your location, rather than showing the entire surface, they are constantly changing and caching values for each pixel wouldn't do any good. I still don't have any idea how it is setting the map size, but it seems to be consistent. It's 640 * 640 for the regular 1-man command pod, and the ALCOR lander has two different sizes one is something around 700 * 800 and the other is ~950 * 1050 (which makes no sense for the full surface map, because it should be much wider than it is tall. The best way to speed up map rendering would be to shrink those maps a bit. Those sizes are really big and unless you zoom all the way in during IVA aren't necessary. Shrinking them might help speed things up a bit, but I don't know how to do that.

Mods already come in their own folders inside of GameData. You don't just drop the MechJeb.dll into GameData, it goes into GameData/MechJeb/MechJeb.dll. I don't see how adding another layer of folders is going to help that. And there are legitimate reasons why some mods must put multiple folders into the GameData folder, usually these are explained in the relevant forum posts and/or readme files. Exactly what "core game files" are you overwriting anyway? Like everyone else has said, pretty much anything that modifies stock files does so through Module Manager. If that's not the case then you should complain to the mod maker, but I'm only aware of a handful of mods that actually instruct you to overwrite stock files.

Is there a simpler method for getting to an editable version of a class file from the Assembly-CSharp.dll? Go to definition (F12) always takes me to the locked, metadata-as-source window with the source code. I can get at it by right clicking on the tab, selecting 'open containing folder', then opening the .cs file in another VS window. I guess it's simple enough, but if anyone was wondering how to get at the .cs file it might not be obvious.

I have a solution for resetting the map cache when switching Celestial bodies. It's very simple, but I think I should hold off on any changes to the big map for a while. I would like to also find a way to prevent the high resolution altimeter from simply re-coloring the low resolution data, but that might be much more difficult (and also not a very big deal).

I think a 64 bit OS would help to some extent with RAM, I'm not really sure on how this works, or whether or not KSP is large-address-aware on a 32 bit OS. Increased RAM wouldn't really help all that much with performance though, just the ability to use more mods without crashing. The biggest boost to performance would be upgrading that CPU. Those older Core 2 Duos really lag behind newer Intel CPUs, even moderately powerful AMD CPUs do fairly well. Of course any significant upgrade would require a new motherboard, and probably new RAM, which becomes a much more expensive proposition. And thanks for the results Nedal, I'll update the front page soon.

Not necessary to cheat or remain on the same vessel. Just switch to vessel around another planet and this will happen. I'll see about adding a check for the celestial body at the beginning of getpartialmap. Edit: I didn't have any problems turning options on and off while the big map was rendering, I'll look into it more.

Those attachment node fixes probably aren't very important. The models aren't any good anyway, so it doesn't really matter if they sink in or float a little (also note that some of the stock parts have bad colliders, which make many parts float above their surface). For the BTDT and MapTraq the analyze data action group is available to be set to a hot key while in the VAB. The fix for that is simple, though not very important. I tested the fix for the no power bug a little more. It seems to be working, you can start and stop scanning with no power, the animation plays and the part behaves properly after power is restored. Maybe changing this so that you can only enable or disable scanning on EVA while there is no power would be a better idea. But for now it works. I'm not sure why the ground track would be affected by any changes in v6, but I can see how the map update may be a little slower. I think there is some room to improve this in general beyond caching the IVA map. But that too can wait. It seems that the map is always set at 640 * 640 pixels, at least the square map is. Do you need the ALCOR capsule to get that rectangular version of the map? Or am I missing something in the regular 1-man command pod? Either way, the map is pretty small, a cache should only take up a 1 or 2 MB of space. But I would like to figure out how it sets the screen size before I do anything to that, and more changes will be needed to make caching actually work.

I see what you mean now. That's how it's always been. Adding the powerIsProblem line will fix the problem with the retracted-but-active scanner. The old version simply didn't allow you to retract the scanner while you didn't have power. I suppose doing it that way is another option, but personally I think it's annoying when you can't turn something like that off when you are out of power. After all, you can extend solar panels without power, so you should probably be able to turn off the scanner without power too.

I don't believe the big map was ever affected by power. I'm not sure that it should be, it would really just be annoying. I fixed the problem, I just added the powerIsProblem line: [KSPEvent(guiActive = true, guiName = "Stop RADAR Scan", active = true)] public void stopScan () { unregisterScanner (); powerIsProblem = false; animate (-1); } My copy (or copies to be accurate) of the code are a total jumble right now, so I can't push it to Github. But I can make the other fixes to remove the analyze data buttons tomorrow and include everything together.

I see it, I think I know why it's happening, it might be an underlying bug. I'm checking version 5 now. I also rechecked the big map in Minmus orbit. The ground track and current vessel icon worked fine on the big map. Edit: V5 works fine. I see the problem, it's because of this loop thing that it goes through with onUpdate checking for power usage. I just need to add one line to the stopScan event.

The SAR scanner shouldn't pick up on anomalies anyway. I didn't have any problems with the orbit track, but I'll check on this some more.

To be clear, these scanType shenanigans are only necessary for background scanning, simply adding an overlay doesn't require any of this. And as for doing this for background scanning, it's basically what technogeeky said. Scanning data is recorded in an array that is stored in the persistent file. So once you have data scanned with any given scanner type it will be persistent and anything that refers to that scanType will see the same record. Even if you could delete the record for just that type of scanner this would still only allow for background scanning of one resource at a time. TG's suggestion of using a different scanType enumeration is probably the best idea. That way nothing about the regular version would need to be changed and the new types could use all 255 available values. In any event it's the dependency issue that really needs to be worked out, though I've just had some ideas on that, but I probably won't get anywhere soon.

Thanks. MeCripp also mentioned the Modular Kolonization System that I think adds four Kethane Resources, though one of them is Ore, and I'm not sure if that's the same as the one used by Extraplanetary Launchpads. So that's a lot of potential resources... Am I right that ORS has no persistent method for storing or displaying resources? There is no in-game map, it just shows you resources that you are currently picking up with the scanner (and apparently some kind of indicator texture of some sort)? If so that should greatly simplify adding support for it. I wouldn't have to worry about pulling any data out of some ORS database or re-syncing said database with the SCANsat record after background scanning. I'm actually thinking that it might not even require any dependency on the ORS plugin (or the KSPI plugin, or whatever it uses). On the other hand, it looks like ORS is designed to allow for the .dll to be distributed with other mods. It should be simple enough to include the ORS .dll, allowing me to add a hard dependency on the assembly; it wouldn't have any affect if you don't have any ORS resources, and it wouldn't require any awkward solutions like RPM, or what codepoet has been discussing with connected living space and ship manager. I'll have to look at it more to figure out what would work best.

That's looking really nice, I like that the door actually has a working mechanism. Are you planning on putting in any internal structure for the wedges, or will those be added on a case-by-case basis?

I checked out the latest release on my regular, full installation of KSP. I put a bunch of vessels in orbit (without cheating!) with different sensors at difference altitudes. I checked scanning for all of the different sensors, everything seems to be working, both for regular scanning and background scanning. All of my attempts to break the big map failed, so that's a good sign. I also did some brief testing without Toolbar and that was working fine. There are a handful of very minor issues and one slightly less minor issue that I found. All of which, I think, can wait for another major update to fix. The MapTraq has a non-functional "analyze data" action group available in the VAB, and the BTDT has both the action group and the right-click event for "analyze data", all of these should be removed. The commented out lines in SCANcontroller (437-439) that change the fov calculation also make it so the blinking orange/green light never goes away, at least I think that's what's happening. It doesn't affect scanning though. Also, I'm not sure if anyone really cares about this, but the MapTraq and BTDT are kind-of sunken into the part they connect to. The line in their part.cfg file should be: node_attach = 0.0, -0.1, 0.0, 0.0, -1.0, 0.0, 0, currently it's: node_attach = 0.0, 0.1, 0.0, 0.0, -1.0, 0.0, 0 (flip the sign on the second value). The less-easy to fix problem is that when the big map overwrites low resolution altimetry data with high resolution data it only changes the color. The blockiness of the low resolution data remains until you rebuild the big map cache (just change the size a little bit). This isn't a big deal, it's easy enough to rebuild the cache and it's probably not all that common to scan with a low resolution scanner, then do it with a high resolution scanner in such quick succession. I also discovered that the big map cache is persistent through vessel and scene changes, which is nice. Also, I would hold off on adding caching to SCANsatRPM. It's resetting the map size every time the map rebuilds, so a cache wouldn't do anything but take up space in memory. I'm not entirely sure how it decides what size to set the map, so I don't know if this can be worked around easily. I'll try to test it out with RPM at some point and see if I can't get it to tell me what size it's setting the map at. Otherwise I think it's fine, everything seems to be working correctly.

I didn't consider using it as just a byte rather than a bitmask, but you're probably right, it should allow for plenty of different types. The scanType of 3 is used internally for generating maps, basically it is just a way to check if the specified location has been scanned by any type of altimeter before going on to determine which type and assigning the proper terrain height value and color. I don't see any reason why it can't be modified to check either type separately rather than using the current method. Checking a small array twice is definitely not the performance-limiting step of generating the big map. Using a separate type-enumeration might be the simplest method. I think dependency issues will require recreating a lot of this code anyway, so it might make sense to create a different scanner type for other mods and make that one not use a bitmask, while the standard scanner type could remain unchanged. Multiple modules for combined scanner types is another possibility. I figured out most of the issues with keeping things from getting too messy when I made my Universal Storage science parts with two experiments on the same part. They each have two science modules and two of my version of the environmental sensor module (that controls the readout for each part and the fancy animations).

Does anyone know how many resources use the Kethane grid? Or how many use ORS? SCANsat is limited to eight different scanner types, there are currently five (the mapTraq is type 0 and so doesn't count towards this limit), but I think the biome and anomaly type can be combined and the BTDT type can be dropped entirely. I can see no scenario where anyone would need background scanning for the BTDT, and it doesn't give science the way the other scanners do, so I think it would be better to create a different module specifically for that part. That leaves three default SCANsat scanner types. With room for only five more types I'm not sure how feasible it is to add support for more than the standard resources. Those would be Kethane, the Interstellar resources (maybe?, I haven't looked into these specifically) and maybe Ore. Increasing the number of available scanner types is not trivial and might cause issues with the amount of data that needs to be stored in the persistent file. I'm also not sure how feasible it is to switch which scanner types are available based on the resources mods that the user has installed. By that I mean that it might be necessary to explicitly support certain resource types (support for Kethane, but not Ore, for instance). I looked into ORS briefly. From what I can gather the scanner works by checking your vessel's current position, mapping that position onto a specific pixel on the resource texture, and checking that pixel for the presence of the specified resource. It should be no problem to adapt SCANsat to handle background scanning and map overlays for these types of resources. But again, there could be problems if there are too many types of ORS resources. There are also massive dependency issues with all of this. I'm not sure how to get around this problem other than by basically recreating large sections of the SCANsat code in a different .dll that can be optionally installed. And this would probably run into the same kinds of problems that RPM does when any of the other mods update. So don't expect anything to come of this soon. It's obviously possible to include support for scanning other resource types, but the actual implementation has many issues that need to be worked out.

That's a pretty good idea. It makes sense, too, that you might want to pack some kind of fold out antenna into a storage wedge rather than have it awkwardly hanging on the side.

Arghh, I see the problem now, it's the same thing that was happening to me while testing the Kethane grid. The zoom map uses the same methods as the big map, so it breaks the height map array. I think I can fix it, I'm testing a solution now. Edit: Should work now after my last pull, but probably warrants a bit of testing. The only end-user change is that you can't open the zoom map while the big map is still re-building (right-clicking on the map won't do anything).

I think I've found the problem, at least one aspect of the problem... If you were using a previous version of SCANsat and you had an active vessel with the low res scanner turned off then the analyze button would be disabled and has no way to be re-enabled once you moved to the new version. This should be easy to fix. But, that shouldn't cause new vessels to also lack the analyze button. Edit: I fixed the problem with existing vessels, it should theoretically make new vessels work properly too if they are also having this issue. I sent you a PM with the link, if it works I'll push the fix to TG.

Can you set an action group for analyzing data in the VAB? And if so does it work?

There is much to be done in making the different windows match up better, in style, content, and some aspects of their behavior. Close buttons on some windows, X boxes on others, different behavior when dragged off-screen, the ability to minimize the bottom info section of the small map, etc... Much of the information about your current scanning vessels could be included on the big map, in addition to the mouse-over information. It might also be a good idea to add a way to minimize this bottom info panel too, especially if you make the big map relatively small. Some changes to the small map might not actually work well though. Because it is much lower resolution, in terms of pixels and the granularity of the data it shows, I don't think biome or slope maps would be useful. They would probably just end up being difficult to read and not very helpful. I agree about the anomaly coordinates too. Aside from making things too easy there are some technical problems with relying too much on the exact position. The "anomaly" position doesn't always match up exactly with the actual structure, and there are further complications when you have more than one structure per anomaly.

Is this version 6? Are you using the default part.cfg files, the ones included in the download? Do the other sensors have an "Analyze Data" button? The way that the analyze button is handled was changed a little bit. It should always be present, even if you aren't scanning, and the MapTraq part shouldn't show the button at all. If any one scanner type is working properly then all of them should be. Edit: A brief check of the latest build shows everything working fine for me. Is that the SCANsat toolbar icon shown in your picture above, the last icon on the right? It shouldn't be so small like that. Maybe try deleting and reinstalling the SCANsat folder.

Yes, this is nowhere near ready. That said, I put in some options in the settings menu to control the overlay and to allow for multiple resources that use the Kethane system. These options work (turning off the overlay all together, selecting which resource to display), but there are multiple problems. One is that they don't take effect until the map is rebuilt. I think there will also be problems if people have too many Kethane resources; it probably needs some better way of handling the options, preferably a pop-up menu of some sort. There is currently only one SCANsat sensor type that works for Kethane. The way it's coded right now that sensor will reveal every resource that uses the Kethane system, which obviously isn't good. It's possible to add different SCANsat sensor types for each different resource, but I'm not sure if it's really feasible to continue adding more scanner types. I also fixed the empty cell color. I realize that the Kethane grid varies the color based on the amount of resources in the deposit, I don't think that's a good idea here, it would probably make it much harder to see when layered on top of the regular map. Edit: It should also be noted that this has all of the same dependency problems that everything else does. Making Kethane a required dependency is obviously not an option. Kethane is relatively stable though, so maybe it's a good idea to make a separate .dll specifically for handling Kethane interactions. Adding a MechJeb target overlay would also be great (it would finally make the slope map really useful), but probably will have the same problem the RPM does. You can see the settings menu options here on the left and the fixed empty cell colors. The ore map from extra-planetary launchpads is below. Also, this happens sometimes. I think it has something to do with right-clicking and dragging to move the camera while the mouse is over the big map, the Kethane grid, or maybe both.

I think the idea is to search through all of the existing resources on any given game, find out which ones are Kethane resources, and allow for the user to select which one to display. I'm not sure about displaying multiple resources at the same time though. The settings menu could probably have (as long as the right plugins are found) a button to enable/disable the overlay, another to select the resource and a check box to enable background scanning. Then the big map would have a button controlling the overlay for the selected resource. There's probably a better way of rebuilding the Kethane cell database, but that can be improved upon later. I'm not sure that there's really a need for more than the two maps already available. You can already monitor elevation data on the small map while refreshing the big map for biomes.