0% found this document useful (0 votes)
218 views

BMS Key File Manual

This document provides a manual for BMS key files that: - Categorizes key file sections and callbacks using headlines and naming conventions for easy navigation. - Defines terms related to key files such as callbacks and modifiers. - Gives an overview of the different categories and sections within key files. - Explains the inner workings of how keyboard, DirectX button, and POV hat code lines are structured and function within key files.

Uploaded by

Dave91
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
218 views

BMS Key File Manual

This document provides a manual for BMS key files that: - Categorizes key file sections and callbacks using headlines and naming conventions for easy navigation. - Defines terms related to key files such as callbacks and modifiers. - Gives an overview of the different categories and sections within key files. - Explains the inner workings of how keyboard, DirectX button, and POV hat code lines are structured and function within key files.

Uploaded by

Dave91
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 54

BMS KEY FILE MANUAL

Author: KOLBE

Version: BMS 4.33.1


CHANGE 1
03. 2016
BMS KEY FILE MANUAL
CHANGE 1

FOREWORD
PURPOSE AND SCOPE

My intention (or: Why I started this project back in 2011):

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

6.2 DirectX button code lines ....................................................................................................................... 6-21


6.2.1 First part: The Callback ................................................................................................................... 6-21
6.2.2 Second part: The DX button ID ....................................................................................................... 6-21
6.2.3 Third part: Callback invocation behaviour...................................................................................... 6-22
6.2.4 Fourth part: DX button identifier.................................................................................................... 6-22
6.2.5 Fifth part: DX button press / release event .................................................................................... 6-22
6.2.6 Sixth part: Not used ........................................................................................................................ 6-22
6.2.7 Seventh part (optional): Sound ID .................................................................................................. 6-22
6.2.8 Eighth part (optional): The description .......................................................................................... 6-23
6.3 DirectX POV Hat Code Lines ................................................................................................................... 6-23
6.3.1 First part: The Callback ................................................................................................................... 6-23
6.3.2 Second part: POV Hat number ....................................................................................................... 6-23
6.3.3 Third part: Not used........................................................................................................................ 6-24
6.3.4 Fourth part: POV Hat identifier ...................................................................................................... 6-24
6.3.5 Fifth part: Panning direction ........................................................................................................... 6-24
6.3.6 Sixth part: Not used ........................................................................................................................ 6-24
6.3.7 Seventh part (optional): Sound ID .................................................................................................. 6-24
6.3.8 Eighth part (optional): The description .......................................................................................... 6-24
7 How to edit key files: ..................................................................................................................7-25
7.1 Assignments via BMS Setup Menu ......................................................................................................... 7-25
7.1.1 Key Assignments: ............................................................................................................................ 7-25
7.1.2 DirectX Assignments: ...................................................................................................................... 7-26
7.2 Editing key files with the Key File Editor: ............................................................................................... 7-27
7.3 Using an editor: ...................................................................................................................................... 7-27
7.3.1 Manually Editing Keyboard Code Lines .......................................................................................... 7-27
7.3.2 How to avoid multiple key assignations: ........................................................................................ 7-29
7.3.3 Manually editing DirectX Code Lines: ............................................................................................. 7-30
7.4 DirectX Shifting Facility ........................................................................................................................... 7-30
7.4.1 Introduction .................................................................................................................................... 7-30
7.4.2 Background ..................................................................................................................................... 7-31
7.4.3 DirectX Button Shifting ................................................................................................................... 7-32
7.4.4 DirectX POV Hat Shifting ................................................................................................................. 7-33
7.4.5 Advanced Information .................................................................................................................... 7-34
7.4.6 How to change DX shift magnitude in the falcon bms.cfg: ............................................................ 7-35
7.5 DX Device limitation: .............................................................................................................................. 7-36
8 The DX Device Order:.................................................................................................................8-38

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

2 CATEGORIES & SECTIONS:


I divided the key file into different categories and sections. I have to admit, it has been done before. The
difference is that you can see the section names in the key file. While scrolling down (this happens sometimes too
quickly to find a specific function easily) you will now have some eye catchers.

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.

2.1 CATEGORY AND SECTION CODE LINES


The categories and sections are easily recognizable in the code:

2.1.1 Key File Description (Key file content / UI output):


SimDoNothing -1 0 0XFFFFFFFF 0 0 0 -1 "BMS - Full"

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.

2.1.2 Category example (Key file content / UI output):


SimDoNothing -1 0 0XFFFFFFFF 0 0 0 -1 "1. UI & 3RD PARTY SOFTWARE"

2.1.3 Section example (Key file content / UI output):


SimDoNothing -1 0 0XFFFFFFFF 0 0 0 -1 "======== 1.01 UI FUNCTIONS ========"

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.2 NON CATEGORY & SECTION LINES IN THE UI:

