Page MenuHomeFeedback Tracker

"flyinheight" unexpected behaviour
New, NormalPublic

Description

if a helicopter hovering at [x,y,z >= ~22], an "this flyinheight 10" command results in an effective height (ASL) of ~22 meter.
now you are able to switch the height by flyinheigt commands which arguments are not < 10!
if you now execute the command "this flyinheight x" and x is < 10, the helicopter corrects its flyingheight to the effective height (ASL) of x meter.
from now on, every execution of the command "this flyinheight x", while x is >= effective helicopter height, will be ignored!
the command flyinheightASL is pretty useless at all!

Details

Severity
Major
Resolution
Open
Reproducibility
Always
Operating System
Windows 10 x64
Category
General
Steps To Reproduce
Additional Information

why the developers of A3 does not test what they have written???
i mean, its simple, to use the editor and create a helicopter and test the commands by using the debug console, isn't it?

Event Timeline

dedmen added a subscriber: dedmen.Aug 2 2021, 12:37 PM

Your description is pretty messy.
So what you are really tring to say is flyInHeight is ASL even though it is supposed to be AGL?

NikkoJT added a subscriber: NikkoJT.Aug 2 2021, 1:25 PM

It seems like they're also describing a problem where flyInHeight commands below 10 metres will prevent subsequent flyInHeight commands for higher altitudes from taking effect.

In my experience both flyInHeight and flyInHeightASL are pretty inconsistent and unreliable in their effects overall, so it might be worth just investigating the entire command to see what's wrong with it.

CHIMERACyborg added a comment.EditedAug 3 2021, 5:19 PM

Your description is pretty messy.
So what you are really tring to say is flyInHeight is ASL even though it is supposed to be AGL?

It is more, AGL, but ASL and AGL in case af (issurfacewater _pos == true) is the same, expect AGL should be "over ground" and in that consequence equalto getpos.
So, we can say that it is effective ASL over water and ATL over land.

It seems like they're also describing a problem where flyInHeight commands below 10 metres will prevent subsequent flyInHeight commands for higher altitudes from taking effect.

In my experience both flyInHeight and flyInHeightASL are pretty inconsistent and unreliable in their effects overall, so it might be worth just investigating the entire command to see what's wrong with it.

I dont know why there exist the imaginary "border" at 10m height, this must have a reason!?
It could also be a, lets say, walkarround for another messy AI behaviour problem, but it´s definetly worth to take a look at the code of the command, i guess.

Thx, and greetz
Cyborg