> I see it a real pilot has to let go of something to twiddle a dial
anyway, > we shouldn't complain if we have to as well.
A real pilot can keep one hand on the yoke and twiddle a dial with
another. He or she may also have a copilot. I use mouse control as I'm
without a joystick, and having either to pause the sim to drop the gear,
or to lose control at end of final, doesn't sound like a recipe for
happy landings. Not that my landings are happy anyway ;)

Giles Robertson

-----Original Message-----
From: Josh Babcock [mailto:[EMAIL PROTECTED] 
Sent: 27 May 2004 21:21
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] keyboard mapping

Lee Elliott wrote:
> On Thursday 27 May 2004 20:18, Andy Ross wrote:
>>Josh Babcock wrote:
>>>So maybe airplanes shouldn't be in the interface business.  Maybe we
>>>should spend our energy agreeing on property conventions and Nasal
>>Even better would be to take a big audit of all the existing bindings
>>and re-assign them from scratch.  We've accumulated all sorts of
>>inconsistencies and usability glitches over the years.  Here's one
>>right here:
>>>a    Tailhook down
>>>A    Tailhook up
>>>L    Toggle slats
>>IMHO, we want to adhere to *either* the traditional toggle convention
>>*or* the no-shift-means-down/shift-means-up idea.  Using a combination
>>in the default mappings is confusing.  Likewise, we have other
>>bindings (magnetos, flaps) that use yet another convention ("key
>>pair") to indicate increase/decrease.
>>I'm sure this will generate a good viscious flame war, but IMHO it
>>ought to be done sooner rather than later.  We're starting to attract
>>real newbies, and they are already having a hard time with our default
>>And while we're at it, we need to do the same thing for the joystick
>>bindings.  I bought a new stick recently to replace my X45 (a Logitech
>>Extreme Digital 3D) and discovered that our default bindings for it
>>are absolutely nothing like the ones for the X45.  It does "snap view"
>>with the hat instead of panning, for instance.
>>>Lastly, while we're at it, get rid of any key bindings define in the
>>>code and put the mappings in keyboard.xml.
>>This is done already.  There are no more hard-coded key bindings in
>>the C++ code.  Outside of bindings done for aircraft, everything is
>>in keyboard.xml.
> I hope there's no flame war over this - it's too important.
> Part of the problem with coming up with a good keyboard mapping scheme
is that 
> a comprehensive survey of the requirements needs to be done before
> can be planned e.g. are slats simply toggleable (erk!) or do they need
to be 
> stepped up/down?  (I guess this particular example could be
accommodated via 
> Nasal, as used for the flap indents - I've already done this for the
> which only has two flap positions, so essentially they're being
> Perhaps a wiki could help to gather the information, then many people
> enter the requirements they know about and it would avoid having to
make a 
> single person responsible for finding everything out and possibly
> something, which would lead to a flawed solution.
> Then there could also be an issue with some keyboard combinations
> difficult to use when the context is taken into consideration, i.e. is
> to use Shift/Control combos to control things a good idea at critical
> in the flight, such as take-offs and landings?
> LeeE
> _______________________________________________
> Flightgear-devel mailing list
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Well, I'm glad to see other people take this seriously. I consider what
suggested a sort of half-measure holding action.  I didn't really think
there was enough desire out there to really look at the problem.

I actually think that it goes a little deeper than the configuration
too.  One 
of the basic problems is that these actions don't even mean the same
thing in 
every aircraft.  In the B-29 for example, flaps and gear are controlled
by an 
instantaneous switch that you have to hold down throughout the transit,
with no 
detents. I really haven't been able to come up with a way to deal with
that. I 
think that one of the (many) things we should look at is whether it's
smart for 
the input layer to be directly modifiying properties. Maybe it's smarter
for the 
keyboard.xml file and the joystick files to just say that when I press
button, I want this sort of thing to happen.  It may be move the flaps
to the 
next lowest detent at speed x or it may be move the flaps down at speed
x until 
I let up on the button.

We could do this by having an abstract layer between input and the
workings.  Pressing a key or button would just raise a flag or create an
that would then cause some script to run.  It could be a default script,
or a 
specific one in an aircraft defenition that overrides the default.

Maybe another good question to ask is: what should even be controlled by

keypresses?  Maybe a radical departure like having a bunch of stuff
by pop-up dialog like the radios.  I think in real life it's analogous
I need to change setting x
I'm going to look over here at the x type panel
I'm going to reach over and twiddle dial x
Now I'm going to look back out the windscreen.
So maybe stuff like autopilots could all be in dialogs and you just
press one 
key to get all the functions in the dialog.

Alternatively, you could use a WYSIWYG paradigm and just make all the
clickable and make people click over to mode 0 and use the mouse cursor.
The way 
I see it a real pilot has to let go of something to twiddle a dial
anyway, we 
shouldn't complain if we have to as well.

This could leave a lot more keys free for major function that in a real
would not be a small part of some small panel, but would have their own
lever or button or a control directly on the yoke or throttle.


Flightgear-devel mailing list

Flightgear-devel mailing list

Reply via email to