On 25 Jun 2004, at 12:36, David Megginson wrote:
Jim Wilson wrote:
Sorry for the dumb question: why are they offending? I'm in favor of limiting
aircraft specific key bindings to a very small number of keys (like 1 or 2), but I'm also not clear why the input binding configuration needs to be handled
differently than it is now.
It's a layering violation: I know that sounds like a technicality, but it has serious effects on usability and system management.
Once we set up a GUI for bindings, the user should not be surprised by having new, unrequested key bindings appear simply because (s)he chose a different airplane. For example, if the user binds '/' to fire an afterburner then loads a plane that uses '/' to deploy slats, we have broken the prime directive of user apps and discarded the user's input without warning. The only reason this hasn't been a problem so far is that changing key bindings without a GUI is too complicated for non-power users.
From a management point of view, let's say that we decide to use '/' by default to open a save file. With the current system, that will work fine until the user happens to load a plane that uses '/' for something else, and then it will fail to work, even if the user switches back to the original plane, because the rebinding will outlive the aircraft that triggered it.
So, let's see if we can fix this: keyboard.xml is long overdue for a rewrite anyway.
Just one personal opinion ...
What would be really good is if it were possible for the *user* to define an arbitrary number of keyboard / joystick configurations. These could also be named and grouped together; and there should be an easy way to switch between these configurations, from the keyboard or joystick itself if so desired.
This would allow the user to set up different control configurations for flying different types of aircraft. For instance, a plane that doesn't have a retractable undercarriage won't need those controls at all, and the keys that would otherwise have controlled the undercarriage could then be used for something else.
Also, it would allow people to set up different control configurations for different flight regimes with the same aircraft. For instance when flying a motorglider, you might want to switch between 'powered' and 'gliding' flight regimes, and have the throttle lever alternatively control the engine or the airbrakes; Setting up different control sets and being able to switch between them easily would make that sort of thing very easy and would probably be very useful and improve the user experience a lot.
Behind all of this, there would of course be a _default_ configuration for the keyboard, for each type of joystick, etc, but the user should be able to set up as many of their own configs as they want.
And the configurations woul also be able to vary by which physical controllers were actually available. A laptop user might have a big hefty joystick at home, but might also want to fly 'keyboard-and-mouse-only' when elsewhere; and might need different keyboard configurations for these settings.
The reason I mentioned grouping configurations together is to allow the user to specify, say, that three configs - 'fighter takeoff, fighter dogfight, fighter landing' - all belong together. Combine this with a 'cycle to next configuration in set' function which could be assigned to the same button in each fighter config, the user could easily switch back and forth between regimes as neccessary - without involving the four helicopter and two motorglider configurations they've _also_ made, but which are of course irrelevant when flying a fighter plane. The particular configuration group could be chosen in a menu (being a relatively infrequent operation). Aircraft might also be able to provide hints, so that a suitable control configuration set could be loaded automatically.
But I digress ... I hope you don't mind these musing from an interested-but-not-actively-coding reader of this mailing list.
All the best,
// Christian Brunschen
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel