[0.24.2]MapResourceOverlay for Science,Karbonite/MKS and biomes VERSION 0.2.7

[Cyrik]

new release is out. ors is now optional and version independent, unless it changes a very specific part of its API.

otherwise the science overlay was extended but still slow:/

there are now 2 configs: Base.cfg shouldn't be touched. this is where i change the starting config. if you touch it, it will get overwritten in the next release. MapResourceOverlay is the config that you can change by hand or ingame. it wont get overwritten in new releases, hopefully:)

poll: should i work on the ui, making the science overlay better, giving more options to tweak or adding more overlay types?

[Cyrik]

not that anyone doesn't use blitzy's toolbar, but the next version will be independent of it, yay:)

+ i´m using CaptRobaus new icons.

working on getting science overlays to load faster for now, until someone tells me to do something different:P

[Alvin853]

Is the color intensity of the resource overlay maxed at 255ppm? Because that's not really all that much, I set my cutoff to 500ppm or even 1000, and then only get solid colored spots. Would be helpful if that could somehow depend on the cutoff so I can still see optimal/suboptimal locations without having to change the cutoff all the time.

[Cyrik]

Is the color intensity of the resource overlay maxed at 255ppm? Because that's not really all that much, I set my cutoff to 500ppm or even 1000, and then only get solid colored spots. Would be helpful if that could somehow depend on the cutoff so I can still see optimal/suboptimal locations without having to change the cutoff all the time.

right now it is, mostly because i havent found a good way to find the max or average value for a resource. i´ll try just running through it twice to see if it slows down too much, if it does i´ll have to build a config file for every planet/resource combination

[Alvin853]

i´ll have to build a config file for every planet/resource combination

All the Karbonite/MKS configs use logarithmic scaling, you can probably use that knowledge to make a more general rule. Maybe something like: cutoff -> 0% color, 2x cutoff -> 10%, 4x -> 20%, 8x ->30%... 1024x ->100%

This would cover 3 orders of magnitude, set the cutoff at 10ppm and you can differentiate up to 10240ppm on the overlay before reaching saturation. That's actually maybe a bit too much, about 2 or 2.5 orders of magnitude would be great. RoverDude might be able to help you with this, since that's how the resource maps are initialized, with a .png that has a range from 0 to 255 for each square on the map.

edit: basically what I want: revert the process of going from 0-255 to a ppm value, but maybe to a higher range, and then dynamically take x-(x+255) range depending on what the user sets the cutoff (x)

Edited September 2, 2014 by Alvin853

[Cyrik]

All the Karbonite/MKS configs use logarithmic scaling, you can probably use that knowledge to make a more general rule. Maybe something like: cutoff -> 0% color, 2x cutoff -> 10%, 4x -> 20%, 8x ->30%... 1024x ->100%

This would cover 3 orders of magnitude, set the cutoff at 10ppm and you can differentiate up to 10240ppm on the overlay before reaching saturation. That's actually maybe a bit too much, about 2 or 2.5 orders of magnitude would be great. RoverDude might be able to help you with this, since that's how the resource maps are initialized, with a .png that has a range from 0 to 255 for each square on the map.

edit: basically what I want: revert the process of going from 0-255 to a ppm value, but maybe to a higher range, and then dynamically take x-(x+255) range depending on what the user sets the cutoff (x)

ok soooo, its not actually that slow to run through the map once and finding the highest value:)

next version you will have 2 options: colors linearly scaled from 0-255 starting at the cutoff. so 0 would be the cutoff and so on. second option would be to logarithmicly scale it from 0-255 starting at cutoff.

hope this helps everyone, otherwise i´ll throw more stuff in there:)

[Cyrik]

ok, i´m dead and going to bed, but first you get a new vesion:

science overlay is now way faster, so its actually usable without going crazy

3 different scalings for resources, try them, tell me if you like em:)

[JedTech]

This really adds to Karbonite and Scansat. Thanks so much!

[gh7531]

Wow the speed has increased an awesome lot! Good work Cyrik.

- I figured out that the orbit/overlay glitch I mentioned earlier only happens while selectet the resource overlay.

- Also you are able the select both Logarithmic and Colored Scale at the same time. I think this is not intended?

- While selctet Logarithmic Scale and cutof ppm is at 0 it shows nothing. I don't know how you implemeted it but at 0 should't it show everything? If you set it to 1 or something else it shows as intended I think

- It would be nice if you can make it visible which button is currently active. Like underline the text in the button or make the button looking "pressed" (If you know what I mean ^^)

