More key binding options to be more flexible (On Release, Cyclic, Multiple Actions, etc)

[FalcoGer]

I think generally the controls setup could use some work in DCS as a whole.

I will be using the following terminology: An action or key binding is what is being bound to, for example pressing a virtual button or setting a switch to a certain position in the cockpit. A button or switch is the user's hardware, attached to their computer. A button or switch can either be on (pressed or switched) or off (not pressed or switched in the default state). An axis is a variable, analog, physical input device that a user has attached to their computer.

The following would, in my opinion, greatly enhance the experience and allow more flexibility for binding actions. They can all be implemented incrementally and have no effect on one another.

An action for button release

There are multiple key bindings for "special" cases. For example in the Ka-50 Black shark 3 there is a special key binding for the laser arm switch, but for the Black shark 2 there is not. Those special key bindings act upon both pressing and releasing a button. This approach works, but only if the module developer adds those kinds of key bindings to their module and then they only work for those specific bindings.

It would be more flexible to allow users to do that with any action they choose. Add a binding for each switch position that can be selected. When binding that action to a button, the user may specify that the action happens "On Release" using a checkbox in the key assignment UI. This then allows the user to bind a hardware switch to laser arm on and use the same hardware switch to laser arm off in the Ka-50 Black Shark 2 as an example.

There are several benefits:

• Nothing needs to be changed, just the new feature added, Special key bindings can remain without breaking with no change and slowly be phased out
• Users can use this feature with any key binding they desire, allowing creative setups without the need for module developers to introduce special bindings for any and all switches
• Future aircraft will not require the implementation of special key bindings
• Special key bindings may be phased out, reducing the clutter and confusion during the key binding process

Assigning axis trigger points

Assigning axis values to actions would be nice. This would take the form of "If axis value is above/below (selectable) x% (also selectable), then do this action". Multiple such settings could be applied to one axis input.

A good use case for this would be assigning trigger axis on game controllers to actions. For instance if right trigger axis passes 10% then action first trigger detent, if above 95% then action second trigger detent, if it falls below 90% then release second trigger detent, if it falls below 5% then release first trigger detent.

This allows the use of spare axis as buttons or even multiple buttons.

Multiple assignments

Press one button and have it do multiple things at once. As long as those things do not conflict (for example setting the same virtual switch into two different positions), this should be fine.

Assign axis values on button presses

I'd like if I could press a button, and a virtual axis is assigned some value. For example I press a button and the formation light brightness knob is set to 0%, or any other arbitrary value I want.

Staged Actions

It would be handy if one was able to assign multiple a single button to multiple actions in such a way that each press triggers the next or previous stage in some internal state counter. And when that state switches it acts like a normal button press for key bindings. This would allow a user to assign a button and step through different actions on each press. For instance in the Apache one could configure a stage to press the different zoom buttons and then configure two buttons to go to the next and previous stage respectively. Suddenly you only need 2 hardware buttons to zoom in and out instead of 4. Or one to toggle between FLIR and TV, and suddenly you only need one button instead of 2. While not particularly realistic, it allows for users with limited or mismatching hardware to fly effectively.

The way I envision this is that there is a new, intermediary layer between the user's hardware and the key bindings. The interface could look similar to the trigger interface in the ME. The user configures this layer to have a name, a certain number of stages. The user then configures which binding is triggered for each stage when that stage turns on or off. An option might be needed for how long the stage keep each action engaged. Then new, virtual key bindings appear in the key binding list for each stage to be set explicitly as well as forward/backwards bindings and forwards/backwards bindings with cycling on the last/first element.

In the TADS FOV example above this would look something like this:

1. User enters key bindings screen for Apache CPG
2. User clicks a button, "Manage Staged Actions"
3. A list of such custom actions is displayed along with some buttons to add, edit or remove them.
4. The user clicks the add button
5. User enters a name for the staged actions, "TADS FOV"
6. A list of stages is presented along with an add and remove button.
7. The user adds 4 Stages
8. User defines names for each of the 4 stages ("Wide", "Med", "Narrow", "Zoom")
9. User defines the actions to be taken on each of the 4 stages (the respective button presses, and no actions on release)
10. User finalizes their decisions with an "OK" button.
11. A new category "TADS FOV" appears in the category list. New key bindings appear "TADS FOV - 1 - Wide", "TADS FOV - 2 - Med", etc., as well as "TADS FOV - Next Stage", "TADS FOV - Next Stage (Cyclic)", "TADS FOV - Previous Stage" and "TADS FOV - Previous Stage (Cyclic)"
12. User configures key binding "TADS FOV - Next Stage" and "TADS FOV - Previous Stage" and leaves the others unconfigured.

[Maverick806]

I would also really like to see the On Release bindings.