[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[technogeeky]

DMagic: I discovered another bug. It went something like:

1. Have a partial scanned map of Kerbin. (SAR, in this case)

2. Open BigMap on Kerbin, render.

3. (Cheat) Set Orbit to 15,000 km @ Mun.

4. Without resizing map, render map.

The partial scan map of Kerbin is sitting on top of the map of the Mun. Resizing the map gets rid of this bug.

[technogeeky]

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 updated my post to reflect that I figured out what you meant, and made the changes. All of the parts have appropriate VAB and Flight entries.

I don't have a reference for performance in RPM, but I could look at that later. I am looking at the orbit as we speak.

[technogeeky]

I was not able to see any problems with the orbital tracks in ssRPM being wrong. My capsule landed exactly where the track ended:

- - - Updated - - -

However, I did find a problem: After opening the Big Map, and clicking trying to turn Orbits on/off while it was redrawing, I was unable to re-open the Big Map at all.

I don't have exact steps to replicate, but it is more serious.

[technogeeky]

DMagic:

I have updated my master with the changes from above.

I'd like to figure why I was having trouble opening the Big Map, but I have to go back to work.

And yes, I'm using the ALCOR capsule. There are several different displays, all of different sizes.

I expect that is the source of part of the problem: SCANsat expects a fixed (and certain) aspect ratio; and these RPM map instances seem to ignore this principle.

Note the re-ordering of the logic in OnInitialize(): first, scanners with scanNames are dealt with (all of them, but MapTraq has is an Eyeball scanner in the part.cfg); then, MapTraq has the labels rewritten and the analyze actions/events removed; then, BTDT has the analyze events/actions removed.

Until tonight...

Edited May 14, 2014 by technogeeky

[DMagic]

DMagic: I discovered another bug. It went something like:

1. Have a partial scanned map of Kerbin. (SAR, in this case)

2. Open BigMap on Kerbin, render.

3. (Cheat) Set Orbit to 15,000 km @ Mun.

4. Without resizing map, render map.

The partial scan map of Kerbin is sitting on top of the map of the Mun. Resizing the map gets rid of this bug.

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.

Edited May 14, 2014 by DMagic

[technogeeky]

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.

The problem was that I couldn't open the big map again after closing it.

[DMagic]

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).

[technogeeky]

<-- back at work tonight.

Any updates? The only bug I intend to investigate before publishing the final v6 is the bigmap-button-breaking one I mentioned.

edit: I wonder why every pull request has so many commits. It's probably something I'm doing.

[DMagic]

<-- back at work tonight.

Any updates? The only bug I intend to investigate before publishing the final v6 is the bigmap-button-breaking one I mentioned.

edit: I wonder why every pull request has so many commits. It's probably something I'm doing.

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.

Edited May 15, 2014 by DMagic

[technogeeky]

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.

Excellent.

And re: caching in RPM -- I don't buy it. First, one cache set (the one RPM would need if constantly re-centering) is just a translation of the existing cache set (modulo map size). In theory you might not need to store any additional information, but you can probably do it with an x and y offset, and/or four cutoffs. (or not: cache parts of the map that aren't currently visible in RPM, who cares)

And if not that, you can just cache something else. The

I plan to work quite diligently on performance upgrades this upcoming week. We're going to need it, especially as we introduce more and more overlays (for resources, for N future orbits (to check for a resonant orbit closure/non-closure), for a higher density of orbit information, etc.

By far the most intimidating thing that I intend to try is to breakup the redline-drawing process so that each box in the grid is drawn independently. This way, not only will we cache the parts of the map that aren't changing -- we won't even try to update the parts of the map which could not have changed.

[DMagic]

And re: caching in RPM -- I don't buy it. First, one cache set (the one RPM would need if constantly re-centering) is just a translation of the existing cache set (modulo map size). In theory you might not need to store any additional information, but you can probably do it with an x and y offset, and/or four cutoffs. (or not: cache parts of the map that aren't currently visible in RPM, who cares)

Storing the entire map and only displaying part of it crossed my mind, but I didn't think about sharing the cache with the regular big map. That's worth looking into.

And playing around with the RPM .cfg files I think the IVA maps can reasonably be shrunk a little bit without really sacrificing quality. Some of these maps are really big, the rectangular one in particular is poorly handled and ends up taking much more time than in should to render.

[technogeeky]

Storing the entire map and only displaying part of it crossed my mind, but I didn't think about sharing the cache with the regular big map. That's worth looking into.

And playing around with the RPM .cfg files I think the IVA maps can reasonably be shrunk a little bit without really sacrificing quality. Some of these maps are really big, the rectangular one in particular is poorly handled and ends up taking much more time than in should to render.

OK. I was surprised at how many LOC ssRPM is. I bet there is a lot of opportunity for code re-use by changing only small things in SCANsat.

Anyway, my vacation week has begun. So I hope I can be quite productive.

DMagic: are you reachable on IRC? Or, could you become so? It might be helpful to have even faster communication/response this week.

[DMagic]

OK. I was surprised at how many LOC ssRPM is. I bet there is a lot of opportunity for code re-use by changing only small things in SCANsat.

Anyway, my vacation week has begun. So I hope I can be quite productive.

DMagic: are you reachable on IRC? Or, could you become so? It might be helpful to have even faster communication/response this week.

I should have lots of time this weekend. I'll get on KSPModders by then.

[technogeeky]

I'm doing some of the more tedious stuff (but stuff that must be done to put this project in Showcase).

Behold, some images and gifs:

THE BIG MAP

Javascript is disabled. View full album

THE SMALL MAP

Javascript is disabled. View full album

THE PARTS (AND VAB DESCRIPTIONS)

Javascript is disabled. View full album

PART ANIMATIONS