- I found a smal shifting between the position of the courser at the overlay and the shown ppm in the tooltipp. I don't know if you are able to fix it. It's probably releated to the angle you look at the overlay.

(You can't see the curser actualy I don't know how to get it on the screenshot but you can imagine where it was. And there shouldn't be a ppm of 3000. I think the 3000 are at the spot 1cm to the lower right)

- And I have a suggestion too. I think it make sense to only make the tooltipp visible when the curser is above an actual point where the amount of something is above the cutoff value. So the tooltipp shows only if important and you don't need to enanble and disable it.

- I think someone suggested it earlier im not sure. But a independed cutoff value for each resource would be nice. At minmus as example the ppm difference between water and minerals are realy huge

- If possible a marker for anomalies like ScanSat has would be realy nice too.

[RoverDude]

Poking in to say that this mod is fractally awesome.

[Cyrik]

Wow the speed has increased an awesome lot! Good work Cyrik.

- I figured out that the orbit/overlay glitch I mentioned earlier only happens while selectet the resource overlay.

- Also you are able the select both Logarithmic and Colored Scale at the same time. I think this is not intended?

- While selctet Logarithmic Scale and cutof ppm is at 0 it shows nothing. I don't know how you implemeted it but at 0 should't it show everything? If you set it to 1 or something else it shows as intended I think

- It would be nice if you can make it visible which button is currently active. Like underline the text in the button or make the button looking "pressed" (If you know what I mean ^^)

- I found a smal shifting between the position of the courser at the overlay and the shown ppm in the tooltipp. I don't know if you are able to fix it. It's probably releated to the angle you look at the overlay.

https://dl.dropboxusercontent.com/u/30637586/KSPForum/position.jpg

(You can't see the curser actualy I don't know how to get it on the screenshot but you can imagine where it was. And there shouldn't be a ppm of 3000. I think the 3000 are at the spot 1cm to the lower right)

- And I have a suggestion too. I think it make sense to only make the tooltipp visible when the curser is above an actual point where the amount of something is above the cutoff value. So the tooltipp shows only if important and you don't need to enanble and disable it.

- I think someone suggested it earlier im not sure. But a independed cutoff value for each resource would be nice. At minmus as example the ppm difference between water and minerals are realy huge

- If possible a marker for anomalies like ScanSat has would be realy nice too.

great feedback, thank you for the effort!

now to your specific points:

- i will look into the orbit/overlay thing today. i´m not sure if its fixable. might have to lower the alpha so that you can see through:/

- its intended for both to be active at the same time, i just forgot to make them interact in that case:)

- log(0) gives explosions:) gonna fix that

- more visual feedback on the buttons incoming next update, just for you:)

- yeah the displacement is a visual thing:/ the tooltip gives you the exact mouse coordinate at the planet, the overlay is a bit higher, depending on the highest mountain. not sure what to do about that. i could make the tooltip depend on the overlay sphere instead of the planet, but i´d rather keep it as accurate as possible. if anyone has ideas for a fix, i´m open to them!

- nearly forgot: tooltip disabled below cutoff. would need more peoples feedback on this. i like that i can always check with the tooltip, even if its below the cutoff, then again, i havent played the game since i started modding...

- yes, someone suggested it, but its good to remind me. i sometimes forget feature request. if i dont say no to a request just poke me once in a while so i dont forget. or even better, make an issue on github so i have to deal with it:)

- yes, i can make an anomalies overlay. not sure if i want to, since the scansat one better looking then an overlay would be, but i might as well throw it in for people who dont use scansat

Poking in to say that this mod is fractally awesome.

thank you! even if i had to google fractally

while i´m at it: the colored scale goes through these colors:

xkcd_ArmyGreen,

xkcd_Yellow,

xkcd_Red,

xkcd_Magenta,

xkcd_White,

xkcd_White

if you have a better idea, let me know. this one has been stolen from scansat

Edited September 2, 2014 by Cyrik

[gh7531]

more visual feedback on the buttons incoming next update, just for you:)

- Also I got another Idea while playing around but I don't know if it's possible since it woks with an complete other mod... mabye you know the spacetelescopes from "Tarsier Space Technology"?

