Wheffle

If you want a deeper and more detailed scanning experience with different types of maps (like altitude maps and such), SCANsat will probably interest you. It adds a lot of stuff to KSP that simply wasn't there before and provides you with a lot of cool projections and different types of scanners. There are a lot of options available to keep the stock resource surveying in place while using SCANsat or let SCANsat replace it with its own system, to varying degrees. My goal for OSP was to simply augment the stock resource system. If you generally are satisfied with the stock system except for the surveyor's magic instant scan ability, or you just want to keep your mods light, OSP might interest you. It's what I feel the stock system should have been like. Technically I don't think they will fight with each other if you use both, but honestly it's pointless to use both. * * * @RealGecko Yes, this would technically work with any planet packs, as long as the textures use mipmaps (I'm not positive whether the planet authors have to do it manually or Unity produces them automatically). @Enceos Ah, interesting, I missed this mod. Well, no need to reinvent the wheel! Looks like a great mod. @curiousepic Seeing as how Research Bodies seems to basically be doing what I was messing around with, it would make sense to move in a different direction and try using the overlays like what you were describing. I can already foresee some issues, but it could be cool as a "hardcore" option. I'll think about it!

Yeah, had to coax them out. They should be there now.

@curiousepic @Enceos After a billion years I have started poking around with unexplored planet blur. Not sure if anyone is still interested, but there you have it. I've managed to find the normal and bump map textures for planets and set a 'mipMapBias' Unity setting to a large number, presumably causing Unity to choose a smaller mipmap even at close camera ranges. Here are some comparison examples: Moho: Eve: Duna: Dres: Gilly: As you can see, the results are mixed and sometimes kind of weird. It looks like planets with atmospheres (like Eve) get completely washed out, which is fine because that's kind of what we realistically see when we point telescopes at planets like Venus. There is obvious detail loss on Moho, Dres and Duna, but Duna seems to be very pale for some reason and the physical shapes of rocky planets isn't being obscured, so peaks and valleys are still pretty visible. There is almost zero difference with Gilly probably because its extreme non-spherical shape cannot be masked by altering textures alone. Granted I did this on my laptop which is pretty low-end and the textures don't look that good even without alteration. I might hop over to my desktop and see what happens there. I'm worried that the results might vary between hardware and platforms because the changes are fairly low-level, but that fear might be unfounded as part of the reason engines like Unity are popular is that it does its best to standardize results across platforms. For anyone that has more experience with Unity (especially with rendering and stuff) I'd love to know any alternative methods that could be tried. I'm not much of a graphics person and I've only just put myself through a small Unity rendering crash course for this. Most importantly, would anyone still be interested in something like this? My ideas are that the planets outside of the Kerbin system would be blurred until a spacecraft with either a Kerbal or active comms entered the system, at which point the planet and its moons would be revealed in more detail. As a bonus, I was thinking upgrading the tracking station could grant you slightly more detail for unvisited systems. I'm also thinking it best to break this off into a separate mod altogether. Thoughts?

Small-ish patch deployed. Made a few optimizations that should improve performance. Saves are backwards compatible, but the wise will backup their saves anyway. After a bit of testing, seems to be fully compatible with KSP 1.2.2. No update needed. Spacedock | Curse Edit: After a bit of testing, seems to be fully compatible with KSP 1.2.2. No update needed.

Pushed out another update that I worked on over the weekend. Scan area no longer gets distorted at high latitudes, scanning at high time warp works a lot better, and overlays can auto-refresh if that's what you like. A few bugs have been squashed as well, including stuff that was really hitting performance. I looked at using Kethane's geodesic grid to resolve the scan area distortion problems, but I ended up using simple mercator projection scaling instead. While the hex grid looked pretty cool, it added a lot of complexity and performance issues. I'm pretty happy with the new scaling though. Should be compatible with current saves! Download Spacedock | Curse

zomg flexible docking i am drooling uncontrollably

Just pushed the update! It's nothing more than a migration to KSP 1.2 really. Soon I'd like to push out a more extensive update to make some needed improvements and maybe add features. Also, this was not very exhaustively tested, so please post any bugs you run into.