Javascript is disabled. View full album

PART ACTIONS

Javascript is disabled. View full album

I actually had a bigmap animation going from 0% coverage to 100% coverage at 10,000x -- but the GIF was larger than 2MB which is evidently the limit at imgur. Oh well, I'll have to do it again.

I intend to also grab ssRPM-related screenshots (probably none animated, but maybe).Any thoughts? Additions?

[hawk_za]

to all involved

just small MSG to say a massive thank you continuing this project and renewing its capabilities as it truly is, in my opinion, one of the better plug ins for ksp that expands on playability and content

i recently spoke to the devs with regard to integrating it into the main game and mailed the forum moderator at squad this was his reply i will post my original mail as well

Re: intergrating exsisting pluginns into ksp

Quote Originally Posted by hawk_za

hi there im sure you are a busy man and ill try to keep this brief

i recently made a post on the forums

http://forum.kerbalspaceprogram.com/...-stock-version

with regard to integrating the damny mapsat mod into ksp default game structure and listed about 6 points as to the logic behind this in the hopes of the developers reading it but am currently unsure if even that has happened, as i know how busy you guys must be with the work for patch .24

so im hoping sending you the above link in the hopes that as community manager you might bring this idea to the developers attention as it seems to me that this is somthing much of the community is baying for.

i vaguely remember on a video that the dev team did make a stance on not incorporating mods into the game and would like to further inquire if this stance would ever change.

yours in service

Hawk_za

Hi, Hawk. How's everything? At this time, the devs have no intention to directly integrate mods that have been created by members of the community. However, if it gains enough community backing, I can certainly notify them as to the types of features that people would like to see in future updates. Thanks!

SO i was thinking about creating a poll to see if indeed there is enough community interest in having this in the current game what is your ideas on this

ps just downloaded v.6 and now going to try test it will post on any relevant feedback i find

[hawk_za]

okay just finished scanning with version 6 and it appears the low resolution grey altimeter rectangular and the low resolution grey slope rectangular maps have been mixed up i scanned kerbin but got dunas scans

that's all the relevant feed back i have for now will re post if i find other stuffs hope this helps :>

Edited May 16, 2014 by hawk_za

[hawk_za]

okay after a reset of all data i thought i was being an idiot as kerbin was appearing fine till i moved over to my duna satellite an i got the below image

as you can see on the big map the duna map appears below a set kerbin map

p.s when downloaded the v6 had 2 directories that i pasted in the ksp game data directory a scan sat directory and a SCANsatRPM directory

could this be causing my issues if so i apologize in advance for my stupidity.

Edited May 16, 2014 by hawk_za

[hawk_za]

okay after deleting the SCANsatRPM directory and restarting ksp and resetting all map data the big map is still not behaving and is seems to get confused as to which overlay to use.

hope this feedback is of use

Edited May 16, 2014 by hawk_za

[CaptRobau]

Would it be possible to project the SCANSat map on the planet/moon itself à la Kethane's resources hexes? So that it looks something like this:

This would be the holy grail of displaying data like this.

[phoenix_ca]

Would it be possible to project the SCANSat map on the planet/moon itself à la Kethane's resources hexes? So that it looks something like this:

http://i6.minus.com/ibr3bkILyjrhpf.png

This would be the holy grail of displaying data like this.

I will sacrifice as many kerbals as is necessary to make that a reality.

[KerbMav]

If you are not yet tired of new features, how about an orbit projection option that shows the orbit where the craft will be taking into account the body's rotation, so you can plan deorbit burns to determine the landing zone in specific locations.

[hawk_za]

okay tried scansat with the toolbar 1.7.1 and found that it dose not seem to be compatible icon don't appear and neither do the maps

this is after testing toolbar with mechjeb chatterer and kerbal engineer redux hope again this is of use

[DMagic]

okay after deleting the SCANsatRPM directory and restarting ksp and resetting all map data the big map is still not behaving and is seems to get confused as to which overlay to use.

This is a known bug and has already been fixed. For now you just have to reset the big map by changing the size a little bit (drag the little # icon on the bottom right).

SCANsatRPM is used by Raster Prop Monitor, if you don't have RPM installed SCANsatRPM won't do anything, the SCANsatRPM.dll plugin should fail to load.

Are you configuring the toolbar after installing SCANsat v6? Are there options for the SCANsat buttons available, but without icons, or does nothing show up? Is SCANsat placed in the right location? The icons won't load if it isn't in the right place: Kerbal Space Program/GameData/SCANsat/

[LameLefty]

Would it be possible to project the SCANSat map on the planet/moon itself à la Kethane's resources hexes? So that it looks something like this:

(SNIPPED)

This would be the holy grail of displaying data like this.

Oh dear Baby Jebus, make this happen gentlemen, please. The future of the Kerbal race depends on it.

[hawk_za]

This is a known bug and has already been fixed. For now you just have to reset the big map by changing the size a little bit (drag the little # icon on the bottom right).

SCANsatRPM is used by Raster Prop Monitor, if you don't have RPM installed SCANsatRPM won't do anything, the SCANsatRPM.dll plugin should fail to load.

Are you configuring the toolbar after installing SCANsat v6? Are there options for the SCANsat buttons available, but without icons, or does nothing show up? Is SCANsat placed in the right location? The icons won't load if it isn't in the right place: Kerbal Space Program/GameData/SCANsat/

hey wow thanks for the amazingly fast response good to hear of the fix i will try the resize trick and see if it works for me also as for scan-sat as i go into the config window and select the scan sat icons to be displayed toolbar plugin and scan sat completely disappear however in map mode the toolbar plugin is still there and all other plugins work with the exception of scan sat again will post relevent feedback as soon as testing is done hope this helps as i really am glad to contribute to the growth of scan sat in any way possible