add more anomalies

[technogeeky]

Suggestions include:

• highest elevation
• lowest elevation

That's it, really. I suspect these aren't official anomalies? I don't know. I know that some online maps list them as such.

[DuoDex]

I believe that you can determine these from one of the normal ScanSat mapping options. Just put in a little time.

[technogeeky]

Come to think of it, I need to know this information already anyway to change the legend from being arbitrary (and not based on any planetary bodies heights) to starting at the lowest and ending at the highest elevation.

[DuoDex]

True. It would be really time-consuming to do this realistically (i.e. actually compare heights). I suggest you use the current elevation map(s) to find the lowest and highest heights for each body, then write an algorithm to divide colors equally between the lowest height and the highest height.

I explained this really badly. If it's unclear I'll be here.

[technogeeky]

This is planned and in the works. I don't like that solution, but I also don't know if there is an efficient way to find those values myself.

Actually, now that I think about it, there is one:

We already want a (secret) debugging feature which reveals all maps fully. This would involve code which already scans and records altitudes; so it would cover the highest and lowest altitude (modulo the precision needed to find it). So I could have the this debugging process generate the maximum/minimum altitudes into the log (or somewhere else) and just feed this back into the codebase.

It sounds possible to me. I'll have to dig some.

[DuoDex]

I explained this terribly and gave a false impression. I was attempting to explain how to color topographical maps properly.

You said: "We already want a (secret) debugging feature which reveals all maps fully. This would involve code which already scans and records altitudes; so it would cover the highest and lowest altitude (modulo the precision needed to find it). So I could have the this debugging process generate the maximum/minimum altitudes into the log (or somewhere else) and just feed this back into the codebase." This is much better than what I thought, which I won't take the trouble to explain because it's stupid.

So what I suggested was to assign the maximum altitude (which we have already determined via your above idea) the color that you wish to indicate "highest" altitude and assign the color that you want to indicate "lowest" altitude to the minimum altitude, then have something that (using those two colors as a range) goes through and assigns each altitude a color that is relevant to the two colors already assigned.

Example (with extremely convenient numbers): We're scanning an asteroid where the highest altitude is 100m and the lowest altitude is 50m. Using the solution you have suggested, we determine those heights and assign the lowest the color blue and the highest the color red. Now, the scanner turns on and notices a 75m hill. It goes through the code and sees that the color red is highest and blue is lowest. It calculates the relative height to the lowest and highest altitudes and because it is EXACTLY halfway in between the two altitudes picks the color EXACTLY in between the colors assigned to the highest and lowest altitude. With red and blue and a 75m hill, that is purple. If we try this with a, say, 62.5m hill, we would get a darker purple than normal. If we did this with an 87.5m hill we would get a lighter purple.

Again, I'm not good at explaining. If you want a diagram I can make one.

[DMagic1]

The in-game way of doing this would be to compare each calculated elevation from the big map and determine which is the highest and which is the lowest, then put some kind of indicator over them when the map finishes. This is probably terrible because it adds more for the big map to do, and it would only work well with a full map. Anything that has to cycle through all of the elevation values and pick out the highest and lowest probably isn't a good idea.

I think what TG is suggesting is to fill out the maps by cheating, calculate the highest and lowest heights for each planet, then just store that data as constants somewhere, either in the code or in a config file. That way we could just look up the values and their locations from their stored location and assign an icon on the map. It's not as flexible as doing it all in-game, but I think it's much more practical. And it's also better than relying on the wiki or something like that.

Then from there we could do what you suggest and assign colors appropriately. I have no idea how they are assigned now, or why some planets don't use the full scale, but it probably isn't difficult to set it up correctly.

[DuoDex]