My code seemed to be working fine for KSP 1.1, but now the stock app toolbar stuff is all wonky. Buttons are appearing in scenes that they shouldn't and stuff like that. Code for KSP 1.1: // a MonoBehavior class public void Awake() { appButton = ApplicationLauncher.Instance.AddModApplication( ButtonPressed, ButtonReleased, null, null, null, null, ApplicationLauncher.AppScenes.MAPVIEW | ApplicationLauncher.AppScenes.TRACKSTATION, GameDatabase.Instance.GetTexture("PATH_GOES_HERE", false) ); } From what I understand, the ApplicationLauncher should do all the showing/hiding based on the AppScene parameter. This worked fine for 1.1, but in 1.2 it's showing the button in scenes where it doesn't belong, including the main menu sometimes. I looked through the forums and other source code, and it looks like people are using event callback functions from the application launcher to add and remove their buttons based on those. So I changed my code to this: //a MonoBehavior class public void Awake() { GameEvents.onGUIApplicationLauncherReady.Add(AddAppButtons); GameEvents.onGUIApplicationLauncherDestroyed.Add(RemoveAppButtons); } public static void AddAppButtons() { if (ApplicationLauncher.Ready) { appButton = ApplicationLauncher.Instance.AddModApplication( ButtonPressed, ButtonReleased, null, null, null, null, ApplicationLauncher.AppScenes.MAPVIEW | ApplicationLauncher.AppScenes.TRACKSTATION, GameDatabase.Instance.GetTexture("PATH_GOES_HERE", false) ); } } public static void RemoveAppButtons() { ApplicationLauncher.Instance.RemoveModApplication(appButton); Destroy(appButton); } Something like that. I tried to mimic what I saw. I don't understand why you'd have to manually add and remove buttons, I thought the point of the ApplicationLauncher was to remove that kind of tedium. I also can't find any documented changes made going into 1.2 with the way the ApplicationLauncher works, so I'm thoroughly confused. Maybe my code before was flawed and it just happened to work anyway. Any help would be greatly appreciated! Update So it looks like the callback functions can't be static or else it throws a null pointer exception and nothing happens. I made the callback functions non-static, but I'm still having MAJOR issues getting my button to NOT appear in scenes where it doesn't belong. I moved my code around, and now it looks like this: [KSPAddon(KSPAddon.Startup.AllGameScenes, false)] //Does this need to be something specific? Removing it seems to make it never load class MyClass : MonoBehavior { ApplicationLauncherButton button = null; protected virtual void Awake() { GameEvents.onGUIApplicationLauncherReady.Add(AppLancherReadyCallback); GameEvents.onGUIApplicationLauncherUnreadifying.Add(AppLauncherUnreadifyingCallback); } protected virtual void OnDestroy() { GameEvents.onGUIApplicationLauncherReady.Remove(AppLancherReadyCallback); GameEvents.onGUIApplicationLauncherUnreadifying.Remove(AppLauncherUnreadifyingCallback); } public void AppLancherReadyCallback() { if (ApplicationLauncher.Ready) { button = ApplicationLauncher.Instance.AddModApplication( ButtonPressed, ButtonReleased, null, null, null, null, ApplicationLauncher.AppScenes.MAPVIEW | ApplicationLauncher.AppScenes.TRACKSTATION, icon ); } } public void AppLauncherUnreadifyingCallback(GameScenes scene) { if (ApplicationLauncher.Instance != null && button != null) { ApplicationLauncher.Instance.RemoveApplication(appButtonBiomeOverlay); } } } At first it seems to work (no button shows up until I'm either in the tracking station or map view in flight), but when I return to the main menu, and sometimes when I go to the space center, the button shows up. Not always, just under specific circumstances. I'm very confused and getting pretty frustrated that I can't get a simple application launcher button to behave like it used to before the update.

Update: I'm not currently planning on continuing support for Fairing Tweaker. It was originally a band-aid for the stock fairing system that I liked but had some issues that really bugged me. With the last couple of KSP updates, the stock fairing system has improved to the point where I feel the mod is obsolete (in my opinion). The only real part of the mod that would be nice but isn't in the stock fairing system is the edge rounding, but I don't feel like that warrants an entire mod and I can live without it. If anyone has any compelling arguments for why I should support/update the mod, feel free to convince me Alternatively, if anyone wants to pick up the source code for whatever odd reason (there's really not much to it), have at it.