2.2.1 Non changeable keys example (Key file content / UI output):


SimDoNothing -1 0 0XFFFFFFFF 0 0 0 -0 "REM: Hardcoded (not changeable)"

2.2.2 Changeable keys example (Key file content / UI output):


SimRadarElevationUp -1 0 0XFFFFFFFF 0 0 0 1 "TQS: ANT ELEV Knob - Tilt Up"

2.2.3 Invisible keys example (Key file content / UI output):


CommandsSetKeyCombo -1 0 0X2C 2 0 0 -2 "Key Combination"
<- This is a screenshot. Believe me 

The UI will look like this:

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

1. Term: Short form of the section name followed by a colon.

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:

 AUX: CNI Knob – Toggle


 GEAR: HOOK Switch – DN

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:

 RADIO: AWACS Menu


 SIM: Exit Sim

3.1 FIRST TERM:


As mentioned above, the 1. Term is a short form of a section name. Sometimes it’s easily done. For the TEST Panel
for example it is just TEST. But you have some sections where you have to be careful with naming. EXT LIGHTING
panel (LEFT CONSOLE) and LIGHTING panel (RIGHT CONSOLE) for example. The term for EXT LIGHTING is „EXT“
and for LIGHTING it is „LIGHT“ in this case.

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

3.2 SECOND TERM:


The 2nd term describes a switch / button / wheel or knob. In most cases you will find the correct designation as it
is inscribed on the panel.

Examples: HSI CRS, 2-ALOW, MAIN PWR…

It is followed by the type. The types are:

 Buttons: e.g. ICP buttons on the ICP


 Switches: e.g. MASTER ARM Switch on MISC panel
 Wheels: e.g. PITCH Wheel on the TRIM panel
 Knobs: e.g. ENG FEED on FUEL panel
 Handles: e.g. EJECT Handle

3.3 THIRD TERM:


The third term describes a function or the positions / states of a switch, knob etc.

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:

Push (for buttons):

Pushing a button describes a single action.

(e.g. ICP Buttons)

Hold (for buttons and switches):

As long as you hold the button or switch, it is active. If you release the button or switch, it is inactive.

(e.g. EPU GEN Switch)

This one is also for functions which need a long input to become active. E.g. the EJECT Handle

Release (for buttons):

Release action for pushbuttons.

(e.g. MAL & IND LTS Button)

Toggle (for switches, knobs, buttons and functions):

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

Step Up / Down (for knobs, wheels & switches):

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)

Cycle Up / Down (for switches and knobs):

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)

(ON – AUTO – OFF – ON – AUTO…) & (ON – OFF – AUTO – ON – OFF…)

Cycle (for switches and knobs):

Same as above but only in one (!) direction. You cannot cycle in the opposite direction, because there is no
callback for it.

(ON – AUTO – OFF – ON – AUTO…)

Increase / Decrease (for knobs and wheels):

Incr. / Decr. is only used for knobs and wheels which change brightness, volume, degree values or pressure. It is
also used for FOV.

(Increase Brightness / Decrease Volume…)

States / Positions (for knobs & switches):

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

3.4 UPPER CASE VS. LOWER CASE:


All categories and sections are written always in upper case. (LEFT CONSOLE, VIEWS…)

The first term is always written in upper case. (TEST, OXY…)

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.

3.5 KEYS VS. MOUSE (RIGHT / LEFT CLICK, SCROLL WHEEL):


Nearly all wheels & knobs can be turned either using the mouse buttons or the mouse wheel (clockwise – left btn.
or mouse wheel up / counterclockwise – right btn. or mouse wheel down).

For cycle, toggle and toggle up/down callbacks you have to use the right and left mouse button. (With some
exceptions)

For pushbuttons you only need the left mouse button.

3-11
BMS KEY FILE MANUAL
CHANGE 1

4 OVERVIEW CATEGORIES & SECTIONS:


Category Section Short form
1. UI & 3RD PARTY 1.01 UI FUNCTIONS UI
SOFTWARE 1.02 3RD PARTY SOFTWARE 3RD

Category Section Short form


2.01 TEST PANEL TEST
2.02 FLT CONTROL PANEL FLT
2.03 ANTI G PANEL (n/i) ANTI
2.04 MANUAL TRIM PANEL TRIM
2.05 FUEL PANEL FUEL
2.06 AUX COMM PANEL AUX
2.07 EXT LIGHTING PANEL EXT
2.08 EPU PANEL EPU
2.09 ELEC PANEL ELEC
2. LEFT CONSOLE 2.10 AVTR PANEL AVTR
2.11 ECM PANEL ECM
2.12 ENG & JET START PANEL ENG
2.13 AUDIO 2 PANEL AUDIO2
2.14 AUDIO 1 PANEL AUDIO1
2.15 MPO PANEL MPO
2.16 UHF PANEL UHF
2.17 LEFT SIDE WALL LEFT WALL
2.18 SEAT SEAT
2.19 THROTTLE QUADRANT SYSTEM TQS

