BUG terrain_height with geocoordinates

[PhilouDS]

Hi,

This is my code:

// Kontrol System v0.5.8.3
use { yield } from ksp::game
use { CONSOLE } from ksp::console
use { Vessel } from ksp::vessel
use { GeoCoordinates, Waypoint } from ksp::orbit

pub fn main_flight (vessel: Vessel) -> Unit = {
  CONSOLE.clear()  

  // Munar Signal MISSION -> Waypoint created by the game on the Mun's surface
  // Latitude = 12.45 -- Longitude = 39.20
  const munar_signal = vessel.main_body.waypoints[0]
  const ms = munar_signal.geo_coordinates

  while(true) {
    CONSOLE.print_at(0,0, $"     Body: {ms.body.name}")
    CONSOLE.print_at(1,0, $" Latitude: {ms.latitude:N5}°")
    CONSOLE.print_at(2,0, $"Longitude: {ms.longitude:N5}°")
    CONSOLE.print_at(3,0, $"Altitude1: {ms.terrain_height:N2} m")
    CONSOLE.print_at(4,0, $"Altitude2: {vessel.main_body.terrain_height(12.45, 39.20):N2} m")
    yield()
  }
}

And the result:

Not only altitude1 and altitude2 are different but, also, altitude1 changes through time! I don't think this should be the normal behaviour 😅

[untoldwind]

This is somewhat surprising because it is running through the same chunk of code.

Problem is, that there are two different kind of terrain-heights in the game. The "regular" terrain height is calculated via the libnoise driven PQS system taken over from KSP1 (i.e. that is probably 99.9% of the surface) But then there are these points of interest, when some handcrafted model essentially overrides the terrain ... in these cases a ray-cast has to be done. I suspect that that one just does not hit the point of interest.

TLDR: I am not sure if there is an easy fix for this ;)

[PhilouDS]

I tried this: CONSOLE.print_at(5,0, $"Altitude3: {vessel.main_body.terrain_height(ms.latitude, ms.longitude):N2} m") And I have the same result as Altitude1 (I have the exact same changing value). I tried to do the same with my vessel's geocoordinates and I have no problem at all. So this raycast seems to be the problem indeed.

The strange thing is that the variable ms is defined outside the loop. So, even if Altitude1 is not the same than Altitude2, it shouldn't be changing.

[untoldwind]

Is it possible, that you did the first call while the 3d-model at the point of interest was not loaded yet? (i.e. out of range) That could explain the different results.

[PhilouDS]

Is it possible, that you did the first call while the 3d-model at the point of interest was not loaded yet? (i.e. out of range) That could explain the different results.

I added sleep(2) just after CONSOLE.clear() in the above script and altitude1 is still changing.

[lefouvert]