Just an update: I've taken a look and made changes for KSP 1.2 (code turned out to look almost exactly like @RealGecko's changes for his recompile, thanks for picking that up!), but it looks like there are some subtle and not-so-subtle issues that need to be ironed out, including the resource map shrouds not being applied correctly. I'll try to get these issues ironed out and bring it back to pre-1.2 functionality and release an update before I dive into any "extra" stuff I was planning on trying to include soon.

I actually haven't tried it to see if it works at all. I have no idea how it will interact with KerbNet and the new communication system, which is why I was holding off until I could do testing. If anyone has tried it, feel free to let me know what weirdness or lack of weirdness resulted.

I'll get on it when I can, but currently I can't give a set time frame. As they say, "soon (tm)". I'm pretty swamped in school at the moment. I would rather have OSP updated before I start my 1.2 career (so I can use it) and I am really looking forward to playing 1.2, so I have personal motivations that ensure it will get done eventually...

Thanks! With KSP 1.2 on the doorstep, OSP is due for an update. Unfortunately I have to give the usual caveat: I'm in the middle of a semester at university and have been pretty busy, so I can't give a time frame on the next update. I haven't figured out how (design-wise or technical-wise) OSP will integrate into some of the new features, namely KerbNet, so that might take some time as well. All-in-all, when I get the ball rolling again, I'd like to roll the next update out with new and improved features as well as 1.2 compatibility. Specifically I'd like to fix the scan-skipping on high warp times and improve the method of data storage in the persistence file. I will also take a look at the much-asked-for-but-probably-given-up-on-by-now planet shroud feature and auto-updating the resource and biome map.

@Jiraiyah That's normal behavior. Unfortunately the map update is too laggy to do auto updates. You'll notice a small stutter when you bring up the ore or biome map; that would not be fun to deal with if it was happening automatically every second or multiple times a second.

Yes, that's it. The radius units unfortunately are in arbitrary grid cells, so you might just have to tinker with it to get a radius you like. If you set it to 2, the radius of the scan area will be 1/4 of the default.

I believe I made it adjustable in the config file for the scanner. If you've messed with KSP config files before, it should be easy to find. If not, let me know and I will walk you through it. It's a simple value change that will reduce the radius of the region scanned every tick.

Although I haven't personally tested it, yes, the mapping data/science transmission should need a connection when you're using AntennaRange. I'm not familiar with AntennaRange's internal workings so I can't guarantee it (if you test it, let me know!). To answer your second question, the scan will definitely continue while it is out of range or has no line of site. It stores up the map data it has scanned without any need for transmission, and then the map is revealed once it is transmitted back. So theoretically you can scan the entire planet with no active connection, bring it into range and transmit the whole map back to the KSC all at once.

Thanks for testing it for me! I'll officially update it when I get the chance, along with a few small improvements probably.

In career mode, which is what I mostly play, I've been able to return from orbit of Duna and Eve but not from the surface of either, and I've not done anything more than throw a small satellite out to Jool. The problem is that I am mostly just interested in career, and every time the game updates I tend to just start my career over rather than try to port it into the next version, with all the mods I use bouncing around causing problems across updates.

If you look in the "patches" directory in the OSP folder, you can make changes to the module patch there. It includes scan radius, electric charge drain, and science bonus I believe. It would be cool to have some kind of biome key. I will look into it, but I have no idea how feasible it will be. I most likely will never add any other kinds of maps, like altitude or anomolies or whatever. My goal is to keep OSP as simple and stockalike as possible.

Your landing gear shouldn't be exploding. If it is, you're using much too small gear. I had issues with the wheels actually popping, and moving up a size in landing gear solved it for me. Now I can slam into the ground pretty hard and everything holds fast.

Oh hey, cool! So, it should work with any kind of mod that adds planets (based on how the mod works), although there's an old post on this thread that I noticed saying there might have been a bug on an old version with extra planets. I might do some testing myself, as I'm curious. As far as scaled planets go, the size of the scan data depends on the planet's size, so a mod that scales up, say, 10x, will scale up the scan data 100x. This could cause slow-downs. If it turns out to be a huge performance issue, I might try to address it. Cool.

@Enceos Not a big deal There's some good info being discussed.

This is a sweet mod.

Pushed out a patch. You should be able to actually get transmittable data from Minmus and Gilly now. Fixed some other silly little bugs. Hopefully didn't introduce new ones. As always, let me know if y'all find any.