[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[Nibb31]

I'm adding part modules to the AIES pack parts to use them as sensors and to get them into the tech tree and I've noticed that the sensorType value seems to be binary. Is it safe to assume that sensorType = 3 will scan both altimetry and advanced altimetry data ? Is there even any point in collecting both? Will a sensorType = 63 combine all sensor types in a single part?

[Gryphorim]

I think I have found a bug, I'm getting no data other than sattelite position on my map regardless of which antennas I'm using. I think it may be a clash with BoulderCo city lights and clouds. Can anyone confirm or debunk??

[Thourion]

@Nibb31: Dunno if thats any help, but if you open the KSP debug screen then you toggle a part in flight, it shows the sensor type it uses. Im not 100% sure i think i saw the 63 on one of the parts ...

@Anyone Else: Anybody have a workaround for the hidden map after ship switch, that doesnt require Restart of the game? Until damny fixes it i mean.

[sirkut]

What colors are HI, LO, etc on the map?

[damny]

Is it safe to assume that sensorType = 3 will scan both altimetry and advanced altimetry data ?

It's at least what's supposed to happen.

Is there even any point in collecting both?

The low resolution scan has a larger field of view, so you can prioritize time over accuracy. Also important if your orbit is not ideal for mapping.

I might make the difference larger in the future. The next build will make finding good orbits significantly easier, so I might have to balance this in some way by making it more important to have a good orbit for the more interesting sensors.

Will a sensorType = 63 combine all sensor types in a single part?

All existing ones. I think it'll record coverage for 64 and 128 too, those just don't do anything yet.

[Thourion]

What colors are HI, LO, etc on the map?

Is this what you mean?

...Green means there's data of that particular type, grey means there's no data of that type, and red means there would be data if the game had that kind of data...

--------------------------------------------------------

... I might make the difference larger in the future...

Yeah please do so. At this point the difference is really small.

Edited October 31, 2013 by Thourion

[sirkut]

Yes, I was curious if any of the satellites were enabled based on the orbit. The only time a map wouldn't generate is if my altitude was wrong.

[MOARdV]

I think I have found a bug, I'm getting no data other than sattelite position on my map regardless of which antennas I'm using. I think it may be a clash with BoulderCo city lights and clouds. Can anyone confirm or debunk??

With BoulderCo C&L Alpha-10, I can debunk. I was both yesterday. I have not looked at the Beta-1 yet - that'll be in an hour or so, after my son goes to school and before I need to show up at work.

[kahlzun]

no data will appear if above 500 km

[OrtwinS]

I think I have found a bug, I'm getting no data other than sattelite position on my map regardless of which antennas I'm using. I think it may be a clash with BoulderCo city lights and clouds. Can anyone confirm or debunk??

no data will appear if above 500 km

I think these two might be related.

[damny]

I posted build 2 here (different URL, so the old file is still available if the new one is broken).

This build fixes a few bugs, hopefully including the one where you'd lose the UI completely until a restart of KSP when switching vessels in map view.

This build also introduces alternative map projections and toggle-able grid and ground track overlays for the big map. I completely don't trust my math on these (well, I guess the grid is probably okay) so please do double check. The overlays have a noticeable impact on performance on slower systems. I'm also looking for feedback on that.

In addition to the ground track, the orbit overlay also displays funny markers on the equator. These are predicted equatorial crossings. If they look like this, you are having a bad problem and won't be making a good map that day:

Full changelog:

Build 2 - 20013-10-30
---------------------

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

- BTDT scanner now correctly works when the vessel is below 2000m above ground,
  instead of when the anomaly is below 2000m above sea level. (DMagic)

- Main UI now correctly shows the altitude of the vessel above ground, instead 
  of the terrain elevation above sea level below the vessel.

- Big map mouseover text now displays latitude and longitude in the correct 
  order. (DMagic)

- Geographical coordinates are now displayed in DMS. (Sochin, GhostChaser)

- Left-clicking inside the zoom box now zooms back out. (OrtwinS)

- Big map now shows a projection of the active vessel's current orbit from one
  orbital period in the past to one orbital period in the future. (Sochin)

- Big map now shows predicted equatorial crossings for the next few dozen orbits.

- Big map can now be rendered using the Kavrayskiy VII projection. (OrtwinS)

- Big map can now be rendered using a Polar Orthographic projection. (OrtwinS)

- A red scanning line indicates big map rendering progress. (Thourion)

- When using greyscale, text labels are displayed in cyan and orange. (sharpspoonful)

- Text labels on maps now have a black outline. (OrtwinS)

- The UI doesn't go AWOL anymore if you switch vessels in map view. (Tutman, DMagic)

- The small map doesn't paint elevations <-1500m red in greyscale mode anymore.

- Areas not covered by all active sensors on your active vessel now appear
  darker on the small map. 

- There's a switchable dot line grid on the big map. (OrtwinS)

- Map markers can be toggled in big map. (DMagic, OrtwinS)

- The zoom box acquired a close button. (Ralathon, DMagic, OrtwinS)

[Thourion]

Yessir! ...theres goes my whole day, along with this and next months supply of coffee and cigarettes.

Downloading and Diving straight away.

[rosenkranz]

This looks good. Looking forward to this greatly.

As to the science bit, scanning a planet could generate dangerous amounts if not done right. Diminishing returns is likely key. You'd get most of the science pool by 30% complete and pretty much all of it by 70%. The last 30% you do because you're a completionist

[Gristle]

This looks good. Looking forward to this greatly.

As to the science bit, scanning a planet could generate dangerous amounts if not done right. Diminishing returns is likely key. You'd get most of the science pool by 30% complete and pretty much all of it by 70%. The last 30% you do because you're a completionist

What if you made it so that creating the maps doesn't generate science directly (or a smallish amount) but are prerequisites for other other science. For example you need to have at least 80% of a slope map complete before Kerbin scientist would have enough data to identify impact craters on Kerbin.

[DMagic]

Seems good so far. The map UI doesn't disappear anymore and the BTDT scanner seems to be working right. The improvements to the big map and the different projections are great, too.

The performance impact from the overlays are pretty significant for me (on an i5 4200U at 2.3GHz; I'll test my desktop later). The grid knocks me down from 60 to 30FPS, and the orbit projection knocks me down to 40FPS. With both of them on I'm down to about 25FPS. The anomaly markers have no effect. Changing map type, color, or projection type doesn't have any effect on performance.

Edit:

I did find one problem. A completed map on the polar projection has a small gap running up from the center of the north pole, and down from the center of the south pole. I'm not sure how easy this is to see, but it's pretty clear in-game.

Edited October 31, 2013 by DMagic

[Thourion]

... The overlays have a noticeable impact on performance on slower systems. I'm also looking for feedback on that...

Well on a Core2Duo with 5gigs ram and a gforce 9600gt, somewhat oldish system with today's standards, the frame rate drops much, not crazy down the drain but yeah. I can imagine if by chance you have the non-scanning part, installed in a big ship you fly, just to be able to keep scanning with the others, its gonna rain lag.

On the other hand, just by hiding the orbit and grid, you go like you dont have this mod installed.

The render on the big map, seems to lag the game a bit, (you can feel it more with Orbit and Grid ON), but full render doesnt last long so i dont think its a big problem. Also you happen to have this huge beautifull map in view, you dont even pay attention to the game fps-jiggling through the render process.

So in the end, im not in any rush for optimization of the mod at this point, meaning if you got other stuff to do, i dont mind at all to give them priority imho.

Final word, i already said my pc specs, add to that a heavy list of other mods installed as well in the above playthrough of scansat, all feels good.

PS. The orbit lines, eq crossings, the text display along of course with the fix for the UI bug = I need a new set of pants, already have 2 wet

Only thing that comes to mind right now (other than sending probes all over the system), is some way, like a dot, on the small map to show anomalies, so you dont have to keep the big one open when guiding a plane for example.

[Thourion]

I did find one problem. A completed map on the polar projection has a small gap running up from the center of the north pole, and down from the center of the south pole. I'm not sure how easy this is to see, but it's pretty clear in-game...

Hmm i thought it was some indicator on which ball is North which is South lol.. or is it?

[OrtwinS]

Hmm i thought it was some indicator on which ball is North which is South lol.. or is it?

Good point, maybe a big 'N' and 'S' in at the top left of both maps will make that more obvious. (or perhaps 'NP' and 'SP').

I find it curious that a simple grid has such a performance impact. Is it actively overriding some part of the map render mechanism?

Isn't it just a static piece of the UI that is layered above the map?

And damny, thanks for crediting us! (I have a score of 7/18 :P)

[damny]

With both of them on I'm down to about 25FPS. The anomaly markers have no effect.

The anomaly markers are probably not a very big deal since there's so few of them and they don't involve a lot of calculation.

Changing map type, color, or projection type doesn't have any effect on performance.

Actually I'd expect that the non-rectangular projections render slightly faster because they show less data (non-clear pixels).

A completed map on the polar projection has a small gap running up from the center of the north pole, and down from the center of the south pole. I'm not sure how easy this is to see, but it's pretty clear in-game.

Now that you point it out, it's indeed easy to see... it's unfortunately not supposed to be an indicator for which side is which Apparently my projection inverse is undefined for the antimeridian (180° longitude), and I totally didn't see that. I did tweak the size of those circles a bit in the last minute...

I can imagine if by chance you have the non-scanning part, installed in a big ship you fly, just to be able to keep scanning with the others, its gonna rain lag.

It shouldn't affect performance at all if the big map isn't actually open.

So in the end, im not in any rush for optimization of the mod at this point, meaning if you got other stuff to do, i dont mind at all to give them priority imho.

It's not so much missing optimization. I definitely expect to stop drawing lines by rendering them as text at some point It's just so convenient for prototyping...

I find it curious that a simple grid has such a performance impact. Is it actively overriding some part of the map render mechanism?

Isn't it just a static piece of the UI that is layered above the map?

It's a lot of little dots that are rendered as text on top of the map each frame. See above... someone said I should release often

[DMagic]

Actually I'd expect that the non-rectangular projections render slightly faster because they show less data (non-clear pixels).

The non-rectangular maps definitely render faster, the polar especially. I was referring to the effect of the grid/orbit overlays; the performance drop is the same regardless of which projection the markers are shown on (which isn't exactly surprising, I just wanted to make sure).

[OrtwinS]

-snip-

It's a lot of little dots that are rendered as text on top of the map each frame. See above... someone said I should release often

Haha, yes . And I love it.

• Render the grid as something else than text every frame (a mostly-transparant overlay image? Or make the points a part of the GUI window?) disclaimer: I jest!
  
• GUI display options: minimize (icon only, scanning still active), compact (minimap only) and full size (minimap + vessel list). The big map is still a separate window.
  

Not much of a list, I came up with a dozen more things, but we all covered those in previous posts.

Edited October 31, 2013 by OrtwinS

[BananaDealer]

So I just set-up my first orbiter around Duna after a successful Polar Lander re-enactment. Two of them actually (both of them successful, had to scap the first orbiter), but that's a different story... I gotta say, this mapping thing is impressive! I only had the grayscale altimeter scanner since I like to pretend progression but even that's cool!

Anyways, is the change from old to new style GUI in warp/non-warp an intended feature or just a pesky glitch?

[damny]

Anyways, is the change from old to new style GUI in warp/non-warp an intended feature or just a pesky glitch?

In warp? I only noticed it switching to KSP style when you pause.

[OrtwinS]

A little story about the Kavrayskiy VII projection.

When I originally suggested a non-rectangular projection, I went to Wikipedia (list of projections) and picked the first non-rectangular projection available (Molweide). This one was still a little weird around the poles, and distorted higher latitudes quite a bit, so I picked the next non-weird one: Kavrayski VII.

I quickly edited the post, and added it.

Some reading up on projections later, I find out that there are several other more regular used projections (Robinson and Winkel-Tripel mostly, and Wagner VI, which is actually Kavrayski VII slightly compressed).

Turns out Kavrayski VII seems to be the best solution for us. The straight parallel latitudes keep navigation still doable, and it can be generated with a relative simple formula.

Robinson uses an arbitrary table (generation by interpolation, boy it's a mess). And Winkel curves the latitude as well, which might be more visually pleasing but makes is near useless for actual use (which we intend, right?).

Kavrayski VII is a projection used in the former Soviet Union, and knowing politics it has been completely ignored in 'our' world despite being quite usefull.

And now, we're using it .

PS, if we care about less deformation around the equator, and care less about the poles, Wagner VI is still an option. But the difference is marginal. And I don't think more or different projections should have any priority now. I just wanted to share a story.

[sirkut]

Would be nice one day to be able to zoom in on a particular grid and have a small 3d window preview that you can rotate around to get a real sense of a place to land.