Erik Hofman wrote:
Giles Robertson wrote:

The other advantage of defining specific function is consistency across
aircraft models. As as user, I'd want to know that a certain key drops
the arrestor hook, and that that same key drops the hook in all aircraft
that have one. If we just make aircraft modellers use a certain set of
keys, inconsistencies should spring up.


So far every designer seems to have accepted the same keyboard bindings across different aircraft. Please take a look at FlightGear/data/Docs/keyboard/map.pdf

Erik

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

OK, maybe the answer is just to make sure all the designers read that doc, and make changes to it when appropriate, but I already see conflicts like "h" in the hunter. I personally use "h" a lot, especially in the outside views, but it looks like it's gone for the hunter. Also, CRTL-B already has two meanings. The minute someone builds a plane with speedbrakes and a variable boost turboed engine this will get confusing.

This also brings up another point. All this stuff that is defined in multiple aircraft is not accessible to custom keyboard configurations. Say we get a few more planes with adjustable turbos (I'm working on one now) and instead of CTRL-B (which is what I'm going to code into my set.xml file) someone wants to use something else to control all the turbos in their custom config. Instead of just changing one line in their personal keyboard.xml file, they now have to go and edit all the planes that have turbo selectors. In addition they would have to do the same to assign a joystick button. Yuck.

So maybe airplanes shouldn't be in the interface business. Maybe we should spend our energy agreeing on property conventions and Nasal scripts. Turbo boost for instance could be handled similarly to the way flap detents are. Additionally you could say that if you want to use some of the neat features in the hunter, make sure you have some control mapped to /controls/flight/flaps-alternate-extension and all the other neat stuff. Stuff like adjusting the boost, emergency flap deflections, opening doors, dropping stuff and whatnot are pretty common real life functions. It's a good bet that we will be seeing stuff like this again, so let's do it right and define them globally. We have plenty of keys, no need to keep redefining the same functions over and over in a way that short circuits FG's wonderfully ability to be configured locally.

Anyway, we really need to stop hardcoding these keys into the program and the aircraft, it just trashes the flexibility of the input system. So here's my proposal. First, I volunteer to make the changes and mail them to Curt.

I think we should define the following default functions and link them to properties or Nasal scripts, because they seem to be popping up and are really pretty common in aviation:

C Open/close cabin doors, canopies, panels and ground related eye candy.
: Boost up selected engines(nasal script with detents defined a la flaps)
; Boost down selected engines
w Fold/extend wings
(/sim/controls/body/wing-fold, /sim/controls/body/wing-fold-period)
(I seem to recall that a and A don't actually do anything anymore ... this could also be ? /)
a Tailhook down
A Tailhook up
L Toggle slats


This leaves several keys totally unused, I would suggest reserving defyuDEFYU and their CTRL modifiers for aircraft and putting a note as such in keyboard.xml so people don't create conflicts in their local configs and also so that airplane builders will know what keys shouldn't step on their user's custom keyboard layouts.

Lastly, while we're at it, get rid of any key bindings define in the code and put the mappings in keyboard.xml. I'm not sure if there are issues with doing that though. That will help with custom layouts a lot.

Comments?

Josh

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to