mgalyean
commented
3 years ago Given that without the suffix most kos coders that need this info are already eating the computational expense one could guess that this would be "ok". But maybe a way to know if one were getting the cheap or expensive result would be nice. This could be done in script by checking OPCODESLEFT before and after I suppose
Somewhat related and probably obvious, so not trying to be pedantic here, but there are some optimizations to the expensive computation that can be made if one assumes an equilateral triangle of reference points around the position of interest in that the offsets from the center can be predefined and no trig is required. That is the values for cos() and sin() will always be the same so can be hard coded (+-0.86666... radius of sample and +-0.5 radius of sample to get the x,y offset combos of sample positions. If the radius of the sample size is always the same then the offsets would always be the same and hardcoded and only additions/subtractions would be required
bigmcr
When the terrain polygons are loaded, geoposition uses a Raycast to find the exact location of the ground. It turns out that Raycast also tells you the normal vector of the surface of the collider (terrain polygon) you hit, and KSP could expose this in a sufffix if we wanted. (Along with that, we could get a slope value for the spot by getting the angle between that normal and the up vector at that spot.)
If this is done, a decision has to be made about what to do about the geopositions that are far enough away not to have terrain loaded so they have to fallback on the PQS calls for hypothetical terrain. As it does NOT tell you the normal vector, it would have to be approximated by taking 3 nearby samples to make the plane. Is this computationally expensive? Is it okay to do or should such calls return nothing for normal? Those questions would have to be addressed before this could become a feature, but they probably do have sane answers that can be found.