Change Details

## 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" https://community.bistudio.com/wiki/addAction#Syntax) - Read the state of an input action with inputAction command (https://community.bistudio.com/wiki/inputAction) - 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.

## 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" https://community.bistudio.com/wiki/addAction#Syntax) - Read the state of an input action with inputAction command (https://community.bistudio.com/wiki/inputAction) - 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.

## 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" https://community.bistudio.com/wiki/addAction#Syntax) - Read the state of an input action with inputAction command (https://community.bistudio.com/wiki/inputAction) - 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.