AIRCRAFT SPECIFIC INPUT PROFILES
The purpose of an aircraft specific input profile, is to create input mappings for an individual aircraft that lets you create inputs based on the different controls and requirements of the aircraft. For example, if you are creating an aircraft for firefighting missions, then you may want to map a specific input to opening the liquid drop doors.
To set up this kind of profile you will need to have an aircraft package to start from, and if you wish to include input mappings for specific controllers, then we recommend having those devices at hand too (and ensuring that they have a device profile already present in the simulation). Keep in mind that, when setting up this kind of profile, the aircraft type may already have a category profile for the devices you want it to support, so you should check the simulation controls setup to see what these inputs are. If they are adequate for the aircraft, then you do not need to map these inputs in the aircraft profile. You can find out more about this from the following page:
Setting Up The Aircraft Package For Inputs
To start with you will need to open the aircraft package in the Project Editor and then open the Input Profile Editor. From this window you will be adding the custom controls for the aircraft, which will be based on what's defined in the aircraft Model Behaviors. initially the window will be empty and the first thing you need to do is select the aircraft package from the Assets section:
Once selected, the Input Editor will parse all the files, and create a list of "nodes" within the modular structure that have input events in their Model Behavior files. These will need to be added to the package sources ActionDB file, which is a local file used to generate the final package Input Configuration XML file, from the Input Editor. This is done by first selecting the modular node you wish to add from the Node drop-down menu:
Once you have selected a node, you need to click the Build ActionDB button. After a short pause as the DB is created/updated, you can then repeat this process for each of the nodes with inputs you want to add custom controls for. Each DB file will be stored with the node that it was created from.
Create The Input Profile File
Having set up the DB file, the next thing to do is create the base file to add the different inputs to for the final package. This is done by clicking on the + button beside the File list (which will be empty), which will open the following window:
Here you need to give the file a name, and then setup the device and platform for which you are defining the inputs. For the category, it should match the aircraft that profile is being applied to, for example, the Cabri would have a "Helicopter" profile, while the DA62 would have an "Airplane" profile, etc...
Next you give the device details for the profile, since you can set up multiple different profiles to cover various devices for each aircraft or aircraft part. If you have the device available you can simply plug it into your PC then select Use A Device Connected To Your Computer to select the device from the drop-down list.
If you don't have the device then you will have to supply the following:
- Product ID - This is the unique product ID, expressed as a hexadecimal value, format
0x0000. - Composite ID - The composite ID is an integer value used to link multiple parts of a single product to a unique product ID (e.g. HOTAS…)
- Hardware Version - Similar to the composite ID, the hardware ID is used to link multiple parts together when they do not all belong to a single product ID.
Once you have this information, you should give the profile an appropriate name, and then click the Ok button. This will save the profile XML to the package and it can now be edited in the Input Profile Editor.
Note that you will need to repeat this process for each device that you want to associate with your behaviour inputs, and for each node in the modular aircraft that you want to create custom inputs for.
Editing The ActionDB Inputs
Once you have created your first set of ActionDB entries, you need to set them up for exporting with the final package as part of the Input Configuration XML for the aircraft (the ActionDb file is an intermediary file and is not exported with the aircraft, nor should it be necessary to edit this file).
At this point the Input Profile Editor will look something like this:
To edit the different model behaviour input actions and associate them with specific device inputs, you will first need to filter the list. In general, all other actions will have been setup through the Transversal and Aircraft Category profiles which have been set up already by the simulation team or specific device manufacturers. You can edit these if you wish, but you risk causing issues with users who expect certain "generic" inputs to do certain things (for example, changing the XBox gamepad throttle controls from A and B to something else will be a problem for users). So, to filter the list so that it shows only the appropriate inputs, set the Context to INPUT_EVENTS:
You can now go through the events and set up the different bindings between the behaviour input action and a device input. This is done using one of the following two methods:
- take the inputs directly from the device by clicking the Get Input button (
) and then moving the device joystick and/or pressing the device buttons.
Or:
- use the drop down list button (
) and select one or more inputs manually.
Note that regardless of the method chosen to add the device input, you can "group" inputs on a single action to have two or more device inputs required for it, for example: press A and joystick UP to raise the landing gear.
It should be noted that there are certain options available to you for each binding, and these can be accessed using the 
button, which will open the Action Options window:
From here you can choose from the various different type flags to use to modify the input. These type flags are all explained in detail here: Type Flags. Note that if you have checked the MOD VALUE type flag, you will have another option - Value Event - which allows you to change the value sent when the input is received (by default this is 0 / 1 or between 0 and 1 depending on the input), or if you are editing an Analogue or Axis input, then you will also have the Override Axis option.
You can go ahead and repeat this process for all the input actions that you wish to bind with custom controls, over all the different nodes of the modular aircraft, and for all the different controllers you need to map (note, you are not expected to bind all your custom input actions to some controls, only those that "make sense" within the simulation and that will be getting used frequently).
Remapping Actions
Another option when it comes ot setting up the inputs for your aircraft is the ability to remap specific UI prompts to use the localised name strings and MergeIcons of the inputs you have defined. In many/most cases this is completly uneccessary, but the option exists should it be required for your aircraft. Currently this is done from the Inputs tab of the SimObject Editor (future updates may change this):
The idea here is that some UI strings that are shown to the user will be localised to show the device input for the situation or a localised string. However, it may be that you have changed this from the default, or the device you're setting up the profile for is not one that is included in the simulation. As such you can select from one of these built-in UI strings, and then associate it with one (or more) of the inputs from your profile, so that the input MergeIcon or name string will be shown instead of the default. See here for more information:
Saving And Exporting The Project
Once you have set up all the input actions for the aircraft aircraft, you can save the Input Configuration XML to the package using the Save option from the File menu. Once you've saved the bindings you can go ahead and build the package (see Building A Package) and then test the bindings in the simulation (ie: select the aircraft and the appropriate controller and then start a flight, testing the different inputs that you have defined).