ground distance, and altitude based on "sea level" are inferred on usage
Hello!
this bug is causing numerous other issues from artificial intelligence being unable to determine altitude to parachutes that do not open over mountains given a specific height, and possibly more bugs
reproduction:
1. build a ship that can sufficiently fly close to planet surface - Triton in this example
2. on Triton look for a big flat area close to the "sea level" of the planet - for example any frozen lake
3. for the flight control seat of the vehicle to the largest screen set up the "App" that is for showing the horizont line, and prograde marker with the vertical speed at the bottom left corner, and the altitude at the bottom right corner inside it - these information are present all in one app - i forgot its name in game, but you have to choose this one, and look at both this one, and your altitude numbers for the horizont line as you reproduce this bug
4. turn on altitude numbers for the horizont line of your screen in settings
5. start from the ground close to sea level (from the frozen lake) on Triton
6. slowly take off while looking at both the altitude marker in the flight control's screen, and the altitude number that should be present by default when flying inside planetary gravitational fields beside your horizont line that is not in the flight control's seat
7. notice that as you take off both numbers start to be different after a certain altitude
- the altitude you can see beside the horizontline that is not inside the screen is ground distance, while the altitude you can see in the flight control's screen at the bottom right corner is changing from ground distance (at lower altitudes) to altitude that is based on "sea level" (at higher altitudes)
- this means the "App" in the screen is showing two different values in the same place, and altitude is determining which altitude this screen is showing - this is a bug in itself, but the horrible thing is that the these values are not only shown, but actually measured behind the scenes as a single expected reliable measurement that is the basis of systems that rely on altitude such as parachute auto open mechanism, and artificial intelligence trying to determkine altitude - this causes for example parachutes to not be able to open over mountain tops (for example with altitudes set as 300), and artificial intelligence to not find correct altitude.
my suggestion is:
completely separate ground distance from "sea level" altitude
- let parachutes only refer to ground distance when it comes to automatically opening parachutes
- let the "App" in this example to show both the ground distance, and "sea level" altitude
- let players determine separate artificial behaviours depending on either "sea level" altitude, or ground distance
- possibly more separation is also suspectible
i would like to suggest to never make inferred single field values in your code, but always try to separete these via for example types - one type for one value, even if you just wrap a floating point precision number into another type seemingly useless. in this very case literally create a type for "GroundDistance", and create a type for "SeaLevelAltitude" (even if these wrapper types will only contain a number as their field), and literally make functions only accept values of either ground distance, or sea level altitude type - possibly both, but in that case as two completely separate arguments
quiet surprisingly the target reticle is constantly showing ground distance - which is not very helpful, so my suggestion is that just like a supposed new "App", the target reticle should also show both ground distance, and "sea level" altitude - very importantly - not at the same place in the screen, but one beside the other
Edited a bit right now
Edited a bit right now
this is one related bug: https://support.keenswh.com/spaceengineers/pc/topic/47858-ai-flight-move-block-ignoring-minimum-altitude-and-collision-avoidance-settings
according to an update comment it is unrelated
this is one related bug: https://support.keenswh.com/spaceengineers/pc/topic/47858-ai-flight-move-block-ignoring-minimum-altitude-and-collision-avoidance-settings
according to an update comment it is unrelated
in these footages you can see that the basic task is trying to get to a gps relatively at lower altitude starting from the top of the mountain. the flight ai is set to min altitude 300m, with maximum speed between 40-100 m/s. in these footages you can see that instead of the ai moving the ship forward towards the target: it tries to move the ship to the proper altitude ever so constantly - resulting in very slow forward movement (as most of the maximum set speed of the ai is feeding the ascension, and then descension motion) due to be unable to decide proper altitude instead of forward motion.
i would like to give credit to Luca the dry humored girlfriend whos modified trench drone features the footages.
in these footages you can see that the basic task is trying to get to a gps relatively at lower altitude starting from the top of the mountain. the flight ai is set to min altitude 300m, with maximum speed between 40-100 m/s. in these footages you can see that instead of the ai moving the ship forward towards the target: it tries to move the ship to the proper altitude ever so constantly - resulting in very slow forward movement (as most of the maximum set speed of the ai is feeding the ascension, and then descension motion) due to be unable to decide proper altitude instead of forward motion.
i would like to give credit to Luca the dry humored girlfriend whos modified trench drone features the footages.
Replies have been locked on this page!