Category Section Short form


3.01 ALT GEAR CONTROL ALT GEAR
3.02 TWA PANEL TWA
3. LEFT AUX CONSOLE 3.03 HMCS PANEL HMCS
3.04 CMDS PANEL CMDS
3.05 GEAR PANEL GEAR

Category Section Short form


4.01 MISC PANEL MISC
4.02 LEFT EYEBROW EYE
4.03 TWP TWP
4.04 LEFT MFD LMFD
4. CENTER CONSOLE 4.05 ICP ICP
4.06 MAIN INSTRUMENT MAIN
4.07 INSTR MODE PANEL INSTR
4.08 FUEL QTY SEL PANEL QTY
4.09 RIGHT MFD RMFD

4-12
BMS KEY FILE MANUAL
CHANGE 1

Category Section Short form


5.01 SNSR PWR PANEL SNSR
5.02 HUD HUD
5.03 NUCLEAR CONSENT PANEL (n/i) NUC
5.04 LIGHTING PANEL LIGHT
5.05 AIR COND PANEL AIR
5. RIGHT CONSOLE 5.06 ZEROIZE PANEL ZERO
5.07 KY58 PANEL (n/i) KY58
5.08 ANTI ICE / ANT SEL PANEL (n/i) ANT
5.09 AVIONICS POWER PANEL AVIONICS
5.10 OXYGEN PANEL OXY
5.11 FLIGHT STICK STICK

Category Section Short form


6.01 OTHER COCKPIT CALLBACKS CKPIT
6.02 SHORTCUTS SHORT
6.03 KEYBOARD FLIGHT CONTROLS FCTRL
6. MISCELLANEOUS 6.04 EXTRA MFD (THIRD) TMFD
6.05 EXTRA MFD (FOURTH) FMFD
6.06 SIMULATION & HARDWARE SIM
6.07 WINAMP WINAMP

Category Section Short form


7.01 VIEW GENERAL CONTROL VIEWGEN
7. VIEWS 7.02 VIEW INTERNAL VIEWINT
7.03 VIEW EXTERNAL VIEWEXT

Category Section Short form


8.01 GENERAL RADIO OPTIONS RADIO
8.02 AWACS COMMS AWACS
8.03 ATC COMMS ATC
8. RADIO COMMS 8.04 TANKER COMMS TANKER
8.05 WINGMAN COMMAND WINGMAN
8.06 ELEMENT COMMAND ELEMENT
8.07 FLIGHT COMMAND FLIGHT

Category Section Short form


9. Appendix: 9.01 OUTDATED LIST n/a

Category Section Short form


DirectX HOTAS UNSHIFTED n/a
(Examples, depends on your HOTAS SHIFTED n/a
settings, Note: Only Sections LEFT MFD n/a
visible in UI!!!) RIGHT MFD n/a

Remarks begin with the short form REM.


Sectiones labeled with (n/i) are currently not implemented.

4-13
BMS KEY FILE MANUAL
CHANGE 1

5 KEY FILES - GENERAL INFO:


As mentioned in the introduction, the key settings are not comparable to other common versions before. While
removing systematically all old and outdated or not working callbacks, I realized soon that there are a lot of free
keys available for mapping other callbacks. So I decided to remap almost everything.

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.

5.1 DEPRECATED & OUTDATED / DEV CALLBACKS:


I am not using a single old callback within my key files, as they will be removed completely from Falcon in the
future. Furthermore, all debug and testing callbacks are not implemented into my key files either. We have a
bunch of new callbacks while OTOH a lot of have been removed. Please refer to the Callback Updates.pdf to see,
what has changed.

5.2 TRACKIR, FRAPS & TEAMSPEAK:


A common weakness of any keyboard layout is the fact that they don’t incorporate 3rd party software like
TrackIR, Fraps or TeamSpeak. This is not an exclusive issue which is limited to Falcon keystrokes. This issue is now
solved, as these common tools are now taken into account by the Falcon BMS key files.

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

5.3 THE KEY FILE PROFILES:


There are five different key file profiles which use the same layout. They are using the key settings which can be
found in the keyboard layout files.

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

These files can be selected via BMS Setup menu.

2. YourBMSInstallFolder/Docs/Key Files & Input

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

6 THE INNER WORKING OF KEY FILES


If you are not familiar with editing key files you should read the following explanations of the inner working of key
files (originally gathered by Dunc for Falcon AF, but revised for use with BMS).