Doing it all in-game would be a terrible memory hog, however you would have to do it for asteroids (which would require a whole 'nother set of code as the game recognizes them as parts).

Some planets don't have all the colors because the arbitrary way you have the color-altitude table set up now results in some planets just not having the proper altitude for the color assigned.

[technogeeky]

I think what TG is suggesting is to fill out the maps by cheating, calculate the highest and lowest heights for each planet, then just store that data as constants somewhere, either in the code or in a config file. That way we could just look up the values and their locations from their stored location and assign an icon on the map. It's not as flexible as doing it all in-game, but I think it's much more practical. And it's also better than relying on the wiki or something like that.

Precisely. I can go farther, however.

@DuoDex:

The point of the setup I was describing was that it only needs to be run once, just prior to the release of SCANsat. The developer who is releasing it would build the program with a flag enabled (instead of debug, say, CLOSESHAVE). Doing so would cause at least two things to happen:

1. The Big Maps for every body would be 100% visible. (useful for other reasons, such as generating reference maps for websites, screenshots of the plug-in, etc)
2. You could start a pool of working threads to run over the maps (in parallel), marking the max and min altitudes. Even better would be to generate this function (and the opposite; minimum elevation per ~~altitude~~ inclination). Having this function and the ability to analyze it (I'm sure a stepper function classifier is possible to write) for each body (and not just the ones without atmospheres, as calculated here) would be very interesting (and perhaps allow us to make even coloration decisions).

Regardless, the prerequisite to this is exactly what I'm working on now. I'm adding a framework to organize the four or five windows that we have; adding color palettes and support for them along with user customization and colorblindness awareness and notification.

Back to the point, however: this process would just be run once by the devs. There would be a table in the code which stores these things (max,min some other small-ish set of values for every mainBody) , and that table would print itself out in the KSP.log (or, as the framework I'm working with provides, a ConfigNode .cfg file that is not in persistent.sfs). Then we can just paste this output back into the code itself (along with some simple text processing) and whala, we have regenerated all of these values.

[DuoDex]

@technogeeky I know that the process would only have to be run once. What I was saying was that it is possible to write a function that takes the minimum and maximum altitudes/elevation (I'm not sure what you meant by "minimum altitude per elevation") that were generated by those threads and make coloration decisions based on those for each body, have that be printed to a table and used in the maps via the method you suggested. This also would only have to be run once.

Color palettes could also be supported by this, having each color in a palette correspond to a number determined by the above function, the above function now generating numbers instead of specific colors.

[technogeeky]

@technogeeky I know that the process would only have to be run once. What I was saying was that it is possible to write a function that takes the minimum and maximum altitudes/elevation (I'm not sure what you meant by "minimum altitude per elevation") that were generated by those threads and make coloration decisions based on those for each body, have that be printed to a table and used in the maps via the method you suggested. This also would only have to be run once.

1. I meant the same graph but with minimum altitude instead of maximum. So minimum altitude vs inclination. I've edited my post to reflect that.
2. I think we are mostly on the same page about this stuff. My current plans are:
   • for each planetary body
     • for Altimetry:
       • for LO: a ref to a palette of size 2 (or 3) -- [black, white] by default
       • for HI: a ref to a palette of size 6 or 7 or 8 -- by default
       • and sliders to designate:
         • minimum altitude (maybe)?
         • sea level
         • maximum altitude (maybe?)
     • for Biome: a ref to a palette of size by default
     • for Slope: a ref to a palette of size <FIXME: how many?> by default
   • for each resource overlay
     • for two-color resources: a ref to a palette of size 2 by default
     • for three-color resources: a ref to a palette of size 3 by default
3. However, the only part which I see taking place in a once-off fashion is generating the elevation data. The coloration applied to the elevation should take place in-game, far after the fact.
4. In fact, for everywhere I said 'a ref' above, I envision the user being able to not only swap between a set of included palettes (I intend to get a big set of them from a website dedicated to mapping palettes), but also to copy those palettes to make new ones (and apply them) or make entirely new ones from scratch -- all in-game.

Now, we the developers are going to have to make some fun choices for defaults (I think we'll try and use a different palette for each planet). But other than that, we should be hands off.

1. FIXME: I do not know where I want to store this information, however. It seems like it might be the kind of data which should be stored in a plugin-wide .cfg file, instead of in persistent. A user may expect that their preferred coloration settings be present in all of their games, not just one. Or maybe not.

[DuoDex]

@technogeeky I would store it in the persistent.sfs file as this would simplify mobile saves. (I have a laptop and a BadS desktop and keep my KSP data in the cloud. Having to update my mods AND my saves every time I switch computers would be a massive pain in the ***). You're the dev, your choice.

With the slope data again it should be possible to generate some colors using min/max data. I would suggest a rather large palette size for slope (the more the better, 8-9-10) as slope is far more variable than actual elevation, as evidenced by the Dres canyon.