BMS Key File Manual
BMS Key File Manual
Author: KOLBE
FOREWORD
PURPOSE AND SCOPE
I found it always pretty hard to go through the key settings to find a specific function. In most cases it’s due to
lack of clarity and a missing segmentation. For this reason I decided to create a new keystroke file from scratch.
Many did it before, but the output was not really suitable for me (and maybe others). But while continuing my
work, I realized that there are even more things to do. E.g. the keyboard layout.
Since the beginning of community modded Falcon versions we are using more or less the same key settings. If you
take a closer look at the keyboard layout (even in BMS) you may realize, that the settings are not very logical. So I
decided to revamp the key layout as well.
The main idea behind this project was to categorize the key file by using „headlines“ and strict naming
conventions. It should be easily possible to navigate through the key file and to find things quickly. Therefore the
description of each callback is following some rules which will be described below.
This manual shall give you a basic understanding of how key files work. All available and necessary information
are part of this document. If you follow the instructions you should be able to create your own key file without
any major obstacles.
I hope you find my work useful. You might also take a look at the other documents. If you have any suggestions or
found mistakes, please contact me.
This work is not yet finished. It is very likely that the input system will be updated in the future. Updates and news
are announced and discussed in the following forum thread:
Forum Link
Please use this forum also if you have questions, remarks or found a bug.
I apologize for any mistakes (maybe phrase or spelling) I made. English is not my native language. But I gave my
very best
Thanks to DragonFly (49th), Dunc and Boxer (BMS) for reviewing this document and the key files.
Have fun…
Kolbe
1-2
BMS KEY FILE MANUAL
CHANGE 1
1 TABLE OF CONTENTS
1 TABLE OF CONTENTS ................................................................................................................ 1-3
2 Categories & Sections: ............................................................................................................... 2-6
2.1 Category and Section code lines............................................................................................................... 2-6
2.1.1 Key File Description (Key file content / UI output): .......................................................................... 2-6
2.1.2 Category example (Key file content / UI output): ............................................................................ 2-6
2.1.3 Section example (Key file content / UI output): ............................................................................... 2-6
2.1.4 Separators......................................................................................................................................... 2-6
2.2 Non category & section lines in the UI: .................................................................................................... 2-7
2.2.1 Non changeable keys example (Key file content / UI output): ......................................................... 2-7
2.2.2 Changeable keys example (Key file content / UI output): ................................................................ 2-7
2.2.3 Invisible keys example (Key file content / UI output):...................................................................... 2-7
3 The Terms: ................................................................................................................................... 3-8
3.1 First Term:................................................................................................................................................. 3-8
3.2 Second Term: ............................................................................................................................................ 3-9
3.3 Third Term: ............................................................................................................................................... 3-9
3.4 Upper case vs. lower case: ..................................................................................................................... 3-11
3.5 Keys vs. Mouse (right / left click, scroll wheel):...................................................................................... 3-11
4 Overview categories & sections:...............................................................................................4-12
5 Key files - general info: ..............................................................................................................5-14
5.1 Deprecated & outdated / Dev callbacks: ................................................................................................ 5-14
5.2 TrackIR, Fraps & TeamSpeak: ................................................................................................................. 5-14
5.3 The key file profiles:................................................................................................................................ 5-15
5.4 Backup .................................................................................................................................................... 5-15
6 The inner working of key files ...................................................................................................6-16
6.1 Keyboard code lines................................................................................................................................ 6-16
6.1.1 First part: The callback .................................................................................................................... 6-16
6.1.2 Second part: Sound ID .................................................................................................................... 6-16
6.1.3 Third part: Not in use ...................................................................................................................... 6-17
6.1.4 Fourth part: Keyboard key .............................................................................................................. 6-17
6.1.5 Fifth part: Modifier key ................................................................................................................... 6-17
6.1.6 Sixth part: Key Combination key (Key Combo) ............................................................................... 6-18
6.1.7 Seventh part: Key combination modifier........................................................................................ 6-20
6.1.8 Eighth part: UI visibility ................................................................................................................... 6-20
6.1.9 Ninth part: UI description ............................................................................................................... 6-21
1-3
BMS KEY FILE MANUAL
CHANGE 1
1-4
BMS KEY FILE MANUAL
CHANGE 1
8.1 How to find out your DX device order and DX button IDs: .................................................................... 8-38
8.2 How To Avoid DX Device Order and Axis Changes ................................................................................. 8-39
9 DirectX device specifics: ...........................................................................................................9-41
9.1 How to cancel MRM/DF override Modes: .............................................................................................. 9-41
9.2 How to overcome DX button shortcomings? ......................................................................................... 9-41
10 Key file options & specifics: ................................................................................................10-43
10.1 Changing ICP-Numpad mapping (1=7 -> 7=1): ..................................................................................... 10-43
10.2 How to change the DX POV functions (Trim vs. View & other functions): ........................................... 10-43
10.3 Assigning keys to Extra MFDs (3rd & 4th MFD): ..................................................................................... 10-45
10.4 Double entries: ..................................................................................................................................... 10-45
11 Troubleshooting: ..................................................................................................................11-46
11.1 Why does BMS crash when loading a key file? .................................................................................... 11-46
11.2 Stuck key: .............................................................................................................................................. 11-46
11.3 How to enable EyeFly (Free Cam):........................................................................................................ 11-46
11.4 The mouse doesn’t work anymore in pit:............................................................................................. 11-47
11.5 Keyboard keys and combinations you have to be careful with:........................................................... 11-47
11.6 (Pretty) Screenshot vs. PrtScr: .............................................................................................................. 11-48
11.7 Why we don’t hear cockpit sounds when pressing a key:.................................................................... 11-49
12 Notes on the new pitbuilder key file: ...................................................................................12-50
12.1 General notes: ...................................................................................................................................... 12-50
12.2 Uncommented keyboard layout:.......................................................................................................... 12-51
12.3 Keyboard layout with comments: ........................................................................................................ 12-53
1-5
BMS KEY FILE MANUAL
CHANGE 1
The categories and sections are meant to act like a headline. Even in the newspapers you will look for the
headlines in the first place. Each category has a group of sections. As an example the LEFT CONSOLE is the
category of the following sections:
TEST PANEL, FLT CONTROL PANEL, MANUAL TRIM PANEL, FUEL PANEL etc.
The first key file code line, if set to -1, will be displayed as shown above. This is the description of the file to see at
a glance, which file is loaded.
The categories and sections are set to value -1, so they are visible in the UI, not changeable and with a blue
background color.
2.1.4 Separators
In the key file itself I used the following lines for easy navigation:
#========================================================================
They are set before and after each category and section. They are not shown in the UI, because they are
commented out. Unfortunately you will lose all commented stuff (with a # at the beginning) once you save the file
in the UI. So it is recommended to keep a backup of the original file.
2-6
BMS KEY FILE MANUAL
CHANGE 1
But after a while you should be able to navigate the key file easily without these borders. This feature is just for
those who are not familiar with editing keystroke files.
2-7
BMS KEY FILE MANUAL
CHANGE 1
The categories and sections follow basically the arrangement made by Red Dog. So you will start in the pit at the
rear left side, go to the front and then to the rear right side. But there are some differences. I sorted the callbacks
in the sections and the sections itself more logical and gave them more correct names.
For more info about the categories and sections see the overview farther below.
3 THE TERMS:
Due to the reason that the description line is limited to 37 characters, I had to accept some compromises. But in
most cases you will find the description as it was meant to be.
The description has been divided into three separate terms: 1. Term: 2. Term – 3. Term
2. Term: Correct designation of the switch / button / wheel / knob etc. followed by a dash.
3. Term: Correct designation of the positions / states of a switch / button etc., or: Short description of the
function
Examples:
In some cases it doesn’t make sense to divide the description into three terms. So you will also find descriptions
with only two terms. Then it will be like this: 1. Term: 3. Term
Examples:
If possible, this term has no more than 4 or 5 characters. But sometimes they have more.
Each first term is unique in the key file and describes only one section. So it is possible only to look at the first
term while scrolling down the key file in the UI. You will easily find what you need.
3-8
BMS KEY FILE MANUAL
CHANGE 1
For cockpit builders, you will often have things like „ON“, „OFF“ etc. But there are other functions of course (e.g.
Night vision on). To distinguish between different functions I used the following designations:
As long as you hold the button or switch, it is active. If you release the button or switch, it is inactive.
This one is also for functions which need a long input to become active. E.g. the EJECT Handle
Toggles through two (!) states of a switch, knob, button or function. Toggle forward and toggle back (E.g. ON /
OFF).
3-9
BMS KEY FILE MANUAL
CHANGE 1
This is meant to step between 3 or more states of a switch, function etc. Stepping up brings you to the last state
and ends there. Vice versa for step down.
(first position/ON – AUTO – OFF/last position) & (last position/OFF – AUTO – ON/first position)
It cycles a switch position up. When in the last position, it jumps automatically to the first position and so on.
(Vice versa for cycle down)
Same as above but only in one (!) direction. You cannot cycle in the opposite direction, because there is no
callback for it.
Incr. / Decr. is only used for knobs and wheels which change brightness, volume, degree values or pressure. It is
also used for FOV.
This is the pitbuilders playground. You will often find stuff like ON, OFF etc. There will be no further explanation of
what this switch is used for. It names only the specific state.
Function:
Describes a specific function, e.g. Sím Exit. Sometimes I had to keep the description short. So there are some short
forms. These are:
Tog. (Toggle)
Cyc. (Cycle)
Inc. (Increase)
Dec. (Decrease)
Dn (Down)
Btn. (Button)
3-10
BMS KEY FILE MANUAL
CHANGE 1
If the second term refers to a switch / button etc. in the cockpit, it is also written in upper case. (MAIN PWR /
PARKING BREAK…)
If the positions / states are referring to a corresponding switch / button etc in the Pit, it is written in upper case.
(ON / OFF / UP / DN…)
All other words only begin with a single upper case letter. (Increase / Toggle / Up…)
So what is the difference between UP and Up? It’s quite simple. Everything you can read in the Pit is written in
upper case completely.
For cycle, toggle and toggle up/down callbacks you have to use the right and left mouse button. (With some
exceptions)
3-11
BMS KEY FILE MANUAL
CHANGE 1
4-12
BMS KEY FILE MANUAL
CHANGE 1
4-13
BMS KEY FILE MANUAL
CHANGE 1
Important callbacks which you will need often are easy accessible. Cockpit callbacks are grouped panel by panel.
It is possible to perform a complete ramp start without using the mouse in the cockpit. The key settings are
optimized for HOTAS owners, especially TM Cougar.
TrackIR uses some keys by default. These are e.g. F8 (TrackIR precision) or more important F12 (TrackIR recenter).
These default keys along with BMS specific functions like TrackIR reload are incorporated into the key file.
Note: You can change the key for TrackIR Recenter at two different locations. The UI in BMS and the
TrackIR UI. In case of mapping two different keys for recenter, both will be working.
Regarding VoIP software like TeamSpeak (should be the most common), you don’t have default keys for PTT or
broadcast functionality. These keys have to be set manually in the TS UI. Nonetheless I decided to implement
them into my keyboard layout. You can see the key settings in my layout as suggestions. Of course you can map
them to any key you want. Another solution is, to set them as DX buttons. In this case you have to assign them in
TS settings. A proper place for them would be the same button on you HOTAS you have assigned VHF / UHF
Comms to.
Fraps is a commonly used tool for video capturing. Unfortunately the default keys are colliding with the default
keys of TrackIR. So you have to remap either the TIR or the Frap default keys.
Note: F9 (TIR Pause / FRAPS Video Capture) and F12 (TIR Recenter / FRAPS Overlay) are colliding. If
you use both you have to solve it by reassigning these keys in one tool to avoid issues.
Keep in mind that you have to set the keys directly in the software and NOT in BMS. Except for TrackIR reload and
TrackIR Recenter, all key settings for TrackIR and TS are mapped to the callback SimDoNothing, so you can find
them in both the key file itself and the keyboard layout.
5-14
BMS KEY FILE MANUAL
CHANGE 1
Full:
This is the full version of the key file with all callbacks.
Pitbuilder:
This version is for pit builders. All toggle / cycle callbacks for switches / knobs which have full state callbacks are
removed. The pitbuilders file has its own dedicated key assignments.
Basic:
This is the “light” version of the “Full” key file. All full state callbacks are removed. If you are not a pitbuilder and
use cycle / toggle functions instead, this is the file for you.
Minimum:
This key file contains only a small number of callbacks which are essential plus some additional functions for
comfort reasons. If you use the mouse in cockpit very often, this is most likely the right key file for you.
Blank:
This is the full key file without any key assignments (except hardcoded stuff, general comms and exit sim).
5.4 BACKUP
The key files are located in two different folders:
1. YourBMSInstallFolder/User/Config
All key files are also stored here to provide a backup in case you accidently screwed things up.
When editing key files you should always use the files in the User/Config folder. In case something went wrong
you can easily replace the faulty key file with a good one from the backup folder.
5-15
BMS KEY FILE MANUAL
CHANGE 1
Note: The parts are separated by a blank character (Spaces shown with a red underline here).
The first part assigns a specific BMS function to the code line. If you press the assigned keyboard key(s) it invokes
the callback function and the callback related action will be executed. So in our example if you press “G” on the
keyboard (0X22 = G) it toggles between gear up and gear down in the sim.
The callbacks itself are hardcoded and cannot be changed by the user. They could only be replaced by other
callbacks, which don’t make sense in a key file as we can simply assign other keyboard keys to this callback. (DX
code lines are another story and are described later).
You can find a complete set of all callbacks which are safe to use in my _full key file. Callbacks which are not listed
there are outdated / deprecated and should no longer be used as they will be most likely dropped in the future.
In the past the second part was used in 2D cockpits which we don’t have anymore. With the release of FBMS a 4-
digit sound ID could be assigned to invoke cockpit sounds when pressing the assigned key. The old 4-digit sound
IDs were referenced in the 16_ckpit.dat.
These 2d pit button IDs (4-digit numbers) are now outdated and don’t work anymore!
Now the second part serves as sound ID, which will be used directly from f4sndtbl.txt. It determines the
KEY_DOWN sound to be played when activating the callback.
If you replace the number by -1 sound playback is disabled for that callback.
More info can be found in the chapter Why we don’t hear cockpit sounds when pressing a key.
6-16
BMS KEY FILE MANUAL
CHANGE 1
The third part is not used in the code line, as it is old 2D Pit stuff. In the past you could decide to use both, mouse
and key binding (0) or only the mouse (1) in cockpit. Changes here don’t have an impact. You should leave the 0
unchanged.
(0X22 = g)
BMS makes use of the XT scan codes. The keyboard key code used in the BMS key files is composed of a leading
0X and the following one- or two-digit XT scan code Hex number.
There is one exception: If no key is assigned the keyboard key code is 0XFFFFFFFF.
Each key has an assigned and unique scan code which will be transferred when pressing the key. The interesting
part of it is that the scan codes for most keys (but not all!) are working regardless of which keyboard language is
chosen, even if the key caption says something different.
For example:
0X15 is “Y” on an US International keyboard layout and “Z” on a German layout. So the XT codes are independent
from the chosen keyboard language. 0X15 will be shown country-specific correctly.
I don’t use all possible keys as I want to make sure, that the key files can be used by the majority of the
community. The keyboard layouts around the globe are widely differing. So I concentrated on the most common
keys. I don’t want to list all key codes here as it would be a rather long list. Please refer to my BMS Keyboard
Codes documents (can be found in the keyboard layouts folder) for more information.
A full list of all possible key codes can be found in the original Keyfile-generator.xls in the BMS installation
folder/Docs/Falcon BMS Manuals. But if you want to create your own key file with the intention of spreading it, I
would recommend staying with a few common keys as I did. If you use a single code which is not supported by
your keyboard, it will crash BMS as soon as you try to load it in BMS UI.
You can assign modifiers to be used together with keyboard keys. In the example above the Shift key is assigned.
To invoke the callback you have to press Shift + g on the keyboard.
6-17
BMS KEY FILE MANUAL
CHANGE 1
We can use three different modifier keys, Shift, Ctrl and Alt. They can be combined which sums up in eight
different modifier combinations:
If you assign a modifier but no keyboard key in the code line, the function will be shown as “No Key Assigned” in
the UI. So it is not possible to assign a function to a modifier key only.
Also it is not distinguished between left & right modifier keys (e.g. left Shift / right Shift).
Before starting here you have to understand, that the sixth and the seventh part (key combination key + modifier)
cohere.
You cannot use a key combination key without a key combination modifier!
Same for the other way round, you cannot use a key combination modifier without a key combination key! But
this will be addressed later.
In my key files you have one code line which looks the same as the example above. So you assign a keyboard key
+ modifier key to the callback CommandsSetKeyCombo the same way as you normally would do with all other
callbacks in a key file.
6-18
BMS KEY FILE MANUAL
CHANGE 1
But you can’t do that in the UI. Indeed it would be possible to set the keys for CommandsSetKeyCombo here. But
you have no possibility to assign the key combo (Alt + C in this example) to another function in the UI. So you have
to manually edit the key file with an editor either way.
It is possible to set two or more different key combos. But it doesn’t make sense, as there is no need for it. So I
use only one key combo with my key files (Alt + C).
Once a key combo is set, we need to implement it into an existing code line:
6-19
BMS KEY FILE MANUAL
CHANGE 1
A key combination modifier has the same syntax as a normal modifier (see explanations above). Setting a key
combo modifier without a key combo key does not have any effect.
Note: There is a special case for setting a key combo modifier without a key combo key. If a code line
is set to “locked” (-0, see eighth part below) it is not possible to change the keys in the UI (In the
example above 0X22 = “g”). You can also not assign “g” to any other function, because the locked
status is preventing the deletion of the key in that code line. By assigning a key combo modifier “g”
remains in the locked code line while assigning it somewhere else is possible now. This workaround is
used for the “1. UI & 3RD PARTY SOFTWARE” category in the key files.
By changing the eighth part you can decide how the code line will be shown in the UI (see also Categories and
Sections at the beginning of this document).
Example: Visible
Example: Headline
6-20
BMS KEY FILE MANUAL
CHANGE 1
The last part of each code line defines the description shown in the BMS UI. The description line is limited to 45
characters (was 37 characters in 4.32 before) and embedded between two quotes.
When using more than 45 characters the description will be cut off as shown in the example below.
AFGearToggle -1 0 0X22 0 0 0 1 "GEAR: LG Handle – Toggle (>45 characters will be cut off)"
SimTriggerFirstDetent 0 -1 -2 0 0x0 0
Each code line is composed of seven different parts. An eighth part is optional.
Note: The parts are separated by a blank character (Spaces shown with a red underline here).
SimTriggerFirstDetent_0_-1_-2_0_0x0_0
The callback here works pretty much the same as described in the “Keyboard Code Lines” section with the
difference, that they are invoked by pressing a DX button rather than pressing a keyboard key.
A second difference is that it does make sense to change callbacks here. If you feel unsatisfied with a DX function,
just replace the callback with a new one.
The DX button ID represents a physical DX button on your input device. Each button has its own specific ID in the
range of 1 to 32. Windows doesn’t allow more than 32 different DX IDs per device.
6-21
BMS KEY FILE MANUAL
CHANGE 1
On the contrary BMS counts the DX numbers from 0. So the first device has the IDs 0 – 31. You can assign
functions to shifted and unshifted layers. How that works is described later.
DX code lines distinguish between three states when a callback is invoked. These are:
We have four code values for the third part of the DX code line:
This value distinguishes between DX buttons (value -2) and POV hats (value -3).
You can define whether the callback is invoked when a DX button is pressed (0) or released (0x42). In addition you
can chose if the callback is invoked with a key down, key up or the default semantic by setting the corresponding
value at the third part of the code line. More details on this subject will be provide later on in this manual.
This part never changes in a DX code line and should be left untouched.
In the key files, for DX button callbacks, the former "mod1" field (last entry in a DX row, always 0 in the past) will
now serve as sound ID to determine the KEY_DOWN sound to be played when activating the callback. The sound
IDs can be found in the f4sndtbl.txt. Sound can be deactivated with “-1”. Also the value “0” activates no sound as
no sound file is assigned.
6-22
BMS KEY FILE MANUAL
CHANGE 1
The description doesn’t have a real impact. It is not shown in the UI. It only makes sense to make some personal
notes about the callback, especially if you are not familiar with the callback functions.
AFElevatorTrimUp 0 -1 -3 0 0x0 0
Each code line is composed of seven different parts. An eighth part is optional.
Note: The parts are separated by a blank character (Spaces shown with a red underline here).
AFElevatorTrimUp_0_-1_-3_0_0x0_0
See 6.2.1
BMS supports up to four different POV hats _if_ they are on the primary input device! (You know, the one which
controls your jet…)
POV Hats are numbered consecutively from 0 to 3. To be honest, most devices do not feature four different POV
hats. Having just one should be common. It is possible to add a shifted layer like it is shown in the table below.
The shifting offset is 2.
The default behaviour of the primary POV hat is changing the Point Of View. This can be changed by adding POV
code lines for the unshifted layer (POV Hat number 0) and assigning different callback functions to it (e.g. TRIM).
6-23
BMS KEY FILE MANUAL
CHANGE 1
This value distinguishes between DX buttons (value -2) and POV hats (value -3).
Each POV hat has eight different directions. They are numbered consecutively from 0 to 7 (clockwise starting
from the 12 o’clock position) as shown below:
The sound IDs work for POV code lines as well. 0 or -1 deactivates sound.
It is also possible to add descriptions to the POV hat code lines. See also 6.2.8
6-24
BMS KEY FILE MANUAL
CHANGE 1
Let’s start with a short example of a key file. This is how it looks in an editor:
Just pick a function you’d like to change a click once into the left column. As soon as you do so, the keys
assignment will be highlighted in blue colour.
Next press the key you would like to assign instead. In this case “F1”.
You can do the same for keys with modifiers. Just select the left row of the function...
7-25
BMS KEY FILE MANUAL
CHANGE 1
...and press the modifier keys, hold them and then press the keyboard key.
Once loaded in the UI the same key file looks like this:
What we need to do now is to left click on a row we want to assign a DX button to. The key of this row will be
shown in blue.
Now we press a button on the input device. As soon as the button is pressed the key will change to white again
and below the key file list you’ll see something like this:
7-26
BMS KEY FILE MANUAL
CHANGE 1
This means that you have successfully assigned a function to your input device. From now on, whenever you press
that button you’ll see this. So you can easily figure out which function is assigned to which DX button on your
device.
If you press a button on your device which has no assigned function it will be shown like in the image above.
Now, if we have assigned all four functions to DX buttons we save the key file. As you can see in the image below
the DX code lines are automatically added to the key file.
Note: If you assign a DX button via the BMS UI the third part of the key file has the value “8”.
It incorporates the most important DX and key file stuff and an overview of all callbacks, logically sorted into
categories and sections. You can edit almost everything. A lot of input checks are implemented.
There is an additional manual for the Editor (BMS Key File Editor Manual.pdf). Just follow the instructions.
7-27
BMS KEY FILE MANUAL
CHANGE 1
How to edit key files is best described with some examples (changes marked yellow).
45
Note: If you mark a value by double clicking on it (here line 18 value 0X22, dark green) other positions
with the same value in the file will also be highlighted (lines 2, 5, 7, 12 & 15, brighter green).
7-28
BMS KEY FILE MANUAL
CHANGE 1
While doing that you will face the difficulty to avoid double assignation of one and the same keys.
Unfortunately you can’t check for double assignation in the BMS UI. So you need other tools than that. I prefer
Notepad++ for that as well.
In opposite to the double clicking feature of showing accordances it doesn’t work for manually marked parts of
the code (It works only for “double-clickable parts, which are separated by blank or special characters). So like in
the example below the marked part is only (grey) highlighted.
To find accordances just hit Ctrl + F which opens the Find window. The highlighted code is already in the search
box. Just click on “Find Next” to search for a match. If one is found the view jumps directly to the line the match
was found.
If you found a match you should change one of the both key assignments.
As we know key files can be rather complex. So it is a good habit to do this each time you assigned a keyboard key
command and / or a key modifier key. Just make sure to search for both, the fourth AND fifth part of the code
line.
7-29
BMS KEY FILE MANUAL
CHANGE 1
You can avoid multiple DX button ID assignations the same way as described in the “How to avoid multiple key
assignations” chapter.
If you assign accidently two or more different callbacks to the one and the same DX button ID (like in the example
below) only the last entry will be invoked by pressing the corresponding DX button input device.
So in this example the first entry (Frame Rate) will be ignored and the last entry (Online Status) will be invoked.
7.4.1 Introduction
The HOTAS controls in the F-16 have a defined set of functionality (see chapter “Hands-on controls”) which is
often reproduced by (v)pilots in their joystick layout. However, most users have the need for controlling
additional, simulator specific functionality like e.g. views or similar with their HOTAS setup.
The common practice to achieve this is the usage of a joystick “shift” button. Like the shift key on the keyboard,
which controls whether a specific keystroke issues a minor letter (when used without shift) or a capital letter
(when used with shift) to the PC, the shift button on the joystick controls whether a button is sending function A
(when used without shift button) or function B (when used with shift button) to the simulation.
To achieve this functionality, the (v)pilot had to rely on the programming capabilities of his joystick and
7-30
BMS KEY FILE MANUAL
CHANGE 1
corresponding drivers and software in the past, making the stick act as a combined DirectX (DX) and keyboard
input device. The combination of DX buttons and emulated keyboard input from the stick was needed to
overcome the maximum number of buttons limitation of 32 that a DX input device is restricted to.
The current BMS version offers a built-in shifting facility that eliminates the need for such proprietary solutions.
Furthermore and even a bigger advantage, it makes it possible to use a pure DX joystick setup for all functions,
shifted and unshifted, by effectively (nearly) doubling the number of possible DX button inputs for a single device
to 63.
7.4.2 Background
BMS can handle up to 16 DX devices with 32 buttons each, making a total input of 512 DX buttons possible. To
assign DX input, a special type of input line within the BMS keyfile is used e.g.:
SimTriggerFirstDetent 0 -1 -2 0 0x0 0
SimPickle 1 -1 -2 0 0x0 0
The red part of the input lines will not be explained here. The green part of the input lines is composed from the
name of the function to call and the DX button number that should trigger the execution of the function.
BMS starts enumerating the buttons with 0, so the first DX device connected to the PC uses button numbers 0 to
31, where button #1 on the stick is mapped to 0 in the keyfile, button #2 is mapped to 1 etc. If more than one DX
device is connected, the 2nd device will use button numbers 32 to 63, where button #1 on the 2nd device is
mapped to 32, button #2 is mapped to 33 etc.
Every DX device has its dedicated 32 button range in the keyfile, so a possible 16th DX device would use button
range 480 to 511. Using this technique, BMS can distinguish between the different DX devices.
Besides the DX buttons, BMS can additionally handle up to 4 POV hat switches. However, unlike the DX buttons,
the POV hats can only belong to one DX device. BMS automatically assigns the POV hats to the DX device that is
selected for primary poll/pitch-input in the UI setup controller page.
To assign POV hat input, a special type of input line within the BMS keyfile is used e.g.:
AFElevatorTrimUp 0 -1 -3 0 0x0 0
AFElevatorTrimDown 0 -1 -3 4 0x0 0
The red part of the input lines does never change for POV hat definitions and will not be explained here. The
green part of the input lines is composed from the name of the function to call, the POV hat number (0 to 3) and
7-31
BMS KEY FILE MANUAL
CHANGE 1
the direction in which the POV hat needs to be pushed on order to trigger the execution of the function.
Regardless of the physical capabilities of the POV hat, BMS always distinguishes 8 separate directions:
Note: POV hats that have not been mapped in the keyfile automatically default to view panning.
This version of BMS offers a new keyfile callback for DX buttons, which defines the mapped button to act as shift
modifier. While this button is pressed down, BMS will add a fixed (but configurable) offset number to all DX
button inputs.
Example: The shift button is configured to add an offset of 256 while pressed. Button #2 on the joystick (1st DX
device) should usually work as weapons pickle button, but should toggle the gear when used in conjunction with
shift. The keyfile would need to contain the following entries to achieve this behavior:
SimPickle 1 -1 -2 0 0x0 0
AFGearToggle 257 -1 -2 0 0x0 0
The 257 is composed from DX button #2 (1) plus the 256 shift offset. So the usage of the shift button effectively
moves the DX buttons of a specific DX device into a separate DX device range. In the example above, usage of
shift moves the buttons of the 1st DX device from 0-31 to 256-287. Conclusively, DX buttons that are pushed on
the 1st DX device while shift is hold will look to BMS like being issued from a (virtual) 9th DX device.
To enable the shifting facility, the following parameter has to be added to the falconbms.cfg file:
set g_nHotasPinkyShiftMagnitude n
The parameter value 0 disables shifting. Setting n to a higher value enables it and specifies the button offset
number. Although arbitrary offset numbers are supported, it is highly recommended to use a multiple of 32 for
the offset. Like this, a shifted DX button range always maps to the complete button range of another (virtual) DX
device.
7-32
BMS KEY FILE MANUAL
CHANGE 1
The callback name for the DX button that should act as shift button is:
SimHotasPinkyShift
When shifting is active, this callback replaces the former “SimPinkySwitch” callback. It still fulfills the same
EXPAND functionality if it is only tapped and released. When it is pressed and held down, it acts as shift button.
Obviously, it is meant to be mapped to the pinky switch on the HOTAS.
In order to make shift work properly, the shift callback has to be mapped twice in the keyfile. Once for the pinky
button, and once for the pinky button plus shift offset.
Example: The pinky switch on the HOTAS uses DX button #3 and the configured shift offset is 256. Hence the
keyfile needs to contain the following lines:
SimHotasPinkyShift 2 -1 -2 0 0x0 0
SimHotasPinkyShift 258 -1 -2 0 0x0 0
Note: If the 2nd callback mapping is missing, the shift button can not be released correctly again once pressed.
If you don’t use shifting at all you can also use the standard callback (SimPinkySwitch).
But it is possible to assign the callback SimHotasPinkyShift to more than one physical DX button.
The shifting of POV hat buttons follows the same concept as shifting DX buttons. It uses the same shift callback
that has already been defined for DX buttons. Only difference is that the shifting offset for POV hats is fixed to 2.
Example: The 1st POV hat should be used for view panning when used unshifted, and for trimming when used
shifted. The keyfile would need to contain the following entries to achieve this behavior:
AFElevatorTrimUp 2 -1 -3 0 0x0 0
AFAileronTrimRight 2 -1 -3 2 0x0 0
AFElevatorTrimDown 2 -1 -3 4 0x0 0
AFAileronTrimLeft 2 -1 -3 6 0x0 0
The 2 is composed from POV hat #1 (0) plus the fixed 2 shift offset. So the usage of the shift button effectively
promotes the 1st POV hat to act as a 3rd (virtual) POV hat. The directional numbers do not change.
Note: It is not necessary to explicitly map the default view panning behavior to POV hat #1 (0), as
every hat which is not mapped defaults to view panning behavior.
7-33
BMS KEY FILE MANUAL
CHANGE 1
The maximum pinky tapping time in milliseconds that is used to determine whether the pinky button should
execute EXPAND or act as shift button can be configured within the falconbms.cfg file:
set g_nHotasShiftQuickPressTimeLimit n
The parameter value defaults to 200. If the pinky button is tapped and released within n milliseconds, EXPAND is
executed. If it is not released within n milliseconds, shift is executed instead.
If the shift callback is mapped on more than one physical device, each individual shift button applies shift to all
devices at once. E.g. pressing shift on the 1st DX device shifts buttons of the 1st as well as any other DX devices
that are connected and vice versa.
Most likely not every DX button or POV hat will have a shifted functionality assigned when creating a keyfile. As
pointed out in the background section, any device or hat that is not used will map to default behavior. The same
is true for shifted buttons and hats.
While this behavior may be desirable in some situations, it may be as well totally unwanted in other situations. A
good example for an unwanted situation is the mapping of trim to a shifted POV hat, as described in the Concepts
and Usage section above. In this example, only the shifted main up/down/left/right hat directions are mapped to
trim, whereas the corner directions have no shifted functions assigned. Therefore, they still default to view
panning, even when used shifted. When the (v)pilot tries to trim aileron and elevator at once by shift-pressing the
hat to a corner, he will execute view panning instead of the desired trim.
The only way to avoid that behavior is to actually assign a function to the shifted POV hat corner directions.
However, combined aileron/elevator trim keystrokes for our example are not available.
SimDoNothing
7-34
BMS KEY FILE MANUAL
CHANGE 1
Like this, unwanted functionality can be deliberately deactivated. So for the trimming/view panning example, the
shifted POV hat corners can be mapped to SimDoNothing to avoid unwanted view panning while trimming:
AFElevatorTrimUp 2 -1 -3 0 0x0 0
SimDoNothing 2 -1 -3 1 0x0 0
AFAileronTrimRight 2 -1 -3 2 0x0 0
SimDoNothing 2 -1 -3 3 0x0 0
AFElevatorTrimDown 2 -1 -3 4 0x0 0
SimDoNothing 2 -1 -3 5 0x0 0
AFAileronTrimLeft 2 -1 -3 6 0x0 0
SimDoNothing 2 -1 -3 7 0x0 0
The same can be done with every shifted DX button or POV hat which should not execute default functionality.
Restrictions
Advanced or logical programming - as offered by many joystick vendors - can not be implemented with the BMS
DX shifting facility.
It is not possible to assign functions to the shifted layer via the Setup UI.
Once opened scroll a bit down until you find the “Misc Settings” section.
7-35
BMS KEY FILE MANUAL
CHANGE 1
Setting it to 512
Of course you could specify any other value between 32 (Note: You’ll need at least one unshifted layer anyway)
and 511. But this doesn’t make any sense as shifting outside the DX device limit is now possible. To sum it up:
If have not more than 8 different input devices the default setting is ok. This should apply to most users. If you
have more than that you don’t necessarily have to do the math. Instead you can just set it to 512 and you are
good to go.
Additionally, the DX button numbers can now be shifted *outside* the DX device limit, making it essentially
possible to use *all* 16 DX devices with DX shifting. To do so, simply specify "set g_nHotasPinkyShiftMagnitude
512" (default is 256) in the config file (and adjust your keyfile accordingly, of course).
So instead of shifting only the 1st half DX devices 1-8 to the 9-16 range, you can now shift all DX devices 1-16 to
the 17-32 range.
Using shifting or not does not matter. If you try to access a button "beyond the max range" (either by shifting or
regularly), it simply is ignored. So the actual number of devices does not seem to be a problem at all - other for
the fact that BMS simply ignores devices that are out of the range.
7-36
BMS KEY FILE MANUAL
CHANGE 1
7-37
BMS KEY FILE MANUAL
CHANGE 1
8.1 HOW TO FIND OUT YOUR DX DEVICE ORDER AND DX BUTTON IDS:
To make the devices work properly it is necessary to know the order of the installed DX devices.
I have to admit, in the first version of my updated manual I showed a fully illustrated way on how to find that out
with the help of Windows. Things like Control Panel, Devices and Printer, Game Controller Settings. Five wasted
pages…
There is much easier way to find that out. In fact with the help of BMS.
Just enter the BMS UI and enter Setup – Controllers page. Now we need to press only one button per device.
In the above image you see INPUT and Button 1 to the right.
Button 1 means in this context DirectX button 1. The DirectX button numbers in the BMS UI are shown as
Windows DX numbers. BMS counts DX button numbers slightly different than Windows. Win DX # 1 = BMS DX # 0.
So far so good. Let’s try that again with our second controller:
Now we see Button 45, which means Win DX # 45 and BMS DX # 44.
8-38
BMS KEY FILE MANUAL
CHANGE 1
As you might remember we have a maximum of 32 DX buttons per device. So if the shown button number is in
the range of 1 – 32 it must be device 1, your primary input device so to speak. If the button number is in the range
of 33 – 64 it is device # 2 and so on.
So in our example above we now know that the first device is the one with the button # 1 and the second with
the button # 45.
As mentioned above there is a difference between the Windows DX numbers and the BMS DX numbers.
While Windows counts DX buttons from 1 BMS does from 0. So the BMS DX button number of the first device
(Button 1 in the screenshot) is BMS DX 0. The button # 45 of the second controller is BMS # 44.
So why do we need to know the numbers when BMS shows them well in the UI. That’s because the BMS numbers
are used in the key file. So if the UI says INPUT Button 1 the same device button will be shown as DX number 0 in
the key file.
On the other hand we need these numbers to calculate the DX button IDs for the shifted layers. They have to be
calculated manually or by using my Excel BMS DX-Generator.
Direct Input devices (joysticks, MFDs, boards etc.) can now be sorted to *specific* positions as desired via a new
config file "DeviceSorting.txt" in the "User\Config" directory. That means even by unplugging stuff and replugging
it, the DX button numbers won't change anymore.
This file will be created automatically if it is not existing, and it will list all devices which are currently connected to
BMS. If you want to change the device order, simply close BMS, edit the file with a text editor and copy/paste the
lines in the file to your liking. Once the file exists, it will always be loaded and the order in there will be honored
by BMS. If you connect a new device which is not listed in the file yet, it will be appended to the existing file ithout
8-39
BMS KEY FILE MANUAL
CHANGE 1
changing the specified order. Missing devices will be ignored. The file simply consists of the GUID and the device
name for each device, one device per line. Example:
If you add one device it will be appended to the end of the file:
You can sort the device by simple copy/paste. In the example below the ICP has been moved from #4 to #2.
Note: You still have to ensure that all devices are plugged in!
Example: you have one stick, and 2 MFDs, the stick usually has DX button number 0-31, the 1st MFD has 32-63,
the 2nd MFD has 64-95. Now you start BMS while forgetting to plug in the stick... in this case, MFD1 will still move
from 32-63 to 0-31 (and MFD2 moves accordingly). However - and that is the whole purpose of this patch - once
you realize that the stick is missing, you can stop BMS, plugin the stick, and now it is *guaranteed* that the stick
will be seen by BMS as button numbers 0-31 again.
In summary: if you have a working DX button setup, it will never be "shuffled around" again like it used to.
In addition files "axismapping.dat" and "joystick.cal" in the <BMS>\User\Config directory will no longer be
overwritten automatically. They will only be written if the the "OK" or "APPLY" buttons on the UI SETUP screen
are hit explicitly.
If you forget to plugin your sticks and you start BMS, it will re-enumerate the axis and re-assign them for the
running session. You can even make changes in the ADVANCED CONTROLS setup screen. But unless you exit the
setup screen with OK or APPLY, *none* of these changes will be persisted to the files. Hence, if you quit BMS, re-
plug your missing devices, their axis will still be mapped correctly as they were before.
Note: Every change you make in the controller section WILL be active in the BMS session, regardless
whether you hit CANCEL or OK, as the UI system needs to apply these changes right away in order to
make the axis bars etc. show the correct values. This behavior has not been changed/touched. Only
the *persisting* of these changes to the files will no longer happen "automagically" once you e.g.
change a value in a drop-down box. There currently is no way to really "cancel" - i.e. rollback - changes
that you make in the controller UI screens. They will stay active as long as BMS is running no matter
what (even when you hit CANCEL).
8-40
BMS KEY FILE MANUAL
CHANGE 1
The DF Switch on the Throttle has only two different DX numbers: One for MRM override mode and one for DF
override mode. There is no separate DX button for cancel (middle position). To overcome this limitation you can
set a value in the falcon bms.cfg.
Open the cfg and scroll down to the Misc Settings section. Look for the code line
set g_bHotasDgftSelfCancel 0
and change the value to 1. This cancels the override mode automatically when turning the DF switch back into the
middle position.
Note: This is TM HOTAS Warthog specific but can also apply to other input devices.
Some of the 3-way switches of the Warthog throttle have only 2 different DX button IDs. Let’s take an example:
As we see only PATH (Win DX 27 / BMS DX 58) and ALT (Win DX 28 / BMS DX 59) have assigned DX button
numbers. So we can only assign two different callbacks via DX.
Wrong!
There is a way to overcome the missing of the DX number for the middle function (ALT/HDG - no DX).
4 = DX button number
-1 = -1 is the default key up/down behavior
0 = default button press/release event
9-41
BMS KEY FILE MANUAL
CHANGE 1
To stay with our example you can test this with your Warthog:
SimRFNorm 58 -2 -2 0 0x0 0
SimRFQuiet 58 -2 -2 0x42 0x0 0
SimRFSilent 59 -2 -2 0 0x0 0
SimRFQuiet 59 -2 -2 0x42 0x0 0
SimRFNorm 58 -2 -2 0 0x0 0
DX button press event -> SimRFNorm
SimRFSilent 59 -2 -2 0 0x0 0
DX button press event -> SimRFSilent
SimRFQuiet 59 -2 -2 0x42 0x0 0
DX button release event -> SimRFQuiet
You can do this with every DX button #. Of course this is not recommended and not useful in all occasions.
9-42
BMS KEY FILE MANUAL
CHANGE 1
If you would like to have a more realistic 1=7, 7=1 mapping just copy the lines below and overwrite! the
corresponding lines in the key file (see ICP section).
10.2 HOW TO CHANGE THE DX POV FUNCTIONS (TRIM VS. VIEW & OTHER FUNCTIONS):
In my key files the unshifted POV acts with its default behavior (views). The TRIM functions are set to the shifted
layer. Here is how you can change that:
Delete the following lines in the key file – HOTAS SHIFTED (They set TRIM to shifted layer):
AFElevatorTrimUp 2 -1 -3 0 0x0 0
SimDoNothing 2 -1 -3 1 0x0 0
AFAileronTrimRight 2 -1 -3 2 0x0 0
SimDoNothing 2 -1 -3 3 0x0 0
AFElevatorTrimDown 2 -1 -3 4 0x0 0
SimDoNothing 2 -1 -3 5 0x0 0
AFAileronTrimLeft 2 -1 -3 6 0x0 0
SimDoNothing 2 -1 -3 7 0x0 0
10-43
BMS KEY FILE MANUAL
CHANGE 1
Copy the following lines into the key file – HOTAS UNSHIFTED (They set TRIM to unshifted layer):
AFElevatorTrimUp 0 -1 -3 0 0x0 0
SimDoNothing 0 -1 -3 1 0x0 0
AFAileronTrimRight 0 -1 -3 2 0x0 0
SimDoNothing 0 -1 -3 3 0x0 0
AFElevatorTrimDown 0 -1 -3 4 0x0 0
SimDoNothing 0 -1 -3 5 0x0 0
AFAileronTrimLeft 0 -1 -3 6 0x0 0
SimDoNothing 0 -1 -3 7 0x0 0
Copy the following lines into the key file – HOTAS SHIFTED (They set Views to shifted layer):
OTWViewUp 2 -1 -3 0 0x0 0
SimDoNothing 2 -1 -3 1 0x0 0
OTWViewRight 2 -1 -3 2 0x0 0
SimDoNothing 2 -1 -3 3 0x0 0
OTWViewDown 2 -1 -3 4 0x0 0
SimDoNothing 2 -1 -3 5 0x0 0
OTWViewLeft 2 -1 -3 6 0x0 0
SimDoNothing 2 -1 -3 7 0x0 0
Of course it is possible to assign any callback you want to the POV hat. The code lines follow always the same
syntax.
10-44
BMS KEY FILE MANUAL
CHANGE 1
Be advised: They are for non F-16 MFD control only, if an AC has three or more MFDs.
MFD 3: Shift+Ctrl +1, +2, +3... and Shift+Ctrl +Num1, +Num2, +Num3...
MFD 4: Shift+Ctrl+Alt +1, +2, +3... and Shift+Ctrl+Alt +Num1, +Num2, +Num3...
Another solution for DX is to add the 3rd and 4th MFD to the shifted layers of the 1st and 2nd MFDs. I included the
DX code lines into my DirectX TM Cougar MFD.pdf.
There are no cockpit switches for that function in a real F-16. Nonetheless this callback is implemented into
Falcon most likely due to comfort reasons. The pilots might look for it at different locations. That’s the reason,
why you can find the Trim Reset three times.
You can find it in the MANUAL TRIM, FLIGHT STICK and in the OTHER COCKPIT CALLBACKS sections. You can
change the key setting only in the CKPIT section. The state of the callback in the TRIM and the STICK section is
visible, not changeable with no keys assigned. You will be referred to the CKPIT section there, if you want to
change the keys.
SimPickle:
Here we have two different locations, where you can shoot a weapon. The FLIGHT STICK (Pickle) and the MISC
ARM PANEL (ALT REL Button). You can change the callback only in the STICK section. The ALT REL Button works
without any callback! It is only visible (not changeable) in the UI to keep the key file complete.
SimRadarGainUp/Down:
You can find the radar gain functions in each of the 4 MFD sections. But you can change the key assignments only
in LMFD section. In all other sections you will be referred to the LMFD section.
The TRIM Reset function in the TRIM & STICK sections, the ALT REL Btn. on the MISC Panel and the RadarGain
functions in RMFD, TMFD & FMFD sections are assigned to the callback SimDoNothing, with no keys assigned (Not
editable).
10-45
BMS KEY FILE MANUAL
CHANGE 1
11 TROUBLESHOOTING:
It’s better to make a backup of your key file and to open it with an editor. Now delete half of the code and check
again in BMS. If the file is ok the issue occurs most likely in the second half of the code which you have deleted.
Now you can go on by halving the code of the second part and check this file again. Go on this way until you
found the corrupt code line. Once found you can examine what was going wrong here.
BMS can also crash when the key file uses a keyboard key which is not
compatible with your locale. A typical example is the “<” key (Key file code is
0x56) on a German keyboard layout. If you try to use this code with an US
International locale, BMS will crash.
The reason for a stuck key is a mishandling of the key press sequence. Here is the way how to do it properly:
1. Press and hold modifier key (keyboard) / Pinky switch (DX Shift)
If you release #4 & #5 in the wrong order the key(s) / function will most likely stuck. To prevent this either use the
correct order stated above or try to avoid using shifted functions.
11-46
BMS KEY FILE MANUAL
CHANGE 1
Tab:
Alt + Tab
Shft Ctrl + Tab
Shft Alt + Tab
Ctrl Alt + Tab
Shft Ctrl Alt + Tab
The Tab combinations above will bring you back to desktop (If you have luck) or could crash / freeze BMS. Both
unwanted actions while enjoying a flight…
Escape:
Ctrl + Esc
Alt + Esc Note: Escape can’t be assigned in the BMS UI! Esc is hardcoded. If you try to
Shft Ctrl + Esc assign that key in the UI, it will leave the setup screen immediately.
Shft Alt + Esc
Ctrl Alt + Esc
Shft Ctrl Alt + Esc
You have to assign that key manually with an editor if desired. But don’t forget to assign “Exit Sim” to another
key. Otherwise the only possibilities to exit 3D are Alt + TAB (if working for you), Reset your PC (of course not
recommended) or crashing / ejecting your jet (Exit menu will pop up automatically).
The above shown combinations will invoke Windows related functions and thus are not recommended to assign
them. The only safe combination is Shift + Esc, which you could assign manually.
Num Lock:
If you assign the Num Lock key it will toggle between “Disable Num Pad” and “Enable Num Pad”. It has no impact
on BMS as the assigned functions on the Num Pad work no matter how the Num Pad status is.
But using this key in a key file will lead to a BMS crash once you try to enter BMS Setup. So this key shouldn’t be
assigned at all.
11-47
BMS KEY FILE MANUAL
CHANGE 1
Print:
Shft + Print
Ctrl + Print Note: PrtScr can’t be assigned in the BMS UI! When doing so the key
Alt + Print mapping field remains empty. In the Sim nothing will happen (except hardcoded
Shft Ctrl + Print Screenshot of course).
Shft Alt + Print
Ctrl Alt + Print
Shft Ctrl Alt + Print
You could assign this key to any function. But as Screenshots are hardcoded to Print, you would make a
screenshot any time the key combinations are invoked. Because of this you should avoid the key combination.
However, Pretty Screenshot is allowed for any of the Print combinations except Shift Alt + Print, which opens a
Windows function.
Windows XP and Windows 7 are handling the PrtScr mapping differently. While assigning PrtScr in XP works
pretty well in key files, it doesn’t in Win 7. Because of that the PrtScr key was hardcoded. This means they are
working for both and you can take screenshots even without assigning a key in the key file.
Which kind of screenshot PrtScr makes (ScreenShot or PrettyScreenShot) is defined in the falcon bms.cfg (section
Misc Settings).
Additionally you can assign keys to the callbacks ScreenShot and PrettyScreenShot. They are set to “no keys
assigned” by default.
If you assign PrtScr manually in the key file Win XP and 7 will behave differently. While it does simply nothing in
Win 7 it will do two things at the same time in XP: It makes a screenshot (due to hardcoded PrtScr) and invokes
the callback PrtScr is manually assigned to.
11-48
BMS KEY FILE MANUAL
CHANGE 1
The following list shows all 3-digit numbers and the corresponding sound files, which are currently used in the
default key files and the 3dckpit.dats. These can be found in the f4sndtbl.txt. If you want to hear sounds when
pressing a key (keyboard) or button (DX device) for a specific cockpit function you have to implement them as
described earlier in this document.
The sound IDs in correlation with the sounds above are listed in order of their first appearance.
11-49
BMS KEY FILE MANUAL
CHANGE 1
The first one is for the average Joe Pilot, the second one is a dedicated to pitbuilders.
While non pitbuilders are used to interact with the cockpit either via mouse or by using toggle / cycle functions,
the needs for a pitbuilder are different.
The main goal was to assign all currently implemented functions and taking a look into the future to take further
developments into account right from the beginning.
So what we have now is a complete set of all possible cockpit functions based on the F-16C/D Blk 50 cockpit
layout. This makes sure, pitbuilders have a future proof keyboard layout at hand on which they can rely on.
But wait:
No promises are made whether new functions are developed or not. Although it is very likely, that most of the
missing functions will be addressed someday, we cannot guarantee that all possible cockpit functions will be
implemented.
On the following pages you see the full set of all assigned cockpit function with and w/o comments.
12-50
BMS KEY FILE MANUAL
CHANGE 1
12-51
BMS KEY FILE MANUAL
CHANGE 1
12-52
BMS KEY FILE MANUAL
CHANGE 1
Views
1 → L & R MFDs 2 → L Aux & C
2 → Left Console
Long Press Panels / HOTAS, Quick Access keys & ICP (shift)
4 → Left Aux & Center Console
4 → Left Console
HOTAS
5 → Left Aux & Center Console
5 → Left Console ← 11
Right Console ← 10
12-53
BMS KEY FILE MANUAL
CHANGE 1
12-54