Board index FlightGear Development New features

A Learning Experience: Keyboard Re-Map

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

A Learning Experience: Keyboard Re-Map

Postby DF_Hammack » Sun Aug 14, 2016 5:13 am

OK, I am retired, with a lot of time on my hands. I like to flight sim for fun, but I would like to do more. I want to get involved with FlightGear, but I don't know much about XML, and nothing at all about NASAL. In the past, I have gotten a good start learning new languages by de-constructing other work. As I fly FG, I find that while the KBD lay-out might be great for primary flight control, there are better possibilities for the KBD as a complement to the joystick. Joysticks used to be expensive. I guess good ones still are, but there are lots of inexpensive joysticks available, and quite a few mid-range to high end sticks wind up in thrift stores. The result is, anyone with an interest in flight simming gets a joystick of some kind. Most sticks have at least 4 buttons and a trigger. If you spend any time with FG, you map the most common functions to your joystick; the KBD becomes superflous. That leaves a lot of room on the keyboard to put specialty functions. I would like to re-map the KBD to provide more logical control as a complement to the joystick, much like a dedicated keypad controller, but without the expense. At the same time, it would be a great way to get more experience with XML, and to learn the core command structure of FlightGear.

I know I can start by de-constructing and rearranging the current keyboard XML file, but I would like to find some reference for other documented commands. There are some commands that are called from within the model, that it would be handy to have external control of, for example, HUD 3D. It is called from a menu, and called by the model, but there is no key command for it. I don't like the 3D HUD, and would love to be able to turn it off w/o pausing, calling the menu, turning it off, and resuming my flight. I control other HUD options from my stick, but I have no idea where to even find the command to try mapping that feature to my stick. Things like this, I know if I find useful, someone else will too. My goal is to do a keyboard with a logical layout that closely corresponds to the switch panel in a single or twin engine light plane. Someone who flies multi-engine airliners might do the same for them, and likewise, military aircraft. Then, when you decide what mission you want to fly, you just select the appropriate keyboard. There is nothing wrong with the default layout for "Sunday pilots", but for those who seek realistic immersion, and can't afford high end hardware, the choice would be nice. And, as I mentioned before, it would give me a better working knowledge of the overall command structure.

To that end, I would like to find documentation to the common commands, and would be happy to discuss such a project with anyone else interested.
DF_Hammack
 
Posts: 34
Joined: Fri Aug 05, 2016 10:57 pm
Location: Camden, SC, USA
Callsign: SilverSplash
Version: 2017.2.1
OS: Xubuntu 17.10

Re: A Learning Experience: Keyboard Re-Map

Postby Thorsten » Sun Aug 14, 2016 6:39 am

There are some commands that are called from within the model, that it would be handy to have external control of, for example, HUD 3D.


If, by the 'model', you mean the aircraft, the documentation resides with each aircraft (or not).

