Closed PhilouDS closed 2 days ago
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 ;)
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.
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.
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.
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)
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).
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.
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
... 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 ;)
... 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 :
Ship
struct dependent (so need some rework to be shared)As all can't be dark, it have some pro :
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 ^^
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 😂
This issue is stale because it has been open for 60 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.
Hi,
This is my code:
And the result:
Not only
altitude1
andaltitude2
are different but, also,altitude1
changes through time! I don't think this should be the normal behaviour 😅