6.1 KEYBOARD CODE LINES


A typical key file code line looks like this:

AFGearToggle -1 0 0X22 0 0 0 1 "GEAR: LG Handle - Toggle"

Each code line is composed of nine different parts.

Note: The parts are separated by a blank character (Spaces shown with a red underline here).

AFGearToggle_-1_0_0X22_0_0_0_1_"GEAR: LG Handle - Toggle"

What each part does in a code line is described below.

6.1.1 First part: The callback


AFGearToggle -1 0 0X22 0 0 0 1 "GEAR: LG Handle - Toggle"

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.

6.1.2 Second part: Sound ID


AFGearToggle 118 0 0X22 0 0 0 1 "GEAR: LG Handle - Toggle"

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.

AFGearToggle -1 0 0X22 0 0 0 1 "GEAR: LG Handle - Toggle"

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

6.1.3 Third part: Not in use


AFGearToggle -1 0 0X22 0 0 0 1 "GEAR: LG Handle - Toggle"

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.

6.1.4 Fourth part: Keyboard key


AFGearToggle -1 0 0X22 0 0 0 1 "GEAR: LG Handle - Toggle"

(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.

Examples: 0X2 = “1” / 0X1E = “A” / 0X52 = “Num0” / 0XE = “Backspace”

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.

6.1.5 Fifth part: Modifier key


AFGearToggle -1 0 0X22 2 0 0 1 “GEAR: LG Handle – Toggle”

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:

Code # Modifier(s) key(s)


0 None
1 Shift
2 Ctrl
3 Ctrl Shift
4 Alt
5 Alt Shift
6 Ctrl Alt
7 Ctrl Shift Alt

Example with a modifier combination:

AFGearToggle -1 0 0X22 7 0 0 1 “GEAR: LG Handle – Toggle”

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.

AFGearToggle -1 0 0XFFFFFFFF 2 0 0 1 “GEAR: LG Handle – Toggle”

Also it is not distinguished between left & right modifier keys (e.g. left Shift / right Shift).

6.1.6 Sixth part: Key Combination key (Key Combo)


AFGearToggle -1 0 0X22 0 0x2E 4 1 “GEAR: LG Handle – Toggle”

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.

First we have to take a look at how to set a key combo.

CommandsSetKeyCombo -1 0 0x2E 4 0 0 0 "SIM: CommandsSetKeyCombo Alt+C"

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.

Assigning a key combination key with a key combination modifier:

CommandsSetKeyCombo -1 0 0x2E 4 0 0 0 "SIM: CommandsSetKeyCombo Alt+C"

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:

Key combo in relation with a single keyboard key:

AFGearToggle -1 0 0X22 0 0x2E 4 1 “GEAR: LG Handle – Toggle”

or a keyboard key + modifier key:

AFGearToggle -1 0 0X22 2 0x2E 4 1 “GEAR: LG Handle – Toggle”

The following examples won’t work:

Assigning a key combination key without a key combination modifier:

CommandsSetKeyCombo -1 0 0x2E 0 0 0 0 "SIM: CommandsSetKeyCombo C"

AFGearToggle -1 0 0X22 2 0x2E 0 1 “GEAR: LG Handle – Toggle”

Assigning a key combination modifier without a key combination key:

CommandsSetKeyCombo -1 0 0xFFFFFFFF 4 0 0 0 "SIM: CommandsSetKeyCombo Alt "

6-19
BMS KEY FILE MANUAL
CHANGE 1

6.1.7 Seventh part: Key combination modifier


AFGearToggle -1 0 0X22 0 0 0 1 “GEAR: LG Handle – Toggle”

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.

6.1.8 Eighth part: UI visibility


AFGearToggle -1 0 0X22 0 0 0 1 "GEAR: LG Handle - Toggle"

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).

Code # Description Used for


Visible Standard output line
1
(changeable) (editable in UI)
Headline Categories & sections
-1
(not changeable, blue background) (easy navigation)
Locked Remarks or functions not
-0
(not changeable, keys shown green) meant to be changed by user
Hidden Important code lines, e.g.
-2
(Invisible in UI) some general radio options

Example: Visible

AFGearToggle -1 0 0X22 0 0 0 1 "GEAR: LG Handle - Toggle"

Example: Headline

AFGearToggle -1 0 0X22 0 0 0 -1 "GEAR: LG Handle - Toggle"

Example: Visible locked

AFGearToggle -1 0 0X22 0 0 0 -0 "GEAR: LG Handle - Toggle"

6-20
BMS KEY FILE MANUAL
CHANGE 1

Example: Hidden (no screenshot here, of course)

AFGearToggle -1 0 0X22 0 0 0 -2 "GEAR: LG Handle - Toggle"