Each aircraft xml can override whatever is defined in the system wide keyboard.xml as it needs. That makes a lot of sense, because for instance the Shuttle has no need for flap controls (as it doesn't have any flaps), but it does need translational longitudinal and lateral thrust control - so the flap controls can be assigned to the translational +-X burns.

Likewise, some planes use a canvas HUD rather than the FG-native one - so they can reassign the 'h' key.

The bottom-line is, you won't be able to work around that - whatever you define system-wide is going to be changed by whatever the aircraft designer thinks reasonable.
Thorsten
 
Posts: 11374
Joined: Mon Nov 02, 2009 8:33 am

Re: A Learning Experience: Keyboard Re-Map

Postby DF_Hammack » Sun Aug 14, 2016 8:02 am

Yes, I understand that. But if I had key control, I could over-ride. To go back to my example... the HUD. I select the style of HUD from my stick. If the plane sets the HUD to 3d, I can menu select to turn it off. It stays off.... till I change HUD modes. When I change modes, the new mode comes up 3D. I have to go back to the menu turn it off again. It stays off till I change modes again. I respect the creators choice, but it just doesn't suit me. In something that HAS a HUD as standard equipment, I would probably be inclined to leave it model appropriate, but in a single engine, light aircraft, HUD is strictly a personal preference. The gauges are difficult to see, the HUD improves fly-ability. The 3D HUD is smaller, more difficult to see - the same problem as with the gauges. I should have the means to set it as *I* like it. If it really bothered me, I would go into the model and change it. Barring another solution, I just may do that, but there should be a global fix for something like that. The bottom line is, the creator creates for his pleasure. He maximizes his pleasure by designing his way, but I flight sim for my pleasure. Shouldn't I be able to maximize my pleasure in the same way? My whole idea is to give the flier the opportunity to customize his experience, without defeating the simulation concept. It seems like you may think I am saying I want 5 wheels on my car, when what I am talking about is pin stripes and a different radio.....
DF_Hammack
 
Posts: 34
Joined: Fri Aug 05, 2016 10:57 pm
Location: Camden, SC, USA
Callsign: SilverSplash
Version: 2017.2.1
OS: Xubuntu 17.10

Re: A Learning Experience: Keyboard Re-Map

Postby Thorsten » Sun Aug 14, 2016 8:56 am

Looking into gui/dialogs/hud.xml

the 3d effect is a property toggle of

/sim/hud/enable3d[1]



In something that HAS a HUD as standard equipment,I would probably be inclined to leave it model appropriate, but in a single engine, light aircraft, HUD is strictly a personal preference.


Well, in some cases it needs to be 3d (the F-14b is a good example which utilizes the FG-native HUD as a stand-in for the real thing). In cases where the original plane has no HUD, I agree that fixing an option plane-side is a design mistake. However, FG can't know the difference but the solution is to bring this to the attention of the aircraft maintainer, not to provide options to override the overrides.

Shouldn't I be able to maximize my pleasure in the same way?


Within reason.

You can always delve into the aircraft config and adjust it to your needs, but your specific set of globals may render any particular aircraft unflyable - so you'd create a bug report that can't ever be reproduced. Which is why for things like key bindings, the aircraft creator gets the last word because they depend crucially on the systems modeling.

On the other hand, for things like weather and rendering, the user gets the last word (we don't allow the aircraft creator to hard-select a rendering framework or change weather).

It seems like you may think I am saying I want 5 wheels on my car, when what I am talking about is pin stripes and a different radio.....


You may not see the havoc your generic key bindings could wreck with any particular plane right now, but rest assured that I do.
Thorsten
 
Posts: 11374
Joined: Mon Nov 02, 2009 8:33 am

Re: A Learning Experience: Keyboard Re-Map

Postby Thorsten » Sun Aug 14, 2016 11:00 am

Actually, let me try to explain this better.

There's no documentation of what you can do with the GUI options because you can do pretty much anything. You can set properties, call fgcommands and execute Nasal scripts. And what you want to do depends very much on the aircraft.

Consider 'G' to lower gear.

By default, the key gets mapped to controls.gearDown() in controls.nas via keyboard.xml. That writes into the FG layer /controls/* of the property tree. Information from there is passed onwards to the FDMs by default, so in JSBSim it would appear as fcs/gear-cmd-norm (or so). From there it's up to the systems modeling to do something with it (change contact point location, change drag,...)

However, any aircraft may differ from that path,

Say, someone has the hydraulical system modeled in Nasal. So he'd like to check whether there is pressure before the command to lower gear is executed. Easy - you by-pass controls.gearDown() and map the key instead to my_plane.myGearDown() which first checks hydraulic system and then either forwards the command or not.

(If you have hydraulics modeled in jSBSIm, you don't need to do that, you can catch it in processing the command into FDM changes)

Say you have a gear which can't be retracted - (like the Shuttle) - then it's most convenient to by-pass the FG layer and let the key directly talk to the JSBSim systems model.

So while 'G' is generally accepted as a convention to lower gear, the way this is done technically is rather airplane-specific. Which is why the plane needs the authority to override mappings. If you use a generic file to map 'G' to 'gear down' and try to operate it on ten different planes which also map 'G' to 'gear down', you may find that none of them works - because they all internally handle the same thing differently.

You're thinking that you just want to customize a few trivia - but FG can't know that. In essence, you're asking for the authority to override any airplane specific configurations - the vast majority being introduced because the plane would not work otherwise!
Thorsten
 
Posts: 11374
Joined: Mon Nov 02, 2009 8:33 am

Re: A Learning Experience: Keyboard Re-Map

Postby DF_Hammack » Sun Aug 14, 2016 1:12 pm

Thank you Thorsten, that explains a lot. So, in other words Keys are not variable, because the key assignment is the convention, not the command. Gear function is assigned to the G key, but there may be one of several commands the designer uses to actuate the gear, that he then assigns to the G key, rather than one specific gear command that could be moved to any key. Do I now understand correctly? My, that is..... different. It does make FlightGear more (and less) configurable than anything I have ever seen before. and explains a lot.

I have seen scripting for a joystick, which assigned various functions in the stick differently for about 10 separate aircraft, by name. This user had a number of configs, each for the same stick, and each covered a number of different aircraft. I thought he was probably being a little too specific. At the time, I didn't understand this, and it was very confusing. Now I understand. The buttons controlled the same function, but that function was called by a different command for each aircraft. Oh well, it was a good idea, and I may still follow through for my own use, but by necessity, it is very specific, and thus not widely applicable. I will further investigate those joystick configs. It looks like I may wind up doing something similar for my keyboard.

Thanks for your patience, everyone. I am new, and sometimes it is easier to test an assumption, and learn why it is incorrect, than to phrase a question. And see? I learned something (just not what I expected) :D
DF_Hammack
 
Posts: 34
Joined: Fri Aug 05, 2016 10:57 pm
Location: Camden, SC, USA
Callsign: SilverSplash
Version: 2017.2.1
OS: Xubuntu 17.10

Re: A Learning Experience: Keyboard Re-Map

Postby Thorsten » Sun Aug 14, 2016 4:54 pm

So, in other words Keys are not variable, because the key assignment is the convention, not the command. Gear function is assigned to the G key, but there may be one of several commands the designer uses to actuate the gear, that he then assigns to the G key, rather than one specific gear command that could be moved to any key. Do I now understand correctly?


Pretty much, yeah.

It (obviously) has pros and cons. It takes some time to get used to how speedbrakes are deployed for instance, there's the s - shift-S toggle option, there's the ; and ' convention for more differential use and there's the throttle for gliders etc which use differential brakes - remembering which works in which plane can be a pain.

I am new, and sometimes it is easier to test an assumption, and learn why it is incorrect, than to phrase a question.


Nothing wrong with that - you're very welcome :-)
Thorsten
 
Posts: 11374
Joined: Mon Nov 02, 2009 8:33 am


Return to New features

Who is online

Users browsing this forum: MSN [Bot] and 1 guest