Wheffle

@markal glad you got it figured out! toggling between views with that button is not a bad idea. i leave most of the stock stuff in-tact but i might look into that.

@markal I see it on the bar on the right side of your screenshot. The little satellite icon over the colored globe: Edit: Just thought of this, not sure if this is it but I figured I'd say this just in case. You might have gotten the ore map and the biome map confused. The button shown above is the biome map. To get the ore/resource overlay, you use the same button you use for stock. To get that button to appear, you have to focus the camera on the planet first, and then the button with the icon of a globe with a slice cut out of it will appear. OSP integrates with the stock system so it uses the same button.

New Update I finally found time to track down and fix the slowdown that happens often when you have an overlay up for a planet. Hopefully it's fixed, at least mostly. Quick test results were good. Let me know if there are anymore problems. Spacedock | Curse Important Note: Seeing as how KSP 1.3 just came out and a lot of mods aren't compatible yet, I actually deployed two updates. The first update fixes the slowdown issue and stays compatible with KSP 1.2. The second update is the same update but is compatible with KSP 1.3. If most of your mods are still on KSP 1.2, stick with the first update for now to still get the benefits of the patch and move on to the latest one later. Quick Link for latest version compatible with KSP 1.2 Orbital Survey Plus 2.3.3 - Fixes the slowdown issue and stays compatible with KSP 1.2 Orbital Survey Plus 2.3.4 - Fixes the slowdown issue and is compatible with KSP 1.3 As always, let me know if there are any problems or questions.

@maculator The biome map is actually the same one you can access from the cheat menu. I don't know if the colors are associated with biomes anywhere in the system. I might look into it when I get to working on this mod again. Unfortunately sometimes having the biome map up on a not fully scanned planet can cause some narley lag in some cases, it's not always easy to predict when. I've resorted to using some pretty hack-ish methods to intercept KSP's overlay textures and modify them before they get deployed, and unfortunately ever since they cleaned up the biome map to give it more resolution it has gained the potential to hog resources, again only sometimes. Fortunately this isn't a problem for the ore overlay. It's something I will address when I have time to work on OSP after finals, I sincerely apologize for it. Edit: In the meantime, if the biome map lag is consistently wrecking your framerate, you can uncheck the "biome map requires scan" option which will alleviate the lag. Of course this means that, well, the biome map doesn't require scanning, so that kind of sucks, but the ore map still will.

This mod has never had any role to play with SCANsat whatsoever. They are generally mutually exclusive, and I'm not entirely sure what happens when you install both (it might not crash or anything, just be broken/weird/confusing/whatever). Some reasons to use SCANsat: You want maps besides the planet overlays that are interactive and allow you to place waypoints, you want different types of scanners for altitude maps, biome maps, resources, etc., you (possibly) want to skip the narrow band scanner or ground-truthing phases of resource scouting, and you generally crave more complexity and a more fleshed-out planet mapping and scanning experience. Some reasons to use OSP: You generally like the stock resource system, you want to stay stock-alike, you don't crave much more complexity but the stock M700 Survey Scanner's instant reveal drives you insane. Or you like the stock system and simply want a biome overlay without using the cheat menu. Hope that clears things up a bit.

Pushed out an update Spacedock | Curse Mostly deals with the issues that have been brought to my attention that occur when you use OSP with RSS or other alternate solar system mods that scale planet sizes up. OSP will now take a look at the solar system and scale the data grids to stay at sane sizes so memory and save/load times won't skyrocket. Thanks @ZobrAA and @MusicMetalHead for the help! Most users won't be affected by the big changes, but everyone should enjoy a few optimizations and other small changes. Might have to wait a bit for curse to "approve" the file upload. Spacedock is usually a good bet.

Yes. OSP isn't intended to be ultra realistic, just a step-up from stock. I figure die-hards have SCANsat.

You can tweak the scan radius in the config files. GameData > OrbitalSurveyPlus > Patches > OrbitalSurveyPlus.cfg > ScanRadius = [whatever you want] Default is 8, so try shrinking it to get a value you like.