6.1.9 Ninth part: UI description


AFGearToggle -1 0 0X22 0 0 0 1 "GEAR: LG Handle - Toggle"

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)"

6.2 DIRECTX BUTTON CODE LINES


A typical key file DX code line looks like this:

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

What each part does in a code line is described below.

6.2.1 First part: The Callback


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.

6.2.2 Second part: The DX button ID


SimTriggerFirstDetent 0 -1 -2 0 0x0 0

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.

6.2.3 Third part: Callback invocation behaviour


SimTriggerFirstDetent 0 -1 -2 0 0x0 0

DX code lines distinguish between three states when a callback is invoked. These are:

Default, Key Up, Key Down

We have four code values for the third part of the DX code line:

Code Callback invocation


-1 Default (Both: Key up and Key down)
-2 Key down only
-4 Key up only
8 DX button assignment in BMS UI (default behaviour)
What you can do with these values is described later on.

6.2.4 Fourth part: DX button identifier


SimTriggerFirstDetent 0 -1 -2 0 0x0 0

This value distinguishes between DX buttons (value -2) and POV hats (value -3).

6.2.5 Fifth part: DX button press / release event


SimTriggerFirstDetent 0 -1 -2 0 0x0 0

SimTriggerFirstDetent 0 -1 -2 0x42 0x0 0

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.

6.2.6 Sixth part: Not used


SimTriggerFirstDetent 0 -1 -2 0 0x0 0

This part never changes in a DX code line and should be left untouched.

6.2.7 Seventh part (optional): Sound ID


SimTriggerFirstDetent 0 -1 -2 0 0x0 0

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

6.2.8 Eighth part (optional): The description


SimTriggerFirstDetent 0 -1 -2 0 0x0 0 “DX: STICK – Trigger 1st Detent”

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.

6.3 DIRECTX POV HAT CODE LINES


POV code lines have a slightly different syntax. A typical key file DX code line looks like this:

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

What each part does in a code line is described below.

6.3.1 First part: The Callback


AFElevatorTrimUp 0 -1 -3 0 0x0 0

See 6.2.1

6.3.2 Second part: POV Hat number


AFElevatorTrimUp 0 -1 -3 0 0x0 0

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.

Hat # 1 POV Hat 2 POV Hats 4 POV Hats


0 unshifted POV 1 unshifted POV 1
1 n/a POV 2 unshifted POV 2
2 shifted POV 1 shifted POV 3
3 n/a POV 2 shifted POV 4

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

6.3.3 Third part: Not used


AFElevatorTrimUp 0 -1 -3 0 0x0 0

This part is always -1.

6.3.4 Fourth part: POV Hat identifier


AFElevatorTrimUp 0 -1 -3 0 0x0 0

This value distinguishes between DX buttons (value -2) and POV hats (value -3).

6.3.5 Fifth part: Panning direction


AFElevatorTrimUp 0 -1 -3 0 0x0 0

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:

6.3.6 Sixth part: Not used


AFElevatorTrimUp 0 -1 -3 0 0x0 0

This part is always 0x0.

6.3.7 Seventh part (optional): Sound ID


AFElevatorTrimUp 0 -1 -3 0 0x0 0

The sound IDs work for POV code lines as well. 0 or -1 deactivates sound.

6.3.8 Eighth part (optional): The description


AFElevatorTrimUp 0 -1 -3 0 0x0 0 “DX: Trim Elevator Up”

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

7 HOW TO EDIT KEY FILES:


There are multiple ways of editing key files. Which one you prefer is your personal choice. We’d like to introduce
you the possibilities to personalize it to your liking.

7.1 ASSIGNMENTS VIA BMS SETUP MENU

7.1.1 Key Assignments:


In the past it was not recommended to change key assignments via setup UI in BMS. This has changed as some
work has been done code wise. So you may change your key assignments in the UI now. The only thing you have
to keep in mind is that all comment lines will be deleted after saving. So saving in BMS UI can work. Using an
editor for that work is on the other hand maybe the first choice, even if it is inconvenient. Note: We do not take
responsibility in case something bad happens to your key file while editing it in the UI!

Let’s start with a short example of a key file. This is how it looks in an editor:

And this how it looks in the UI:

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.

In this case “Shift Ctrl Alt F1”.

Here is what has changed in the key file itself:

7.1.2 DirectX Assignments:


We can easily assign DX functions to our devices via the BMS UI. To give you an example I’ve created a short
sample key file.

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”.

7.2 EDITING KEY FILES WITH THE KEY FILE EDITOR:


I’ve created a new Key File Editor based on Excel files (BMS Key File Editor) based on the idea of the original
Keyfile-generator by Boxer.

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.3 USING AN EDITOR:

