Currently, I believe the fall animations trigger due to the wrong circumstances and way too rapidly.
There are two animations and which plays depends on the ASL (or ATL?) height, let's call them "edge drop" (Weapon ready, legs dangling) and "skydiving freefall" (legs and arms spread, belly facing the ground).
Wrong circumstances:
By wrong circumstances I mean that the "skydiving freefall" animation triggering even in situations where "edge drop" would be way more appropriate.
An example of this is if you have a structure high in the air and you drop from a higher floor of that building to the lower floor. When that building is on the ground or low altitude, the "edge drop" will play, but if that building is high in the air and the player does the same, the "skydiving freefall" will play, even tho the drop distance was the same.
A recommended fix for this would be to actually check the vertical distance between the unit and the nearest collider below the unit on a frame instead of purely altitude. This will result in "edge drop" still being able to play and "skydiving freefall" triggering the moment actual distance between the player and the ground is high.
Eager triggering:
By eager triggering I mean that the both kinds of animations will trigger (seemingly) even if the footing was lost for a single frame. Various model issues or modeling decisions will lead to this and the gameplay on such objects, suspended in the air or otherwise, is rendered useless.
An example of this is if a unit puts it's back towards the railings of the green watch towers on the stairs, the unit will start to "edge drop" even if they lost no altitude and continue to have stable footing. This results in players seeming to be stuck in walls "edge drop"-ing until they rotate. This also happen when you push your back towards a lot of objects if you do not stand on the ground (Video by Danczer demonstrating this: https://www.youtube.com/watch?v=NTYKD8gItPo)
Second example of this is objects suspended high in the air that have roadway LODs with minor gaps or high inclines. On such surfaces it is possible to lose footing for a frame or a few and this will then result in the unit being stuck in the "skydiving freefall" state.
A recommended fix for this is to log the last time the unit had stable footing (a timestamp that updates if the unit is considered to have stable footing in the frame) and compare it against the current frame time. I'm assuming that even a conservative delay will alleviate the problem mentioned above. {F24788} {F24789} {F24790} {F24791}