If Kerbin is still the home world, its grid (and the scanner's radius) should look exactly the same as in stock. Since the Mun is smaller relative to Kerbin that picture makes sense. Kerbin's grid does look a bit small though, might need to do a bit more fiddling. Thank you for the feedback!

Those scan cones do look a bit big. If the patch is working correctly scaling should be based off the home planet. If bodies are much smaller than the home planet then the grid will be a lot smaller, causing a larger scan cone, and the opposite is true. Are the pictures you are showing from stock or has the solar system been altered?

@ZobrAA @MusicMetalHead I cooked up a quick dev patch that looks like it solves the issue. If y'all want to try it out and let me know if it helps, get it at this link: OSP 2.3.2 - dev 2 - patch for RSS You should either start a new save or use it on a save where no scanning has been done. If neither of those options appeal to you and you want to do it the hard way, you'll have to go into the persistence file and delete everything inside the "OSPScanData" node of the OSP Scenario section. Example Screenshot I'll continue testing and will release a full update hopefully along with a few other changes before long.

Haha. You can start a sandbox save and cheat your way up if you need to. I'll be doing some tests of my own though if you can't get around to it.

Well, the path isn't exactly "straight". When you project the path onto a 2D map, it is quite curvy (unless you are exactly equatorial). I can take another look at the code for retroactive scans, but to make sure can you see if you get the same problem when you turn retroactive scanning off in the options? The massive data grids getting created and put into memory as a result of RSS could be causing a memory-based crash as well.

Ah, I see what you are saying. I thought you meant revealing one orbital strip at a time. Well, that *is* an option to cut down on memory and CPU, but I'd rather keep the dynamic scanning that we have right now. I suppose I can add it as an option for lower-end systems or RSS users. It can be a fallback if I can't come up with a good solution otherwise.

I might look i to alternative methods like the one you described, but at first glance it seems a bit more complicated. The planet is rotating as the scanner orbits, so it won't be a simple belt. This is why high inclination orbits will eventually scan all/most of a planet even without switching inclinations.

Yes, that setting helps to cut down on having 99% planets scanned hanging around. Any planet with 100% scan will stop taking up save space.

Yeah, it might not be jiving well with RSS. I'll be looking into it this weekend.

It actually should be doing something like that already. Does it not appear to be doing so? Are you getting lag even though all planets are either 0% or 100% scanned?

Yes, the autosave will build the save node tree from scratch every time. It's just the way KSP is built. I will try to come up with a solution soon, maybe just by adding an option to scale the data grid for users with RSS. Thank you for reporting the problem!

Well shoot. Let's see if we can figure this out. At first glance I suspect it might be RSS. Planet data grids are based on their size, so having much larger planets could inflate the data to ridiculous levels. @ZobrAA are you using any mods that make planets bigger? @MusicMetalHead have you scanned any planets in RSS yet? Did the problem by chance start during your RSS playthrough? If this is the case I'll try to get an update out that will scale down data size for RSS users.

Hmm... I haven't thought about adding contracts. I might take a look.

If you check out some of the images they have in the imgur album they have linked, they obscure the surface and it you slowly get more detail the more you research it. You're right, though, it's not exactly the same thing as what I was thinking about implementing. I'll continue looking into it.

@Jarin It looks like the mod ResearchBodies has already implemented something very similar, so I'm not sure it's worth overlapping in that territory. I might do something a little bit different using planet overlays to mask detail instead. I'm not exactly sure yet.

Unfortunately it might have been one of those "it's working, don't touch it!" moments. Thanks for the heads up, I'll take a look. Edit Yeah, it's coming back to me after taking a look. The experiment definition doesn't exist because the stock survey system doesn't use an experiment definition either, it's just a transmission that is thrown out there and caught by the callback. Yes, it's very strange Squad did it this way, and it probably would be cool to set up proper experiments for my add-on, but it is what it is. Currently I'm using the ScienceData subject to identify the module that sent it. In the next update I'll be sure to at least make the subject unique with your suggestion.

When I dug into it I found this to be odd as well. It seems to circumvent the science system altogether and save its state only in a separate scenario (ResourceScenario). Unfortunately I hacked OSP to do what I figured the stock system was doing anyway, probably very clumsily at that.