7.3.1 Manually Editing Keyboard Code Lines


As mentioned earlier, it is not recommended to change the key settings in BMS setup. It might work, but can also
damage your key file. You can edit the key files with the standard Windows editor or any other comparable
program. I suggest using Notepad++, IMHO the best freeware editor.

7-27
BMS KEY FILE MANUAL
CHANGE 1

It can be downloaded here.

A part of a key file in Notepad++ will look like this:

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

7.3.2 How to avoid multiple key assignations:


If you understood what each part of a key file code line does it will be rather easy modifying existing or creating
own customised files. Most likely you will only have to make the decision which functions to add and which keys
(plus modifiers) to assign.

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

7.3.3 Manually editing DirectX Code Lines:


In the following some examples:

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 DIRECTX SHIFTING FACILITY


By Dunc

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 DirectX Button Handling

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.

BMS DirectX POV Hat Handling

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.

7.4.3 DirectX Button Shifting

Concept and Usage

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.

Enabling Shift and Configuring Offset

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.

How to change the DX Shifting Magnitude is described later on.

7-32
BMS KEY FILE MANUAL
CHANGE 1

Mapping the Shift Button

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).

It is NOT possible to have more than one DX shifting layer.

But it is possible to assign the callback SimHotasPinkyShift to more than one physical DX button.

7.4.4 DirectX POV Hat Shifting

Concept and Usage

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

7.4.5 Advanced Information

Specifying the Pinky Tapping Time

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.

Shifting Multiple Devices Simultaneously

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.

Minimizing Side Effects

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.

To compensate for such restrictions, a special callback has been introduced:

SimDoNothing

This callback does exactly what it says: nothing.

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.

7.4.6 How to change DX shift magnitude in the falcon bms.cfg:


First, open your falcon BMS.cfg with an editor like notepad++. You find it in

BMS Install Folder / User / Config

Once opened scroll a bit down until you find the “Misc Settings” section.

7-35
BMS KEY FILE MANUAL
CHANGE 1

Look for the code line

set g_nHotasPinkyShiftMagnitude 256

The default value is 256.

Change this value to 0 to disable shifting:

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.

7.5 DX DEVICE LIMITATION:


The maximum number of DX devices support is 16.

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

To clarify that here some examples:

First example: 8 DX devices with a shifted layer (default)

set g_nHotasPinkyShiftMagnitude 256

# of device WIN DX # BMS DX # BMS shifted


Device 1 1 ... 32 0 ... 31 256 ... 287
Device 2 33 ... 64 32 ... 63 288 ... 319
Device 3 65 ... 96 64 ... 95 320 ... 351
Device 4 97 ... 128 96 ... 127 352 ... 383
Device 5 129 ... 160 128 ... 159 384 ... 415
Device 6 161 ... 192 160 ... 191 416 ... 447
Device 7 193 ... 224 192 ... 223 448 ... 479
Device 8 225 ... 256 224 ... 255 480 ... 511

Second example: 16 DX devices with a shifted layer

set g_nHotasPinkyShiftMagnitude 512

# of device WIN DX # BMS DX # BMS shifted


Device 1 1 ... 32 0 ... 31 512 ... 543
Device 2 33 ... 64 32 ... 63 544 ... 575
Device 3 65 ... 96 64 ... 95 576 … 607
Device 4 97 ... 128 96 ... 127 608 … 639
Device 5 129 … 160 128 … 159 640 … 671
Device 6 161 … 192 160 …191 672 …703
Device 7 193 … 224 192 … 223 704 …735
Device 8 225 …256 224 … 255 736 … 767
Device 9 257 … 288 256 … 287 768 …799
Device 10 289 … 320 288 … 319 800 …831
Device 11 321 … 352 320 … 351 832 …863
Device 12 353 … 384 352 … 383 864 … 895
Device 13 385 ... 416 384 ... 415 896 ... 927
Device 14 417 ... 448 416 ... 447 928 ... 959
Device 15 449 ... 480 448 ... 479 960 ... 991
Device 16 481 ... 512 480 ... 511 992 ... 1023

7-37
BMS KEY FILE MANUAL
CHANGE 1

8 THE DX DEVICE ORDER:

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.

Following list should clarify that:

WIN DX # BMS DX # # of device


1 ... 32 0 ... 31 Device 1
33 ... 64 32 ... 63 Device 2
65 ... 96 64 ... 95 Device 3
And so on...

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.

8.2 HOW TO AVOID DX DEVICE ORDER AND AXIS CHANGES


A new feature has been introduced with BMS 4.33 U1.

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

9 DIRECTX DEVICE SPECIFICS:

9.1 HOW TO CANCEL MRM/DF OVERRIDE MODES:

