Page MenuHomeFeedback Tracker

Enable mods to create custom input actions
Closed, ResolvedPublic


Current state

Currently, if you want to have a keyboard control that is fully bindable through the controls interface and does not conflict with any default game keybinds, you are forced to use the 20 preset "Use action ##" controls.

Even if you use that, you will still potentially conflict with other mods if they chose to use that action for one of their actions.

"Use action ##" is very limited and deceiving, the problem with this is that due to the limited preset of these actions multiple mods can use the same action. For a real world example off the top of my head, ALiVE mod and the A10C mods currently use the Use Action 20 for their actions which can cause conflicts. Even if there were thousands, they would still be potential conflict points if two creators like the Use Action 1337. Predefined, non namespaced, "slots" would be fine if you worked in a vacuum where other mods don't exist, but unfortunately, that is not the case.

Other options like hardcoding and userconfigs are simply unacceptable for a streamlined experience where the user should have full control over each action he can perform over the "Controls" interface in the options. ACE mod for Arma 2 even went as far as creating an external exe to make this slightly streamlined for the user.

Modders are currently able to:

  • Create custom user action groups for the controls menu through configs (UserActionGroups class)
  • Create conflicts for the controls menu through configs (UserActionsConflictGroups class)
  • Tie actions added with addAction to input actions (7th parameter for addAction called "shortcut"
  • Read the state of an input action with inputAction command (
  • Retrieve dikCodes, key names, images, localized action names for the keys assigned to input actions

Proposed additions/changes

To fully enable modders to ditch dirty or custom solutions for inclusion of new controls which do not conflict with the, the only thing left to do is to enable them to actually create inputActions, the rest of things needed to use them is already there.

Once this is done, an addition of an event handler which could listen for a change/trigger of an input action would be a natural next step in enhancing the way controls are handled by mods.

The current "Use action ##" actions should remain as is, to provide compatibility for scripts that rely on them.


Legacy ID
Operating System
Windows 7
Additional Information

Event Timeline

Sniperwolf572 edited Additional Information. (Show Details)
Sniperwolf572 set Category to Scripting.
Sniperwolf572 set Reproducibility to N/A.
Sniperwolf572 set Severity to None.
Sniperwolf572 set Resolution to Open.
Sniperwolf572 set Legacy ID to 78875313.May 7 2016, 6:00 PM

Totally agree with this one, it's a feature that got requested a lot of times and got anwsered on A2 with the "1-20 user actions" keys, that are pretty limited.

One thing Sniperwolf572 forgot to mention it's that, right now, to detect the key presses its really troublesome, since you need to attach your own keyhandlers to the main display. That method makes detecting special actions like joystick and mouse buttons really tricky, you need to do it by using hacky methods.

Been able to define new inputActions would be good, but will still need to check the keypress with by constant pooling(using inputAction), that would be either totally unrealiable(if donne with a simple loop) or could impact performance (more intensive loop like using perFrameHandler)

The custom keys should be able to be defined by config, as they are now, but you should be able to attach them to function that its called when the key it's presed and other when its released(and when i say key i mean the one that the user selected for that action, that could be a joystick button, axis or a mouse button), just like a keyup and keydown events.

I won't call that part optional since it would be a real improvement on how you define actions and how you can can handle the user input in your addons

Edit: Ops, srry for the edit spam :P

That's what I meant in the last bit, "An optional addition would be to add an event handler which could listen for a change in an input action."

I currently do this like so, but it's potentially performance intensive if abused:

while {true} do {

Listen for the input actions. Done this way so the switch is responsive, allows for any keybind that
can be mapped and avoids custom code for detecting the mouse keys and key combos in the keydown event handlers
waitUntil {

		_isAction = inputaction "User17";
		(_isAction > 0);


// Do stuff here

// Throttle if holding
sleep 0.3;

As you say, this can be done better with a dedicated handler that listens to input actions instead of keys. You can also use addAction combined with the shortcut parameter for a poor mans inputAction event handler, but it's not usable in all cases.

If you read my last sentence, what i said its that i don't see that as "optional", its a really important part, as important as been able to add new inputactions.
Btw that loop using waitUntil its unreliable when client its under heavy load ^^(you will lose the keypress if isn't hold enought time), perframehandler its a bit more reliable(but still can fail if there is a dramatic client fps drop), but even more performance intensive. I already made a lot of testing trying to find out the best way to handle user input.

If you read my last sentence, what i said its that i don't see that as "optional", its a really important part, as important as been able to add new inputactions.

Ah yes, my bad. I agree, it is important. Amended the "optional" sentence to better fit what I actually meant. :)

doveman added a subscriber: doveman.May 7 2016, 6:00 PM

Totally agree with this. For a sensible way of handling mod keybinds, have a look at X-Plane. On this first screen, I click Add New Key Assignment, which adds a blank entry at the bottom

then clicking in the box highlighted at the top opens this screen, which lists all the plugins with assignable commands, where I can select one and then assign a key to it on the previous screen.

As long as each mod uses a unique name, like sandybarbour in this example, then there's no conflicts.

In ArmA, if you want to keep the controls screen as it is now, keep the Custom keys section but have it empty if nothing has been added, with an Add New Assignment button at the bottom, which opens a screen that shows all those mods which have defined commands, like X-Plane does. I'd ditch the current 20 user keybinds ASAP, to make sure modders move away from that old, unworkable, system.

I now understand that ArmA already has a way to add Custom categories to the Controls settings (like this, just not Custom actions. So all that needs to be done is to provide for this, then define a place in addons where the creator specifies a Category name and the actions provided and then ArmA3 should automatically add the Category and actions, for the user to assign as he sees fit. It would be nice if the addon creator could specify default keys as well, which the user can then change if the GUI shows there are conflicts with existing keybinds.

Still not implemented which is a great shame.

dedmen changed the task status from Assigned to Feedback.Jun 23 2021, 4:53 PM
LouMontana closed this task as Resolved.Mon, Sep 19, 5:22 PM
LouMontana updated the task description. (Show Details)
LouMontana edited Steps To Reproduce. (Show Details)
LouMontana edited Additional Information. (Show Details)
LouMontana set Operating System to Windows 7.