HTML ified joystick docs
This commit is contained in:
j4strngs
parent
b7b4e5b3f4
commit
1062618702
3 changed files with 762 additions and 6 deletions
|
|
@ -1,7 +1,9 @@
|
|||
Users Guide to FGInput - Joystick And Keyboard Bindings For FlightGear
|
||||
Or
|
||||
"The document formerly know as The Users Guide to Joystick Usage Under
|
||||
FlightGear Flight Simulator"
|
||||
<HTML>
|
||||
<HEAD></HEAD>
|
||||
<body>
|
||||
<H1>Users Guide to FGInput - Joystick And Keyboard Bindings For FlightGear</H1>
|
||||
Or The document formerly know as
|
||||
<H2>The Users Guide to Joystick Usage Under FlightGear Flight Simulator"</H2>
|
||||
|
||||
version 0.7.7.3 07/02/2001
|
||||
Author John Check <j4strngs@rockfish.net>
|
||||
|
|
@ -582,4 +584,5 @@ no <mod-up> tag, so it *does* work like a parking brake.
|
|||
<property>/controls/brakes[2]</property>
|
||||
</binding>
|
||||
</key>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
|
|||
753
Docs/README.Joystick.html
Normal file
753
Docs/README.Joystick.html
Normal file
|
|
@ -0,0 +1,753 @@
|
|||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE></TITLE>
|
||||
</HEAD>
|
||||
|
||||
<body>
|
||||
|
||||
<H1>Users Guide to FGInput - Joystick And Keyboard Bindings For FlightGear</H1>
|
||||
Or The document formerly know as
|
||||
<H2>The Users Guide to Joystick Usage Under FlightGear Flight Simulator"</H2>
|
||||
|
||||
<cite>
|
||||
version 0.7.7.3 07/02/2001
|
||||
Author John Check <j4strngs@rockfish.net>
|
||||
</cite>
|
||||
|
||||
<ol>
|
||||
<li><A HREF="#history">Some History</A>
|
||||
<li><A HREF="#first_things">First Things First</A>
|
||||
<li><A HREF="#xml">About XML</A>
|
||||
<li><A HREF="#output">Determining Your Joystick Output</A>
|
||||
<li><A HREF="#default">Default Joystick Properties</A>
|
||||
<li><A HREF="#okay">Okay, Now What?</A>
|
||||
<li><A HREF="#modifiers">Modifiers For Raw Joystick Values</A>
|
||||
<li><A HREF="#command_manager">The Command Manager</A>
|
||||
<li><A HREF="#bindings">Bindings</A>
|
||||
<li><A HREF="#axes">Joystick Axes</A>
|
||||
<li><A HREF="#buttons">Button Properties</A>
|
||||
<li><A HREF="#coolie_hat">Digital Coolie Hats</A>
|
||||
<li><A HREF="#keyboard">Keyboard Bindings</A>
|
||||
<li><A HREF="#"></A>
|
||||
<li><A HREF="#"></A>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
This document is written with versions of FlightGear 0.7.7 and greater
|
||||
in mind. It assumes a working joystick present on your system. It
|
||||
is written from the perspective a Linux user, but the information presented
|
||||
is valid on other platforms. The <A HREF="http://rockfish.net/shell/aboutFGInput.txt">most current version</A> is available online.
|
||||
</p>
|
||||
<p>
|
||||
Thanks to David Megginson, who aside from actually implementing FGFS XML
|
||||
features, lets me rip off his descriptions of how stuff works so I can look
|
||||
smart.
|
||||
</p>
|
||||
|
||||
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="history">Some History:</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
<p>
|
||||
Earlier versions of FGFS had assignments of joystick axis/buttons
|
||||
and key bindings hard coded. If you had a joystick that did not use
|
||||
the default channel assignments, or wanted different key bindings
|
||||
you had to edit the source code and recompile.
|
||||
</p>
|
||||
<p>
|
||||
Fortunately, around about v0.7.5 a "property manager" was implemented,
|
||||
which facilitated being able to set the parameters for the joystick at runtime.
|
||||
Version 0.7.7 saw an expanded role for the property manager and the
|
||||
addition of a "command manager" that allows for binding of events to commands.
|
||||
The code that does this is known as FGInput and is used to configure
|
||||
keyboard command bindings as well as joysticks.
|
||||
</p>
|
||||
<p>Version 0.7.9 added a compiled decision tree allowing for conditionals
|
||||
to be used.
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="first_things">First Things First:</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
|
||||
<p>
|
||||
I will cover joysticks first and save the keyboard stuff for later.
|
||||
FGInput treats things in a generic enough way that the line between
|
||||
joystick buttons and keyboard events starts to blur.
|
||||
</p>
|
||||
<p>
|
||||
Storing alternate keyboard or joystick bindings can be done in a variety of ways. The order of precedence for options is thus:
|
||||
</p>
|
||||
|
||||
<TABLE CELLPADDING="8"><TR><Th>
|
||||
Source</th><th>Location</TH><th> Format</th><th> Scope</th></tr>
|
||||
<tr><td>command line</td><td>STDIN</td><td>see examples</td><td>session</td></tr><tr>
|
||||
<td>.fgfsrc</td><td>Users home directory.</td><td>command line options</td><td> single user</td></tr>
|
||||
<tr><td>system.fgfsrc</td><td>$FG_ROOT</td><td>command line options</td><td>system wide</td></tr>
|
||||
<tr><td>joystick.xml</td><td>$FG_ROOT</td><td>XML property list</td><td>system wide</td></tr>
|
||||
<tr><td>keyboard.xml</td><td>$FG_ROOT</td><td>XML property list</td><td>system wide</td><tr></table>
|
||||
|
||||
</p><p>
|
||||
|
||||
|
||||
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="xml">About XML:</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
|
||||
<p>
|
||||
In case you were wondering, XML stands for eXtensible Markup Language.
|
||||
It looks a lot like HTML, except you get to define your own tags. Well,
|
||||
in the case of FGFS we defined the tags you need to configure things.
|
||||
It is well suited for describing hierarchically organized structures, such as
|
||||
the property tree FGFS uses to expose the it's innards to external applications.
|
||||
Your XML configuration files for FGFS must start and end with the following
|
||||
pair of tags.
|
||||
</p>
|
||||
|
||||
<tt>
|
||||
<PropertyList><br>
|
||||
<!-- this is a comment, See I told you it was like HTML --><br>
|
||||
</PropertyList><br>
|
||||
</tt>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="output">Determining your joystick output:</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
|
||||
<p>
|
||||
FlightGear ships with a utility called js_demo. It will report
|
||||
the number of joysticks attached to a system and their capabilites.
|
||||
By observing the output of js_demo while working your joystick you can
|
||||
determine what controls are where.
|
||||
It should be noted that, at least on UNIX, numbering generally starts with
|
||||
zero. In the following example the system has 1 joystick (js0) connected.
|
||||
The output shown is from an analog Gravis BlackHawk with four buttons and
|
||||
a throttle.
|
||||
</p>
|
||||
|
||||
Typical output of js_demo:<br>
|
||||
<br>
|
||||
<tt>
|
||||
<table><tr><td colspan="7">Joystick test program.<br>
|
||||
~~~~~~~~~~~~~~~~~~~~~~</td></tr>
|
||||
<tr><td colspan="2">Joystick 1</td>
|
||||
<td colspan="1">not detected</td>
|
||||
<td colspan="4"><!-- remember we start at 0 --></td></tr>
|
||||
<tr><td colspan="2">Joystick 2</td>
|
||||
<td colspan="5">not detected</td><tr><td>
|
||||
<tr><td colspan="7">
|
||||
+---------------------JS.0-------------------+</td></tr>
|
||||
<tr><td>|</td>
|
||||
<td> Btns</td>
|
||||
<td> Ax:0</td>
|
||||
<td> Ax:1</td>
|
||||
<td> Ax:2</td>
|
||||
<td></td>
|
||||
<td align=right>|</td></tr>
|
||||
<tr><td colspan="7">
|
||||
+-------------------------------------------+</td></tr>
|
||||
<tr><td>|</td>
|
||||
<td>0000</td>
|
||||
<td>+0.0</td>
|
||||
<td>+0.0</td>
|
||||
<td>-1.0</td>
|
||||
<td>. . .</td>
|
||||
<td align=right>|</td>
|
||||
</tr>
|
||||
</table>
|
||||
</tt>
|
||||
<P>
|
||||
The buttons are handled internally as a binary number in which bit 0 (the
|
||||
least significant bit) represents button 0, bit 1 represents button 1, etc.,
|
||||
but this number is displayed on the screen in hexadecimal notation, so:
|
||||
<br>
|
||||
<br>
|
||||
0001 => button 0 pressed<br>
|
||||
0002 => button 1 pressed<br>
|
||||
0004 => button 2 pressed<br>
|
||||
0008 => button 3 pressed<br>
|
||||
0010 => button 4 pressed<br>
|
||||
0020 => button 5 pressed<br>
|
||||
0040 => button 6 pressed<br>
|
||||
... etc. up to ...<br>
|
||||
8000 => button 15 pressed<br>
|
||||
... and ...<br>
|
||||
0014 => buttons 2 and 4 pressed simultaneously<br>
|
||||
... etc.<br>
|
||||
</P>
|
||||
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="default">Default Joystick Properties:</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
|
||||
<table width="350">
|
||||
<tr><td>Axis 0</td><td>=</td><td>Aileron</td></tr>
|
||||
<tr><td>Axis 1</td><td>=</td><td>Elevator</td></tr>
|
||||
<tr><td>Axis 2</td><td>=</td><td>Rudder</td></tr>
|
||||
<tr><td>Axis 3</td><td>=</td><td>Throttle</td></tr>
|
||||
<tr><td>Button 0</td><td>=</td><td>All brakes</td></tr>
|
||||
<tr><td>Button 1</td><td>=</td>Elevator trim (up)</td></tr>
|
||||
<tr><td>Button 2</td><td>=</td>Elevator trim (down)</td></tr>
|
||||
</table>
|
||||
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="okay">Okay, Now what?</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
<p>
|
||||
Now that you know what the output of the devices connected to the joystick
|
||||
port (or USB port joystick devices) is, you probably want to dive straight
|
||||
in and to start connecting to FGInput. If you are familiar with configuring
|
||||
the joystick on versions of FGFS prior to 0.7.7 you can skip down to the
|
||||
section <A HREF="#command_manager">"The Command Manager"</A>.
|
||||
</P>
|
||||
<P>
|
||||
If you are a new FGFS user, you should at least skim the next bit since it
|
||||
explains some concepts you may or may not know. It also covers some legacy
|
||||
joystick options which have not been implemented yet in the context of the
|
||||
command manager.
|
||||
</p>
|
||||
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="modifiers">Modifiers For Raw Joystick Values</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
|
||||
<p>
|
||||
These concepts are expressed by supplying arguments to the joystick bindings.
|
||||
The raw values coming from the joystick axes may not be suitable to use directly.
|
||||
For that matter not all joysticks are created equal so understanding the basic
|
||||
concepts should save you some time when experimenting to get the best performance.
|
||||
</P>
|
||||
<P>
|
||||
The full order of precedence for axis properties is
|
||||
</P>
|
||||
<P>
|
||||
1. The raw axis value ...<BR>
|
||||
2. is filtered by dead-band, ... (deadband is implemented outside the command manager.)<BR>
|
||||
3. then adjusted to offset, ...<BR>
|
||||
4. then multiplied by factor, ...<BR>
|
||||
5. the resulting value is assigned to the FlightGear control property.<BR>
|
||||
<BR>
|
||||
Put another way....<BR>
|
||||
<BR>
|
||||
cooked_value = (( raw_value > dead-band ) + offset) * factor<BR>
|
||||
<BR>
|
||||
|
||||
|
||||
Axis properties:<br>
|
||||
<br>
|
||||
<table><tr><th colspan="3">dead-band</th></tr>
|
||||
<tr><td>-1</td><td> 0</td><td>1</td></tr>
|
||||
<tr><td colspan="3"> ..............................</td></tr>
|
||||
<tr><td>-1</td><td>| |</td></td>1</td></tr>
|
||||
<tr><td></td><td> ^</td><td></td></tr>
|
||||
<tr><td colspan="3" align="center">dead-band</td</tr>
|
||||
</table>
|
||||
|
||||
<P>
|
||||
This is an area where signals are ignored. It is used to compensate
|
||||
for noise, or potentiometers of dubious quality by creating a threshold
|
||||
below which any signal is suppressed. dead-band is relative to zero.
|
||||
</P>
|
||||
<P>
|
||||
The default of 0.1 for elevators and ailerons is very forgiving. A lower
|
||||
number results in a tighter feel. In some cases such as throttle you may
|
||||
wish to not set a deadband. Use a value of 0.0 in this case.
|
||||
</P>
|
||||
|
||||
<table><tr><th colspan="3">offset</th></tr>
|
||||
<tr><td>-1 0</td><td> </td><td>1</td><tr>
|
||||
<tr><td colspan="3"> .............................</td></tr>
|
||||
<tr><td>-1 ^</td><td> </td><td>1</td></tr>
|
||||
<tr><td colspan="3" align="center">offset</td></tr>
|
||||
</table>
|
||||
|
||||
<P>
|
||||
Used to maximize a controls use of it's axis, as in the case of a
|
||||
throttle where zero would be a minimum and not a center point like in the case
|
||||
of a rudder. Typical value -1.0.
|
||||
</P>
|
||||
<table><tr><th>tolerance</th></tr></table>
|
||||
<P>
|
||||
Used to compensate for jittery potentiometer output, tolerance is in essence
|
||||
a gate. Amounts of movement below the threshold are ignored. Unlike dead-band,
|
||||
tolerance is relative to where ever the axis is at rest.
|
||||
|
||||
<table><tr><th>factor</th></tr></table>
|
||||
<P>
|
||||
Controls proportional movement of an axis. If the factor is too low it results in control not reaching its maximum possible limit. Negating the number will result in the control moving counter to the default. The default value is 1.0, think unity gain.
|
||||
</P>
|
||||
<P>
|
||||
In my case, throttle behavior was inverted from what I preferred.
|
||||
I set this value to -1.0 and everything was groovy.
|
||||
</p>
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="command_manager">The Command Manager:</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
|
||||
<p>
|
||||
Previous versions of FGFS allowed joystick output to be bound directly
|
||||
to the property manager. This has changed for FGFS v0.7.7 and now events
|
||||
are bound to commands. Commands *must* be specified for a binding to have
|
||||
an effect. The current list of commands is broken down here into two
|
||||
categories, mainly for my convenience.
|
||||
</P>
|
||||
<P>
|
||||
Visual And File Related:
|
||||
</P>
|
||||
|
||||
<table><tr><th>command</th><th>options</th><th>used for</th></tr>
|
||||
<tr><th>-------</th><th>-------</th><th>--------</th></tr>
|
||||
<tr><td>null</td><td>none</td><td>useful for clearing a previous binding</td></tr>
|
||||
<tr><td>exit</td><td>none</td><td>Exiting FGFS</td></tr>
|
||||
<tr><td>load</td><td>file name*</td><td>Load a saved flight</td></tr>
|
||||
<tr><td>save</td><td>file name*</td><td>Save current flight</td></tr>
|
||||
<tr><td>load-panel</td><td>path **</td><td>Change/reload panel</td></tr>
|
||||
<tr><td>load-preferences</td><td>path **</td><td>Load preferences ***</td></tr>
|
||||
<tr><td>screen-capture</td><td>none</td><td>Save a screenshot to ./fgfs-screen.ppm</td></tr>
|
||||
<tr><td>view-cycle</td><td>none</td><td>Change the direction of the pilots view</td></tr>
|
||||
</table>
|
||||
<tt>
|
||||
*Saved/loaded relative to current working directory.<br>
|
||||
**The path includes the filename you wish to load and is relative to $FG_ROOT,
|
||||
which is the location of the installed base package. The default for load-panel
|
||||
is the value of /sim/panel/path (from preferences.xml) or if that is unset
|
||||
Panel/Default/default.xml. The default for load preferences is preferences.xml.
|
||||
<br>
|
||||
***This might make a good first binding to experiment with, since it's not currently
|
||||
bound to anything. Reloading preferences will allow you to test settings
|
||||
without having to sit through a restart of FGFS for every edit. You can
|
||||
always (re)move it later.
|
||||
</TT>
|
||||
<P>
|
||||
Flight Control:
|
||||
</P>
|
||||
<table><tr><th>command</th><th>options</th><th>effect</th></tr>
|
||||
<tr><th>-------</th><th>-------</th><th>------</th></tr>
|
||||
<tr><td>property-toggle</td><td> property</td><td>toggle the property full on</td></tr>
|
||||
<tr><td>property-assign</td><td>"" "", value</td><td>targets a property for action</td></tr>
|
||||
<tr><td>property-adjust</td><td>"" "", step</td><td>Increment size for changes</td></tr>
|
||||
<tr><td>property-swap</td><td>"" ""[0], "" ""[1]</td><td>Set values in a switch</td></tr>
|
||||
<tr><td>property-scale</td><td>"" "", offset, factor</td><td>Processes the raw joystick value</td></tr>
|
||||
</table>
|
||||
|
||||
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="bindings">Bindings:</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
<p>
|
||||
|
||||
A command may have more than one binding. By default, the examples below
|
||||
use just /binding or <binding>, but /binding[0] or <binding n="0"> is implied.
|
||||
When bindings are specified in XML the indices are created automagically. If
|
||||
you wish to avoid XML you must supply the index number for multiple bindings
|
||||
in your command line formatted options.
|
||||
</P>
|
||||
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="axes">Joystick Axes:</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
|
||||
<p>
|
||||
Here's a sample Joystick axis declaration in XML:
|
||||
</p>
|
||||
<TT>
|
||||
|
||||
<axis n="0"> <!-- target an axis --><br>
|
||||
<desc>Aileron</desc> <!-- descriptive name (optional) --><br>
|
||||
<binding> <!-- open a container for the binding --><br>
|
||||
<command>property-scale</command> <!-- pick a command --><br>
|
||||
<property>/controls/aileron</property> <!-- target a property --><br>
|
||||
</binding> <!-- closing tag for binding --><br>
|
||||
</axis> <!-- closing tag for axis --><br>
|
||||
|
||||
</TT>
|
||||
<P>
|
||||
Remember how I said the property tree was a hierarchy? Thoughtful readers
|
||||
will notice how the nested tags keep things organized.
|
||||
This binding appears in the context /input/joysticks/js/, so the
|
||||
command-line option equivalent of this declaration (leaving out the
|
||||
'desc', which isn't strictly necessary), is
|
||||
</P>
|
||||
<TT>
|
||||
--prop:/input/joysticks/js[0]/axis[0]/binding/command=property-scale
|
||||
--prop:/input/joysticks/js[0]/axis[0]/binding/property=/controls/aileron
|
||||
</TT>
|
||||
<P>
|
||||
Do you see how the command line versions uses a path to represent the hierarchy?
|
||||
Cool! You should read README.xmlpanel next, working with FGFS XML configuration
|
||||
system is easy and it's fun for the whole family! ( not sold in stores. excludes
|
||||
tax and title. void where prohibited by law.)
|
||||
</P>
|
||||
<P>
|
||||
Ok, back to business. The 'property-scale' command also recognizes 'offset' and
|
||||
'factor' arguments. The "type" arguments shown in the following example are
|
||||
specifying a double precision floating point number. A double has more discrete
|
||||
steps and gives a smoother action than a plain float.
|
||||
</P>
|
||||
<tt>
|
||||
|
||||
<axis n="2"><br>
|
||||
<desc>Throttle</desc><br>
|
||||
<!-- See important note about dead-band below --><br>
|
||||
<binding><br>
|
||||
<command>property-scale</command><br>
|
||||
<property>/controls/throttle</property><br>
|
||||
<offset type="double">-1.0</offset><br>
|
||||
<factor type="double">-0.5</factor><br>
|
||||
</binding><br>
|
||||
</axis></tt>
|
||||
<br>
|
||||
<br>
|
||||
or
|
||||
<br>
|
||||
<br>
|
||||
<tt>
|
||||
--prop:/input/joysticks/js[0]/axis[2]/binding/command=property-scale
|
||||
--prop:/input/joysticks/js[0]/axis[2]/binding/property=/controls/throttle
|
||||
--prop:/input/joysticks/js[0]/axis[2]/binding/offset=-1.0
|
||||
--prop:/input/joysticks/js[0]/axis[2]/binding/factor=-0.5
|
||||
</tt>
|
||||
|
||||
<p>
|
||||
*Important Note About dead-band*<br>
|
||||
--------------------------------
|
||||
</P>
|
||||
|
||||
<P>
|
||||
You may recall from the section about raw axis value modifiers that dead-band
|
||||
is implemented outside the command manager. This means that if you want to apply
|
||||
a dead-band, the tag *must* precede the binding tag. If you are using the command
|
||||
line format you must omit the 'binding' part like so:
|
||||
</P>
|
||||
|
||||
<TT>
|
||||
--prop:/input/joysticks/js[0]/axis[2]/dead-band=0.005
|
||||
</tt>
|
||||
|
||||
<br><br>
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="buttons">Joystick Button Properties:</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
|
||||
<p>
|
||||
Buttons, being boolean by nature, can use a little help. By this I mean that there are times when you need momentary action, times where you need a repeating action and sometimes you just want a plain old toggle. In order to facilitate this need we have some tags that modify the actions of buttons.
|
||||
</P>
|
||||
|
||||
<TT>
|
||||
|
||||
<repeatable><br>
|
||||
<!-- Will be either true or false. If it is true, holding down a button (or key) will cause repeated events, say, for moving the trim; if false (the default), pressing a key will cause only a single event. --><br>
|
||||
<br>
|
||||
<step><br>
|
||||
<!-- The property-adjust command takes a 'step' argument specifying the amount of the adjustment for each event. In the following example, the elevator trim moves 0.1% for each event (without automatic repetition, you'd have a pretty sore finger). --><br>
|
||||
<br>
|
||||
<value><br>
|
||||
<!-- Use value on non-repeatables to supply the value for each consecutive press--><br><br>
|
||||
<mod-up><br>
|
||||
<!-- This stands for "modifier up", my favorite I think. This is used to set up a binding for when you *release* a key. As you'll see, it comes in handy --><br><br>
|
||||
</TT>
|
||||
|
||||
<P>
|
||||
Here's a sample joystick button declaration in XML:
|
||||
</P>
|
||||
|
||||
<TT>
|
||||
<button n="1"> <!-- target a button --><br>
|
||||
<desc>Elevator trim up</desc> <!-- optional description --><br>
|
||||
<repeatable>true</repeatable> <!-- Ok, repeatable is outside the command manager too --><br>
|
||||
<binding> <!-- Open the "binding" node of the tree--><br>
|
||||
<command>property-adjust</command> <!-- pick a command type to bind --><br>
|
||||
<property>/controls/elevator-trim</property> <!-- target a property --><br>
|
||||
<step type="double">0.001</step><br>
|
||||
</binding><br>
|
||||
</button><br>
|
||||
|
||||
</tt>
|
||||
<P>
|
||||
In command-line option syntax, this would appear as
|
||||
</P>
|
||||
<TT>
|
||||
--prop:/input/joysticks/js[0]/button[1]/repeatable=true <-- See? no 'binding' --><br>
|
||||
--prop:/input/joysticks/js[0]/button[1]/binding/command=property-adjust<br>
|
||||
--prop:/input/joysticks/js[0]/button[1]/binding/property=/controls/elevator-trim<br>
|
||||
--prop:/input/joysticks/js[0]/button[1]/binding//step=0.001<br>
|
||||
</TT>
|
||||
<P>
|
||||
Here's a slightly fancier declaration, that applies the left (differential) brakes
|
||||
when button 4 is pressed, and releases them automatically when the user releases the
|
||||
button:
|
||||
</P>
|
||||
<TT>
|
||||
<button n="4"><br>
|
||||
<desc>Left brake</desc><br>
|
||||
<binding><br>
|
||||
<command>property-assign</command><br>
|
||||
<property>/controls/brakes[0]</property><br>
|
||||
<value type="double">1.0</value> <!-- brakes are a toggle so 1.0 represents on --><br>
|
||||
</binding><br>
|
||||
<mod-up> <!-- it's not a parking brake so we need to release it --><br>
|
||||
<binding><br>
|
||||
<command>property-assign</command><br>
|
||||
<property>/controls/brakes[0]</property><br>
|
||||
<value type="double">0.0</value> <!-- 1.0 is on so 0.0 is off, right? --><br>
|
||||
</binding><br>
|
||||
</mod-up><br>
|
||||
</button><br>
|
||||
</TT>
|
||||
<p>
|
||||
The first binding is straight-forward: when the button is pressed, the
|
||||
'property-assign' command assigns the value 1.0 (i.e. full) to the left brake
|
||||
property. The second binding, however, is nested inside a 'mod-up' element,
|
||||
it will be fired when the user *releases* the button, and will use the
|
||||
'property-assign' command to assign the value 0.0 (i.e. none) to the left brake
|
||||
property. Repetition is left at the default value of false, so that the same
|
||||
value will not be assigned over and over again.
|
||||
</P>
|
||||
<P>
|
||||
Here's the command-line equivalent:
|
||||
</p>
|
||||
<TT>
|
||||
--prop:/input/joysticks/js[0]/button[4]/binding/command=property-assign
|
||||
--prop:/input/joysticks/js[0]/button[4]/binding/property=/controls/brakes[0]
|
||||
--prop:/input/joysticks/js[0]/button[4]/binding/value=1.0
|
||||
--prop:/input/joysticks/js[0]/button[4]/mod-up/binding/command=property-assign
|
||||
--prop:/input/joysticks/js[0]/button[4]/mod-up/binding/property=/controls/brakes[0]
|
||||
--prop:/input/joysticks/js[0]/button[4]/mod-up/binding/value=0.0
|
||||
</TT>
|
||||
<P>
|
||||
Remember that more than one binding can be included in each context. Here's a
|
||||
very hairy example from the default bindings that fires all three brakes when
|
||||
button 0 is pressed, and releases all three when button 0 is released:
|
||||
</P>
|
||||
|
||||
<TT>
|
||||
<button n="0"><br>
|
||||
<desc>Brakes</desc><br>
|
||||
<binding><br>
|
||||
<command>property-assign</command><br>
|
||||
<property>/controls/brakes[0]</property><br>
|
||||
<value type="double">1.0</value><br>
|
||||
</binding><br>
|
||||
<binding><br>
|
||||
<command>property-assign</command><br>
|
||||
<property>/controls/brakes[1]</property><br>
|
||||
<value type="double">1.0</value><br>
|
||||
</binding><br>
|
||||
<binding><br>
|
||||
<command>property-assign</command><br>
|
||||
<property>/controls/brakes[2]</property><br>
|
||||
<value type="double">1.0</value><br>
|
||||
</binding><br>
|
||||
<mod-up><br>
|
||||
<binding><br>
|
||||
<command>property-assign</command><br>
|
||||
<property>/controls/brakes[0]</property><br>
|
||||
<value type="double">0.0</value><br>
|
||||
</binding><br>
|
||||
<binding><br>
|
||||
<command>property-assign</command><br>
|
||||
<property>/controls/brakes[1]</property><br>
|
||||
<value type="double">0.0</value><br>
|
||||
</binding><br>
|
||||
<binding><br>
|
||||
<command>property-assign</command><br>
|
||||
<property>/controls/brakes[2]</property><br>
|
||||
<value type="double">0.0</value><br>
|
||||
</binding><br>
|
||||
</mod-up><br>
|
||||
</button><br>
|
||||
</TT>
|
||||
<p>
|
||||
For people who take pleasure in avoiding XML, here's the command-line
|
||||
equivalent (note the subscripts to distinguish multiple bindings; the
|
||||
XML will handle this automatically):
|
||||
</P>
|
||||
<TT>
|
||||
--prop:/input/joysticks/button[0]/binding[0]/command=property-assign
|
||||
--prop:/input/joysticks/button[0]/binding[0]/property=/controls/brakes[0]
|
||||
--prop:/input/joysticks/button[0]/binding[0]/value=1.0
|
||||
--prop:/input/joysticks/button[0]/binding[1]/command=property-assign
|
||||
--prop:/input/joysticks/button[0]/binding[1]/property=/controls/brakes[1]
|
||||
--prop:/input/joysticks/button[0]/binding[1]/value=1.0
|
||||
--prop:/input/joysticks/button[0]/binding[2]/command=property-assign
|
||||
--prop:/input/joysticks/button[0]/binding[2]/property=/controls/brakes[2]
|
||||
--prop:/input/joysticks/button[0]/binding[2]/value=1.0
|
||||
--prop:/input/joysticks/button[0]/mod-up/binding[0]/command=property-assign
|
||||
--prop:/input/joysticks/button[0]/mod-up/binding[0]/property=brakes[0]
|
||||
--prop:/input/joysticks/button[0]/mod-up/binding[0]/value=0.0
|
||||
--prop:/input/joysticks/button[0]/mod-up/binding[1]/command=property-assign
|
||||
--prop:/input/joysticks/button[0]/mod-up/binding[1]/property=brakes[1]
|
||||
--prop:/input/joysticks/button[0]/mod-up/binding[1]/value=0.0
|
||||
--prop:/input/joysticks/button[0]/mod-up/binding[2]/command=property-assign
|
||||
--prop:/input/joysticks/button[0]/mod-up/binding[2]/property=brakes[2]
|
||||
--prop:/input/joysticks/button[0]/mod-up/binding[2]/value=0.0
|
||||
</TT>
|
||||
|
||||
<P>
|
||||
This is a good time to remind you that command line formatted options are used
|
||||
in your .fgfsrc file. You can put them in $FG_ROOT/system.fgfsrc to make them
|
||||
global.
|
||||
</P>
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="coolie_hat">Digital Coolie Hats:</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
<p>
|
||||
Many common joysticks come with digital coolie hats. These are detected as
|
||||
axes rather than as buttons, although they are in fact just four (or eight)
|
||||
simple switches. FGFS provides 2 virtual buttons to every axis which are
|
||||
triggered whenever the axis reaches one of the end positions. These virtual
|
||||
buttons can be addressed via two sub-properties »low« and »high« and accept any
|
||||
of the common button properties.
|
||||
</P>
|
||||
<P>
|
||||
For example, if you just want to control view direction, you can map two of the
|
||||
axes to /sim/view/axes/long and /sim/view/axes/lat:
|
||||
</P>
|
||||
<TT>
|
||||
--prop:/input/joysticks/js/axis[5]/binding/command=property-scale
|
||||
--prop:/input/joysticks/js/axis[5]/binding/property=/sim/view/axes/lat
|
||||
|
||||
--prop:/input/joysticks/js/axis[6]/binding/command=property-scale
|
||||
--prop:/input/joysticks/js/axis[6]/binding/property=/sim/view/axes/long
|
||||
</tt>
|
||||
<p>
|
||||
If you want to use them as buttons (say, to scroll the panel
|
||||
vertically or horizontally), you can use the high/low bindings.
|
||||
Here's an example of how to use an axis to adjust the elevator trim:
|
||||
</P>
|
||||
<TT>
|
||||
--prop:/input/joysticks/js/axis[1]/low/repeatable=true
|
||||
--prop:/input/joysticks/js/axis[1]/low/binding/command=property-adjust
|
||||
--prop:/input/joysticks/js/axis[1]/low/binding/property=/controls/elevator-trim
|
||||
--prop:/input/joysticks/js/axis[1]/low/binding/step=0.001
|
||||
|
||||
--prop:/input/joysticks/js/axis[1]/high/repeatable=true
|
||||
--prop:/input/joysticks/js/axis[1]/high/binding/command=property-adjust
|
||||
--prop:/input/joysticks/js/axis[1]/high/binding/property=/controls/elevator-trim
|
||||
--prop:/input/joysticks/js/axis[1]/high/binding/step=-0.001
|
||||
</TT>
|
||||
<P>
|
||||
You could also bind some axes to brakes, so that you can use positions
|
||||
between between 0.0 (no brakes) and 1.0 (full brakes).
|
||||
</P>
|
||||
|
||||
<HR WIDTH="20%">
|
||||
<H2><A NAME="keyboard">Keyboard Bindings:</A></H2>
|
||||
<HR WIDTH="20%">
|
||||
<p>
|
||||
Keyboard bindings are almost exactly identical to joystick-button
|
||||
bindings, as in the following example (the context is
|
||||
/input/keyboard):
|
||||
</P>
|
||||
<TT>
|
||||
<key n="1"><br>
|
||||
<name>Ctrl-A</name><br>
|
||||
<desc>Toggle autopilot altitude lock.</desc><br>
|
||||
<binding><br>
|
||||
<command>property-toggle</command><br>
|
||||
<property>/autopilot/locks/altitude</property><br>
|
||||
</binding><br>
|
||||
</key><br>
|
||||
</TT>
|
||||
|
||||
<P>
|
||||
There are a few gotcha's though. First, the index of the key
|
||||
specifies the key code that you're binding; in the above example, '1'
|
||||
corresponds to Ctrl-A (as mentioned in the friendly comment). Regular
|
||||
key codes go up to 255; codes from 256 up represent special keys like
|
||||
function and arrow keys (you can get the value from include/GL/glut.h,
|
||||
but adding 256 to the special key code). Here is the command-line
|
||||
equivalent of the above, leaving out the documentation properties:
|
||||
</P>
|
||||
<TT>
|
||||
--prop:/input/keyboard/key[1]/binding/command=property-toggle
|
||||
--prop:/input/keyboard/key[1]/binding/property=/autopilot/locks/altitude
|
||||
</TT>
|
||||
<p>
|
||||
(The 'property-toggle' command switches a boolean value between true and
|
||||
false, so it needs no arguments except for the property name.) DON'T
|
||||
LEAVE OUT THE INDEX!!!
|
||||
</P>
|
||||
<P>
|
||||
The second gotcha is that keys can take more modifiers than joystick
|
||||
buttons. In addition to mod-up (representing the key release), a key
|
||||
may use any combination of nested 'mod-alt', 'mod-ctrl', and
|
||||
'mod-shift' modifiers, as in the following example:
|
||||
</P>
|
||||
<TT>
|
||||
<key n="49"><br>
|
||||
<name>1</name><br>
|
||||
<mod-shift><br>
|
||||
<desc>Look back left</desc><br>
|
||||
<binding><br>
|
||||
<command>property-assign</command><br>
|
||||
<property>/sim/view/goal-offset</property><br>
|
||||
<value type="double">135</value><br>
|
||||
</binding><br>
|
||||
</mod-shift><br>
|
||||
</key><br>
|
||||
</TT>
|
||||
</P>
|
||||
<P>
|
||||
In this example, the '1' key combined with shift causes the view to
|
||||
switch to back left. Note that this will work only with the keypad 1,
|
||||
since pressing shift+1 on the regular keyboard will give a '!'
|
||||
character instead.
|
||||
</P>
|
||||
<P>
|
||||
The input module tries to be smart about supplying control and shift
|
||||
modifiers automatically where they make sense -- note that it wasn't
|
||||
necessary to use a nested 'mod-ctrl' element for the ctrl-A binding
|
||||
earlier, since a keycode less that 32 implies a control character
|
||||
anyway.
|
||||
</P>
|
||||
<P>
|
||||
With the new input module, the key-up events can also be detected for
|
||||
the keyboard, so it's possible to have touch-sensitive brakes (etc.)
|
||||
just as with the joystick:
|
||||
</P>
|
||||
<TT>
|
||||
<key n="44"><br>
|
||||
<name>,</name><br>
|
||||
<desc>Left brake</desc><br>
|
||||
<binding><br>
|
||||
<command>property-assign</command><br>
|
||||
<property>/controls/brakes[0]</property><br>
|
||||
<value type="double">1.0</value><br>
|
||||
</binding><br>
|
||||
<mod-up><br>
|
||||
<binding><br>
|
||||
<command>property-assign</command><br>
|
||||
<property>/controls/brakes[0]</property><br>
|
||||
<value type="double">0.0</value><br>
|
||||
</binding><br>
|
||||
</mod-up><br>
|
||||
</key><br>
|
||||
</TT>
|
||||
<P>
|
||||
Now here is a different way to bind a brake. In this example, there is
|
||||
no <mod-up> tag, so it *does* work like a parking brake.
|
||||
</P>
|
||||
|
||||
<TT>
|
||||
<key n="66"> <br>
|
||||
<name>B</name><br>
|
||||
<desc>Toggle parking brake on or off</desc><br>
|
||||
<binding><br>
|
||||
<command>property-toggle</command><br>
|
||||
<property>/controls/brakes[0]</property><br>
|
||||
</binding><br>
|
||||
<binding><br>
|
||||
<command>property-toggle</command><br>
|
||||
<property>/controls/brakes[1]</property><br>
|
||||
</binding><br>
|
||||
<binding><br>
|
||||
<command>property-toggle</command><br>
|
||||
<property>/controls/brakes[2]</property><br>
|
||||
</binding><br>
|
||||
</key><br>
|
||||
</TT>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
@ -16,7 +16,7 @@
|
|||
<span class="ptmbi7t-">FlightGear</span>. It includes:
|
||||
<!--l. 55--><p class="indent"> <a href="FGShortRef.html" >Short reference including key codes</a>
|
||||
<p class="indent"> <a href="FGShortRef.pdf" >Short reference in PDF format (makes a nice printout)</a>
|
||||
<p class="indent"> <a href="README.Joystick" >Guide to joystick and keyboard configuration</a>
|
||||
<p class="indent"> <a href="README.Joystick.html" >Guide to joystick and keyboard configuration</a>
|
||||
<p class="indent"> <a href="FlightGear-FAQ.html" >Frequently asked questions</a>
|
||||
<!--l. 58--><p class="indent"> <a href="InstallGuide/html/getstart.html" >The Complete User's Guide</a>
|
||||
<!--l. 61--><p class="indent">Information for power users.
|
||||
|
|
|
|||
Loading…
Reference in a new issue