Note: This is TM HOTAS Cougar specific.

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.

9.2 HOW TO OVERCOME DX BUTTON SHORTCOMINGS?

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:

Function Name Script Name DX button ID


Testcallback
(on HOTAS) (in TARGET) Windows BMS device 2
PATH APPAT 27 58 SimRFNorm
ALT/HDG APAH n/a 58 / 59 SimRFQuiet
ALT APALT 28 59 SimRFSilent

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).

And here is, how it works:

default DX code line:


Callback 4 -1 -2 0 0x0 0

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

DX code lines with new key up/ down semantic:


Callback1 4 -2 -2 0 0x0 0
Callback2 4 -2 -2 0x42 0x0 0

4 = DX button number (same as default code line)


-2 = -2 invokes the callback with a key down semantic
0x42 = 0x42 invokes the callback when the DX button is released

To keep the story short.


With these both lines we can assign two different callbacks to one and the same DX button number! One for press
and one for release.

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

And this is what happens:

SimRFNorm 58 -2 -2 0 0x0 0
DX button press event -> SimRFNorm

SimRFQuiet 58 -2 -2 0x42 0x0 0


DX button release event -> SimRFQuiet

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

10 KEY FILE OPTIONS & SPECIFICS:

10.1 CHANGING ICP-NUMPAD MAPPING (1=7 -> 7=1):


In my key file the mapping for ICP on the numpad is OSB 1= NUM 1, OSB 7= NUM 7.

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).

SimICPTILS 1 0 0X47 0 0 0 1 "ICP: 1-ILS"

SimICPALOW 1 0 0X48 0 0 0 1 "ICP: 2-ALOW"

SimICPTHREE 1 0 0X49 0 0 0 1 "ICP: 3"

SimICPStpt 1 0 0X4B 0 0 0 1 "ICP: 4-STPT"

SimICPCrus 1 0 0X4C 0 0 0 1 "ICP: 5-CRUS"

SimICPSIX 1 0 0X4D 0 0 0 1 "ICP: 6-TIME"

SimICPMark 1 0 0X4F 0 0 0 1 "ICP: 7-MARK"

SimICPEIGHT 1 0 0X50 0 0 0 1 "ICP: 8-FIX"

SimICPNINE 1 0 0X51 0 0 0 1 "ICP: 9-A-CAL"

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:

Set TRIM to unshifted layer:

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

Set Views to shifted layer:

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

Add other functions to unshifted / shifted layer:

Of course it is possible to assign any callback you want to the POV hat. The code lines follow always the same
syntax.

AddFunctionOfYourChoice: Replace this with another callback.

0/2: Chose unshifted (0) or shifted (2) layer.

AddFunctionOfYourChoice 0/2 -1 -3 0 0x0 0


SimDoNothing 0/2 -1 -3 1 0x0 0
AddFunctionOfYourChoice 0/2 -1 -3 2 0x0 0
SimDoNothing 0/2 -1 -3 3 0x0 0
AddFunctionOfYourChoice 0/2 -1 -3 4 0x0 0
SimDoNothing 0/2 -1 -3 5 0x0 0
AddFunctionOfYourChoice 0/2 -1 -3 6 0x0 0
SimDoNothing 0/2 -1 -3 7 0x0 0

10-44
BMS KEY FILE MANUAL
CHANGE 1

10.3 ASSIGNING KEYS TO EXTRA MFDS (3RD & 4TH MFD):


I didn’t assign any keys to the 3rd and 4th MFDs because the situations where you would use them are pretty rare.
As far as I know it is not possible to use them at all at the moment.

Be advised: They are for non F-16 MFD control only, if an AC has three or more MFDs.

A suggestion for mapping is:

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.

10.4 DOUBLE ENTRIES:


There are some functions, which are present at two (or more) different locations. These are:

AFResetTrim (Reset Trim):

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:

11.1 WHY DOES BMS CRASH WHEN LOADING A KEY FILE?


Check your key file for syntax errors. As we don’t have external tools for checking the key files (like a debugger)
we have to use BMS. Of course you can check your key file manually. But this could be a rather time consuming
task.

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.

11.2 STUCK KEY:


This issue has been seen quite often in the forum. A stuck key issue appears when you are using shifted functions.
In this case it doesn’t matter if you are using the shifted function with your keyboard (key with modifier/s) or with
your DX input device (Pinky Shift with DX button). A popular example is the TRIM function.

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)

2. Press keyboard key / DX button and hold it

3. Continue holding both (1 & 2) as long as desired

4. Release keyboard key / DX button

5. Release 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.3 HOW TO ENABLE EYEFLY (FREE CAM):