I have been through this situation. The exact altitude from terrain is vessel.altitude_scenery. For rought predictive evaluation, .altitude_terrain is enought, but for last 50 meters, vessel.altitude_scenery is far more accurate. (Context : I use it at launch. I go straight forward until my vessel have going up at least his own height and then, I start to apply pitch angle. For fun : "Did you know". Actually, most code I've seen use azimuth and pitchAboveHorizon as guide, but old real launcher use roll and pitch, precomputed from the time of the launch. Delayed launch mean re-compute the roll in order to be azimuth exact)

[PhilouDS]

I have been through this situation. The exact altitude from terrain is vessel.altitude_scenery. For rought predictive evaluation, .altitude_terrain is enought, but for last 50 meters, vessel.altitude_scenery is far more accurate.

Ok. thanks for the info... the bug I noticed is with waypoints (or, at least, the handcrafted models)

(Context : I use it at launch. I go straight forward until my vessel have going up at least his own height and then, I start to apply pitch angle. For fun : "Did you know". Actually, most code I've seen use azimuth and pitchAboveHorizon as guide, but old real launcher use roll and pitch, precomputed from the time of the launch. Delayed launch mean re-compute the roll in order to be azimuth exact)

I prefer to use the vertical velocity to start my GT (calculated in terms of the TWR at launchpad).

[lefouvert]

I prefer to use the vertical velocity to start my GT (calculated in terms of the TWR at launchpad).

Understandable. It was not an advice, just an exposition to give context. And in this context, my concerns are : does my TWR above 1 ? If true, release launch clamp. Does the clamps are out of my way (the purpose to go straight forward to clear them from my trajectory) ? If true, start ascent maneuver. And since clamps are never higher than my launcher, the easiest way to be sure they are out of my path is simply to flight higher than my vessel height. So I determine my vessel heigh with the distance between my highest part and my lowest part (rought, but good enough approximation, since parts position is usually from their center, and in case of asymetrical vessel, distance is higher than heigh) and then I lock SAS stabilization until this heigh is clear. From vessel.altitude_scenery :) As you have seen, I don't use gravity turn, my vessels are too unstable (winkwink UntoldWind) to be reliable in thoses situations. So I force direction with a trigonometric function (logarithmics lead me to burn in atmosphere too often) until this function match orbital prograde, and then prograde take the lead.

[untoldwind]

Maybe the vessel.altitude_terrain and vessel.altitude_scenery should be combined in the API, as it obviously creates some confusion. I added both values before fully understanding the difference. After digging into the code, I do not think there is any use-case for vessel.altitude_terrain

[untoldwind]

... and concerning the gravity turn/launch script: The std::atmo::atmo_launch script is neither optimal nor does it take the angle-of-attack (i.e. the most likely cause of instability) into account. I gladly accept any modification to replace that with one with something more sophisticated ;)

[lefouvert]

... and concerning the gravity turn/launch script: The std::atmo::atmo_launch script is neither optimal nor does it take the angle-of-attack (i.e. the most likely cause of instability) into account. I gladly accept any modification to replace that with one with something more sophisticated ;)

It wasn't a rebuck about your launch script ;) It's just because I know you have seen how junky can be my vessels. They are mostly «flipendo powered» :)

However, If my ascent script can help, I would be glad to give it to you. Main issues currently are :

• it's heavily Ship struct dependent (so need some rework to be shared)
• it's throttle variable, purist won't like it
• stop as soon as expected altitude is reach (it's only an ascent maneuver. circularization need to be done afterward) even if still in atmosphere (kind of a mandatory since for very low orbit, time to circularize would not be enought if out of atmosphere is waited)
• it don't manage to do gravity turn
• takeoff itself is another «maneuver»

As all can't be dark, it have some pro :

• protection against overheating
• protection against too high Max Q
• won't throttle if off direction
• throttle down before reach expecteded altitude to be more precise (less than 20 meters margin error)
• classic auto-stage, auto-jettison fairing
• does science
• deploy everything (a detection of what is about the launcher, and what is a satelite related should be done, in order to deploy everything LAUNCHER related, and not everything-everything. It's on my roadmap, but as said some days ago, busy times :'( )
• have less than 1° inclination error at end (far too much to my taste, but didn't get better at the time)
• automaticly choose between trigonometric for atmo launch, and logaritmic for vacuum launch, both switching to orbital prograde when elevation match.

Fuel consumption is not crazy, but is not optimal.

I think it could be valuable if @PhilouDS share is knowledge about gravity turn and result obtained. I think we should take a look at his YT channel and git code ^^

[PhilouDS]

I think it could be valuable if @PhilouDS share is knowledge about gravity turn and result obtained.

I don't have any knowledge about GT except that the cheaper GTs always follow the prograde vector. So, it's what I do. But the apoapsis I obtain at the end of the GT is never the exact apoapsis I wanted. And with KSP2, I use 2 maneuvers to circularize (with KSP1 + kOS, only one maneuver was needed to get a difference of only 10m between Apoapsis and Periapsis but KSP2's maneuvers are different). For me, it doesn't matter because I always do something else after the circularization (transfer to an other body, hohmann transfer to an other orbit...)

I think we should take a look at his YT channel and git code ^^

You obviously can do that! But don't expect to find the finest code in the world... And don't forget to subscribe 😂

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.