(http://forum.kerbalspaceprogram.com/threads/62941-v0-23-5-Tarsier-Space-Technology-%28v2-5-NO-MORE-WOBBLE%29) Probably it would be a nice gimmick to make it possible to point the teleskope in a HighOrbit at the plantet, zoom a little bit in, take a picture and get the part on the picture visible at the overlay as a hight map and if implemented anomaly and slope overlay?

- Also while I'm writing this adding maby a slope overlay?

[Cyrik]

- Also I got another Idea while playing around but I don't know if it's possible since it woks with an complete other mod... mabye you know the spacetelescopes from "Tarsier Space Technology"?

(http://forum.kerbalspaceprogram.com/threads/62941-v0-23-5-Tarsier-Space-Technology-%28v2-5-NO-MORE-WOBBLE%29) Probably it would be a nice gimmick to make it possible to point the teleskope in a HighOrbit at the plantet, zoom a little bit in, take a picture and get the part on the picture visible at the overlay as a hight map and if implemented anomaly and slope overlay?

- Also while I'm writing this adding maby a slope overlay?

ouch, your first idea is possible, but a lot of work. mostly because right now i can only display colors on the overlay, not textures. if i ever get around to putting textures on it for a feature that more people would use () you can bring it up again. then it would only be a matter of seeing if the mod in question has a decent interface to get at it.

slope overlay is something i want to build anyway. its just a bit more complicated since there is no api for it and i dont want a hard dependency on scansat. i´ll see how scansat builds its slope map, but the feature is not very high on the priorities list, since it would be more of a gimmick then actually useful for the game:)

[gh7531]

ouch, your first idea is possible, but a lot of work. mostly because right now i can only display colors on the overlay, not textures. if i ever get around to putting textures on it for a feature that more people would use () you can bring it up again. then it would only be a matter of seeing if the mod in question has a decent interface to get at it.

I'm sorry I think I didn't describe what I mean good enough English isn't my first speech

I mean somthing like this.

1. You get a satelite in an high orbit around Duna (as example).

2. You ponit you telescope at the planet.

3. You press Take Picture like in the first pic.

4. Now you can see the sector of the picture you taken as overlay like in the second one.

But as you said it is probably way to hard to implement and it would realy only be a tiny tiny thing. It's maby a thing after the final release of this mod. But actualy it is as not important and most likely it wouldn't be woth the afford of work on it it was just a think that flew around in my mind before thinking about the actual use of it ^^ It would only be another way to scan the planet.

Just concetrate on the GUI and the science overlay. And keep the work going on I realy hope this will be the future of scanning and showing the results in an easy to use way it has (I can't say it to often) a feaking awesome amount of potential.

Soo enough of the nice words I have another suggestion that flew around my head

- A way of "overlapping" the overlays would be nice. So that you can see the Karbonite hotspots at the resource overlay and also see where a nice flat place to land would be at the height or the slope overlay. OR so that you can see a place with a lot of Karbonite and a lot of Water for the lifesystem at your mining base for example.

[Cyrik]

Ok since there i no more feedback, I guess I´m done with this mod.

Just kidding, theres a new release with an anomaly overlay and individual cutoffs for resources and lots of small stuff.

Seriously though, i need some feedback to know what I should prioritize.

[RoverDude]

Ok since there i no more feedback, I guess I´m done with this mod.

Just kidding, theres a new release with an anomaly overlay and individual cutoffs for resources and lots of small stuff.

Seriously though, i need some feedback to know what I should prioritize.

I'm still absorbing what you already have

Actually... I do have an idea for a killer feature. Follow me with this.

So one of the issues is finding a good spot to mine. What if your filter had two sliders... PPM and slope angle. So you could figure out the ideal local based on that combination of factors.

(Edit)

Also - if you want another idea for an amazing mod let me know (this one doesn't use any graphics this time - I promise!) Had a huge spark of inspiration and as you can guess, I have more ideas than time

Edited September 3, 2014 by RoverDude

[Cyrik]

I'm still absorbing what you already have

Actually... I do have an idea for a killer feature. Follow me with this.

So one of the issues is finding a good spot to mine. What if your filter had two sliders... PPM and slope angle. So you could figure out the ideal local based on that combination of factors.

(Edit)

Also - if you want another idea for an amazing mod let me know (this one doesn't use any graphics this time - I promise!) Had a huge spark of inspiration and as you can guess, I have more ideas than time

sounds like a good idea. I´ll start working on the slopes overlay first since it would be needed anyway and has already been requested

[DMagic]

sounds like a good idea. I´ll start working on the slopes overlay first since it would be needed anyway and has already been requested

Any ideas on how to actually calculate slope? This is a tough one, since there is no "slope" field for a given location, all you can do is look at a location and look at the surrounding area. So your slope map is only as good as your height map. And to get a good, granular slope map means having a very high resolution height map, which kills performance (at least if you're trying to do it for the entire planet). This is why I think SCANsat's slope map is fairly useless, you have to zoom in very far to get any realistic idea of how flat an area is.

I was thinking that adding the slope to the tooltips might be easier, just look at the terrain elevation for the exact point where the mouse cursor is and compare it to several points very close by, then you're only dealing with a dozen or so terrain elevation calculations.

[RoverDude]

Or is it something where you do the heavy lifting offline and identify (in largish chunks) areas that are (relatively) flat, then this becomes a toggleable overlay

[Cyrik]

Any ideas on how to actually calculate slope? This is a tough one, since there is no "slope" field for a given location, all you can do is look at a location and look at the surrounding area. So your slope map is only as good as your height map. And to get a good, granular slope map means having a very high resolution height map, which kills performance (at least if you're trying to do it for the entire planet). This is why I think SCANsat's slope map is fairly useless, you have to zoom in very far to get any realistic idea of how flat an area is.

I was thinking that adding the slope to the tooltips might be easier, just look at the terrain elevation for the exact point where the mouse cursor is and compare it to several points very close by, then you're only dealing with a dozen or so terrain elevation calculations.

I´ve got the first version working. And you are right, there's problems with it, but i think its still kind of useful.

You don't actually need a height map before hand, since this "body.pqsController.GetSurfaceHeight(rad)" gives you a decent value for any point on the surface. Well I guess you could say that is the height map:)

Anyway, in my first attempt i´m calculating the slope for every lat/long by taking a measurement 0,5 lat/long in 4 directions away from it. It takes around 10 sec to calculate the whole thing sadly. I´ll upload a picture in a sec.

BTW the slope map by itself is just a curiosity I guess. It starts making sense when you combine it with a resource map like rover suggested. That way you could see if that space you with the high resource could is sloped like crazy so you don't want to build there. When you combine the values by dividing the resource map by the slope you might get something usable. Thats the next thing I´ll try once slope map is in releasable shape

Edited September 3, 2014 by Cyrik

[DMagic]

Well, you can calculate the height again for the slope, but reusing the existing height map removes the need for doing those slow pqsController calculations over again.

This whole, slow-terrain-height-calculation problem is SCANsat's biggest issue, I think, so I'm very open to ideas about how to get around it.

You can calculate the data offline, but then you're right back to ISAMapSat's problem of storing big texture files that take up huge amounts of RAM. Maybe there's a better way than using textures to handle it though.

[Cyrik]

Javascript is disabled. View full album

looks decent to me, but i´m very open to improvements.

btw right now you can change the accuracy on the fly and you have to set the max slope yourself, since i dont want to calculate everything twice to find the max slope to divide by:P

Well, you can calculate the height again for the slope, but reusing the existing height map removes the need for doing those slow pqsController calculations over again.

This whole, slow-terrain-height-calculation problem is SCANsat's biggest issue, I think, so I'm very open to ideas about how to get around it.

You can calculate the data offline, but then you're right back to ISAMapSat's problem of storing big texture files that take up huge amounts of RAM. Maybe there's a better way than using textures to handle it though.

yeah saving it would be great but then i´d have to force 1.0 accuracy and thats a bit large for planets. the best way to read a texture/file a few pixels/lines at a time, but that only works if you don't need the values often. it would kind of work for me, not for scansat though, unless you want to slow it's display speed down by a lot

Edited September 3, 2014 by Cyrik
a word

[RoverDude]

Well, you can calculate the height again for the slope, but reusing the existing height map removes the need for doing those slow pqsController calculations over again.

This whole, slow-terrain-height-calculation problem is SCANsat's biggest issue, I think, so I'm very open to ideas about how to get around it.

You can calculate the data offline, but then you're right back to ISAMapSat's problem of storing big texture files that take up huge amounts of RAM. Maybe there's a better way than using textures to handle it though.

Question is - could we just store this as numbers v. a texture? Would it be more or less efficient?

[RoverDude]

Before I forget... This should be tied to a part for functionality - I can whip one up

[Cyrik]

Question is - could we just store this as numbers v. a texture? Would it be more or less efficient?

i think we would have to test it. having it in a texture compresses it more but you would have to do more calculations to get the data out. you are trading space for cpu time. keeping either in memory is a bad idea anyway unless they aren't very detailed.

a file might be the best way though now that i think about it. you could format it in a way where you can just read a few specific lines if you are doing continues updates or you can read through the whole thing and dump it again if you build up your whole thing, the way my overlays do it.