[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[TinyPirate]

I like different altitude brackets for various sensors. Perhaps optical sensors (accessing a high-res surface texture, eg, universe replaced) requires 80-100k (or equivelant on other objects), radar higher, anomy, something in the lower bracket, and so on. But I imagine displaying the optimal/bracket for each sensor around various bodies might be tricky.

[OrtwinS]

I like different altitude brackets for various sensors. Perhaps optical sensors (accessing a high-res surface texture, eg, universe replaced) requires 80-100k (or equivelant on other objects), radar higher, anomy, something in the lower bracket, and so on. But I imagine displaying the optimal/bracket for each sensor around various bodies might be tricky.

I don't think it'll be that tricky, most bodies can be orbited in the 80-1000 range. That gives enough room to play.

Low-altitude sensors can still have their operating range like '>20km' which will keep them functional for even Mun, Minmus or Gilly.

Maybe sensors shouldn't have a fixed 'vision angle'. The optimal sensor altitude can be simulated by different sized scan surfaces!

Say sensor X works best at alt 120-200,

It will still work below 120, and above 200, but with a smaller scan surface (simulating less than ideal conditions). This wouldn't make sense at all if you argue form a fixed view-angle, but it might be a cheap way to simulate 'optimal' altitudes.

The most advanced version of this method would use a (rough) gaussian-like curve that has a 'full size scan' at a certain height (A flattened top to simulate an ideal range), and reducing performance above and below that, going all the way down to no scan surface at all (out of functional range). This might actually be implemented by a series of steps in stead of a curve, or a trapezoid graph, whatever works best.

Edit: If such a mechanic is implemented, the defining values for the curve (or step-graph) might be nice to have in the .cfg file. Makes them easy to edit during beta.

*feature creep alert*

Edited November 1, 2013 by OrtwinS
grammar

[Milkshakefiend]

I'm not sure this has been suggested or not (forgive me if it has) but what about some dedicated aeroplane scanners? Those high altitude high velocity monstrosities need a functional use and I though using one fitted with some sensors could be good for localised high-res detail.

[kahlzun]

I'm not sure this has been suggested or not (forgive me if it has) but what about some dedicated aeroplane scanners? Those high altitude high velocity monstrosities need a functional use and I though using one fitted with some sensors could be good for localised high-res detail.

That's basically what the BTDT is for.

[killer420]

Somebody informed me today that this is using Surfer 11 if that's true will there be a way of exporting the files to it so I can mess around with them in there. Im sure if so you havnt thought about it as its a very expensive program and there wont be a high demand for it.

[Nostromo]

Maybe aesthetically, there could be something like this for aircraft, without the nose cone covering, later on in development.

Edited November 2, 2013 by Nostromo

[DarthJazno]

Is there a way to adjust the "sea level". My wife likes a pink Mun, but I'd like to tone it down a bit.

[simmy2109]

OH MY GOD. You sir have made an incredibly amazing mod, and I don't think you realize it. Those of us who loved ISA Mapsat have been looking for a new developer to worship. You remade ISA.... but WAY better. I applaud this tremendously. Take advantage of all the people offering to help you model/texture!

[drtedastro]

I may have overlooked or missed it, but, will multiple sensors of the same type give better results for high speed (warp) scanning? Not an issue, just a curiosity. Thanks.

[damny]

Hmmm... It uses the bulkier grey GUI on my end... When I warp however it switches to the lighter, transparent GUI...

My best guess is you have a mod that I don't have that switches the skin and draws its stuff before SCANsat... if that's the case, the next build might stop that.

Eh, I did, but that is beside the point.

The only scanners I can think of that should actually be combined into one is the Altitude and Slope RADARS.

I half regret making slope a separate sensor. I thought it might make sense from a gameplay point of view to have it separate and make it more expensive to use, but I think I'd rather fold it back into altimetry and try to find some other possible sensors to implement that actually do something different.

Biome/terrain regions are a specific type (I imagine spectroscopy to detect different elements).

Currently it's also RADAR (SAR), but I'm thinking about changing it to a multispectral sensor. When I worked with SAR data we did use it to detect terrain type, but I think it would make more sense if the low resolution altimetry sensor was conventional RADAR altimetry and the high resolution one was SAR.

Anomaly Scan could/might be integrated in the altitude RADAR at the higher tech levels (the adv. altimeter radar could be precise enough to detect 'anomalies'). Detecting something the size of a monolith from orbit requires a pretty high tech level.

I'd like to keep this one separate, because I might want to tune its parameters independently of the other sensors. In reality it could be any sensor, of course, because people look at the data or images and find the anomalies. When I worked with SAR, we used SAR images to (automatically) detect structures, but we also did that with visible band images. The advantage of SAR over optical sensors is that it works at night and through clouds, but in reality you can use almost anything to find unspecified "anomalies".

It might actually be interesting if anomaly detection used some kind of optical sensor, because if it doesn't work at night, it would be more important to get into a good orbit and it would make the sensors more different...

Maptraq is also unique. It will probably have a significant smaller model and lower energy consumption, the kind of part that you put on everything to allow it to access mapdata (I imagine Kerbals prefer a stand-alone system that can quickly scan it's surroundings and compare that to the known database, in stead of a system relying on an external and complex network of sats like GPS)

I actually like the idea of requiring a GPS satellite network, but how do I explain that if KSP already shows you your position in map view?

I'm thinking that the position indicator could only be visible in the zoom box if you're either above a certain altitude or in range of three or so satellites...

And that leaves us the optical sensor (which does not exist, and perhaps never will). Another completely different type of sensor.

I really want one, I just don't know how to implement it in a way that makes sense. I don't want to just show another slightly different looking map. An optical sensor would still do that (maybe a shaded relief using actual colors from the planet texture?) but I'm thinking that at this point, any additional sensor would also have to add another benefit. Unfortunately there's not a lot of things one can detect on planets in KSP. At least until we get resources.

If I had infinite time, I'd just add things to the game along with the sensors. Like roaming animal herds on Kerbin But I don't have infinite time.

The scanning surface restriction is also 'part of the game'. I don't think it has ever been the intention of any mapping plugin to *poof* supply you with all info you want. We have a wiki for that. If you just want an ingame map display I think you should request a seperate plugin for that.

The thing is, the way this plugin works, I could add a button next to "Forget Map" that says "Remember Map", since the actual scanning is deferred to when the map is rendered. But that's not what I'm trying to do...that would just make the game shorter, but I'm trying to make it longer by adding more goals you can set for yourself.

I'm not sure this has been suggested or not (forgive me if it has) but what about some dedicated aeroplane scanners? Those high altitude high velocity monstrosities need a functional use and I though using one fitted with some sensors could be good for localised high-res detail.

It's hard for me to think of something that would work. The BTDT sensor is quite nice for airplanes, and while it doesn't work at high altitudes, you might still need a high altitude plane to get to the point where you want to use it. But anything that actually results in a map would probably just be annoying for people who want to complete their maps.

Somebody informed me today that this is using Surfer 11

I have no idea what Surfer 11 is so I don't think I'm using it

I may have overlooked or missed it, but, will multiple sensors of the same type give better results for high speed (warp) scanning? Not an issue, just a curiosity. Thanks.

Not when they're on the same craft. Multiple sensors of the same type on the same craft should deliver exactly the same results as one sensor of that type.

[Nostromo]

Hey damny, sorry to bug again. I was thinking about some other radar type that could be fun to add.

RWR (Radar warning receiver)

This would show objects/vessels near by on the same plane (well somewhat, give or take). The "map" could look like that real RWR and just mark them abstractly on there: http://upload.wikimedia.org/wikipedia/en/f/fc/Rwr_example.gif

Edited November 2, 2013 by Nostromo

[ilikemoneygreen]

I for one would just like to extend a +1 and vocal support for the idea of roaming animal herds on kerbin. Get it done Damny. Get it done.

[Scotius]

I'm scanning Kerbin and Mun right now - and loving it It looks good, feels science-y and works without hiccuping or crashing. Now we need only better models for the parts, and ability to gather science and it will become 'must have' mod for everyone, not just mapping nuts

[therealcrow999]

I'm scanning Kerbin and Mun right now - and loving it It looks good, feels science-y and works without hiccuping or crashing. Now we need only better models for the parts, and ability to gather science and it will become 'must have' mod for everyone, not just mapping nuts

I'm sure somebody is working on some new models or will be. It takes time with new mods. I think the models currently in mod were only there to test mod and see if it worked, a simple model design. Most programmers aren't modelers.

[KhaosCorp]

Look back through the thread..few of us are making replacement parts....

I got a set going, but work is kinda slow, on account that my daughter was real sick..and now I am lol...hate this time of year....

Couple others had mentioned workin on parts too.

[simmy2109]

Getting a very strange problem... trying to use these in my KSP career save, but the parts claim I don't have the science researched. Except that I do have Science Tech. Worse... I tried modifying the files to "TechRequired = start" but I still have the same problem. Suggestions?

EDIT: So this is apparently more of a general KSP thing. If you install a mod that adds parts, the parts will not automatically be unlocked just because you already have that science node. You have to go back to that node in the tech tree, look at the parts window on the right, and then manually "research" each new part (it's free).

Edited November 2, 2013 by simmy2109

[DarthJazno]

Getting a very strange problem... trying to use these in my KSP career save, but the parts claim I don't have the science researched. Except that I do have Science Tech. Worse... I tried modifying the files to "TechRequired = start" but I still have the same problem. Suggestions?

Go to your tech tree and find the parts. They are in the middle somewhere. Click on the individual parts to make them available in the VAB. I think it's part of the future money or more research so you may have to "buy" or research each individual part.

[therealcrow999]

Look back through the thread..few of us are making replacement parts....

I got a set going, but work is kinda slow, on account that my daughter was real sick..and now I am lol...hate this time of year....

Couple others had mentioned workin on parts too.

Yeah I hear you, it's going around. I always get sick in spring after everyone else has spread it around, lol.

[SirJodelstein]

Great! Just tested it and must say that i am very happy to have a ISA Mapsat replacement that works better as the original. Multiple scanners simulatneos is incredibly useful, and the markers/orbital info pieces are a nice addon. Thanks a lot for making this!

I have one little suggestion for the magnified zoom window on the big map: The "click again to zoom in even more" feature works, but is somewhat painful to use if you want to go from 10x zoom (initial) to a much higher zoom like 50x or 100x, as i have to step through all of the small intermediate steps (12, 15, 19 and whatnot) . I don't know how the "next zoom step size" is calculated (guessing its something like "increase zoom by a factor of 1.25"), but i think such fine stepping is not really required. My suggestion would be to simplify this to a fixed stepping like 10x, 20x, 50x, 100x or to increase this factor to 2 or something like that. Also, it would be nice to let the user resize the zoom window or make its size somehow configurable.

As you can see, these are very minor issues, probably something to add to the bottom of the issue list. This is already a must-have in it's current form.

[drtedastro]

Not when they're on the same craft. Multiple sensors of the same type on the same craft should deliver exactly the same results as one sensor of that type.

Thanks for the reply. Any 'thoughts' on the ability to select to save data to work on post mission?

[damny]

Thanks for the reply. Any 'thoughts' on the ability to select to save data to work on post mission?

I've put it on my list, but there are some bits missing that I need to implement first, so it's not going to happen soon.

[drtedastro]

No worries. I appreciate that you are looking into doing it.... Thanks.

[damny]

I've uploaded build 3 here.

In this build, I removed the slope detection sensor. Instead, the slope view is now a feature of the altimetry sensors. This does NOT break save file compatibility: The part is still there, it just doesn't affect scanning anymore. If you want to get rid of it, you can make it explode from the right-click menu.

Can you spot all the other changes?

(The answer is "no", because some changes aren't visible...)

I'm still looking for performance feedback. In this build, the grid and markers have negligible impact and the performance hit from the ground track is much reduced.

Full changelog:

Names in () are forum names of people who suggested the feature/found the bug.

Build 3 - 2013-11-02
--------------------

- Map overlays are rendered in a more efficient way. (DMagic, OrtwinS)

- The polar orthographic projection doesn't choke on the antimeridian 
  anymore. (DMagic)

- Greyscale mode changes more colors to barrier free colors.

- The big map is now resizable and its size and position are saved in the 
  persistance file.

- Map markers now use the stock KSP icons, if applicable. (Sochin)

- More text has black outlines now to make it more readable.

- Map markers and the ground track are now visible in the zoom box. (Ortwins)

- Polar projection now displays handy S and N markers. (Thourion, OrtwinS)

- All parts now consume electrical charge. The amounts are not finalized yet
  but can be configured in the part.cfg files.

- Slope detection has been folded into altimetry. (OrtwinS)

- Existing slope sensors have become broken, and a small explosive charge has
  been activated remotely for your convenience. You can trigger it via the
  right-click menu to get rid of the part on existing vessels.

- If there are maneuver nodes on the active orbit during the time span for 
  which the ground track is rendered, the first maneuver node's position will
  be indicated on the ground track along with the ground track for one period
  of the resulting orbit.

- The GUI style should not flip between Unity and KSP style. (BananaDealer)

- Rendered maps are not exported automatically anymore. Instead, there's a
  button in the big map window that exports the current map without any of
  the overlays. Exported images are still saved in the same location. (MOARdV)

- Flags are now visible on the map.

- Double clicking a ship name in the small window now switches to that ship.

- The vessel list in the small window can now be toggled, and the window can
  be minimized to an icon only. (OrtwinS)

[drtedastro]

Good stuff, checking it out now. Thanks.

[TelluriumCrystal]

Very nice work!

I have only one criticism: The little x symbol's asymmetry annoys me a bit. I don't suppose you could change it to a regular x (or maybe a + or • or even a º)?