[Flightgear-devel] Autopilot key bindings and the problem of backspace

[Stuart B. <stu...@gm...>]

Hi All,

Currently there are a number of key bindings to enable various
auto-pilot modes, e.g.:

Ctrl-A Altitude lock
Ctrl-H Heading lock
Ctrl-G Glideslope lock
Ctrl-N NAV1 lock
Ctrl-P Pitch hold
Ctrl-S Autothrottle
Ctrl-T Terrain lock
Ctrl-W Wing level
F6 - Heading lock

Unfortunately, it is all to easy to enable some of them by mistake.
For example, on many systems, Backspace is Ctrl-H. So, if you are
using a GUI dialog box, don't quite click on the input box you
intended, then press Backspace, you will toggle the autopilot heading
mode. As many aircraft that use the generic autopilot don't have a
real autopilot in the cockpit, it is quite difficult to diagnose this,
as you vainly try to stop the aircraft from turning to 0 degrees! I
hit this every so often myself, and it often confuses me. I'm sure new
users hit this all the time and have a very hard time working out what
has gone wrong, assuming they do so before they auger in.

I've just pushed a fix to the MP chat system to fix this for the
quick-chat dialog (which is what usually catches me out), but I'd like
to fix the root problem - which is that it is far too easy to enable
the autopilot by mistake and then be unable to diagnose the problem.

I can see three solutions:

1) The most drastic option would be to remove all the key bindings for
the autopilot. Most of the autopilot locks require additional input
(e.g. setting the heading for the heading lock). While there are key
bindings for setting the heading etc. they only work once the mode is
active. I'm sure everyone uses the GUI to set the correct
heading/altitude/speed _before_ they engage the lock. Given this,
there seems little use for the key binding for the lock themselves.
Does anyone actually use the key bindings?

2) Change the bindings to require an additional modifier key, probably
Shift. This would retain the bindings, but make it less likely that a
user would fat-finger them, and most importantly remove the backspace
binding that I suspect causes the most problems.

3) Provide some notification to the user when the locks are
enabled/disabled. This could either take the form of an annunciator
bar at the bottom of the screen indicating the enabled autopilot mode,
or using gui.popup(), as we have to announce a view change to provide
a momentary announcement. An annunicator at the bottom of the screen
could also be used to indicate the parking brake state. This is often
very difficult to determine on startup.

My personal preference is option 1 or 2, but I'm very happy to go with
a majority decision.

Any comments?

-Stuart