Well, I'm glad to see other people take this seriously. I consider what I suggested a sort of half-measure holding action. I didn't really think that there was enough desire out there to really look at the problem.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 scripts.
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 interface.
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.
Andy
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 anything 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 B-52F, which only has two flap positions, so essentially they're being toggled)
Perhaps a wiki could help to gather the information, then many people could enter the requirements they know about and it would avoid having to make a single person responsible for finding everything out and possibly missing something, which would lead to a flawed solution.
Then there could also be an issue with some keyboard combinations being difficult to use when the context is taken into consideration, i.e. is having to use Shift/Control combos to control things a good idea at critical points in the flight, such as take-offs and landings?
LeeE
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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 this 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 actual workings. Pressing a key or button would just raise a flag or create an event 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 controlled by pop-up dialog like the radios. I think in real life it's analogous to:
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 functions 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 cockpit would not be a small part of some small panel, but would have their own big lever or button or a control directly on the yoke or throttle.
Josh
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