We have a free cam (to be activated with the callback: OTWToggleEyeFly). To get it to work you have to execute
the Falcon BMS.exe with the command “–ef”, like "Falcon BMS.exe" –ef. Otherwise you’ll get the message “EyeFly
Disabled”.

11-46
BMS KEY FILE MANUAL
CHANGE 1

11.4 THE MOUSE DOESN’T WORK ANYMORE IN PIT:


You have most likely invoked the function “Clickable Pit Mode – Toggle”. This function toggles between Mouse On
and Mouse Off in the cockpit. In the key files this function is assigned to Alt + 3.

11.5 KEYBOARD KEYS AND COMBINATIONS YOU HAVE TO BE CAREFUL WITH:


In general you have to be careful with all Windows related shortcuts, especially if you are using windowed mode.
A complete list can be found in the BMS Key File Editor.xls on Key Code Data sheet.

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

See also (Pretty) Screenshot vs. PrtScr above.

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.

Del & Num , (Del)

Ctrl Alt + Del


Ctrl Alt Num , (Del)

Also these combinations will bring you back to Windows.

11.6 (PRETTY) SCREENSHOT VS. PRTSCR:


If you take a deeper look into the key files you will realize, that there are no keys assigned to the callbacks
ScreenShot and PrettyScreenShot. On the opposite PrtScr button is assigned to SimDoNothing. And here is the
reason why:

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).

set g_bPrettyScreenShot 0 = Screenshot (with text overlays)

set g_bPrettyScreenShot 1 = Pretty Screenshot (without text overlays)

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

11.7 WHY WE DON’T HEAR COCKPIT SOUNDS WHEN PRESSING A KEY:


As described above the 2D Pit ID numbers are old remains from “2D Pit days”. As we don’t have 2D Pits nowadays
we don’t need them anymore. Also the 4-digit numbers (referenced in the 16_ckpit.dat), which could invoke
cockpit sounds when pressing the assigned key, are also outdated now. So if you still use them in your key file you
won’t hear a sound. Of course the same is true if the sound ID is set to -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.

Sound ID Sound file


115 cockpit\toggllil.ogg
116 cockpit\rtryknob.ogg
117 cockpit\ejectlvr.ogg
118 cockpit\geardwn.ogg
119 cockpit\gearup.ogg
120 cockpit\icp1.ogg
121 cockpit\icp2.ogg
122 cockpit\icpmntry.ogg
123 cockpit\jettison.ogg
124 cockpit\knobbig.ogg
125 cockpit\knoblil.ogg
126 cockpit\mfd.ogg
127 cockpit\momntary.ogg
129 cockpit\togglbig.ogg
309 cockpit\trimwheel.ogg
310 cockpit\toggsafe1.ogg
311 cockpit\toggsafe2.ogg
312 cockpit\pushbutton_in.ogg
313 cockpit\pushbutton_out.ogg
314 cockpit\pushbutton.ogg
315 cockpit\seatarm.ogg
316 cockpit\toggguard_in.ogg
317 cockpit\toggguard_out.ogg
318 cockpit\rwrbutton.ogg
319 cockpit\magswitch_in.ogg
320 cockpit\magswitch_out.ogg
321 cockpit\altgeardwn.ogg
322 cockpit\cnpyhndl.ogg

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

12 NOTES ON THE NEW PITBUILDER KEY FILE:

12.1 GENERAL NOTES:


As mentioned earlier in this manual we have in fact two different keyboard layouts.

The first one is for the average Joe Pilot, the second one is a dedicated to pitbuilders.

The purpose of a different pitbuilders keyboard layout is obvious:

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.2 UNCOMMENTED KEYBOARD LAYOUT:

12-51
BMS KEY FILE MANUAL
CHANGE 1

12-52
BMS KEY FILE MANUAL
CHANGE 1

12.3 KEYBOARD LAYOUT WITH COMMENTS:


Long Press Test Panel, 3rd Party Software & ICP (shift)
1 → Left Aux & Center Console
1 → Left Console

Views
1 → L & R MFDs 2 → L Aux & C
2 → Left Console

Comms Long Press Panel & Pause


3 → Left Aux & Center Console
3 → 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

HOTAS & ICP (shift)


6 → Main Instrument 6 →
Right Console ← 9 Right Console ← 5

HOTAS & ICP (shift) HOTAS, View & ICP (shift)


7 → Main Instrument 4 → L & R MFDs
Right Console ← 8 Right Console ← 4

HOTAS, View & ICP (shift)


3 → L & R MFDs
Right Console ← 3

HOTAS, View & ICP (shift)


8 → 2 → L & R MFDs
← 7 Right Console ← 2

HOTAS & ICP (shift) HOTAS & ICP (shift)


9 → Main Instrument 5 → L & R MFDs
Right Console ← 6 Right Console ← 1

12-54

You might also like