I have a controller with switches (non-momentary buttons) and I would like to use them for SAS and Breaks. AFBW supports this via the "SAS (hold)" and "Break (hold)" actions. However, if I press another button while "holding" that SAS or Break button (which is actually a switch so "holding" it doesn't require me to be touching it), the "hold" is broken; causing SAS/Break to be disengaged. To reengage the state I have to turn the switch off and back on. This is a pretty serious problem when using a switch to control SAS and then another button to control staging: Staging will disengage SAS.
Looking at the code it appears that the hold actions are implemented by setting the appropriate state when the correct button state (including all buttons on the controller) begins via a button press and clearing that state when the button state ends for any reason. This makes the above behavior make sense. Since combined button states are used instead of the state of a single button, overlapping button presses produces a state that is different from either button and hence a state that will not hold SAS (or whatever).
It appears that AFBW uses button states instead of individual buttons so it can support button chording to perform specific actions. However, the interaction with "hold" actions does not seem to be correct.
Proposed Solution
In my thinking about this, I have come up with the following solution, which I think would be backwards compatible with presets based on the current design.
Provide "set on" and "set off" actions for game states (like SAS, Breaks, and map view) and provide a way to map press and release events separately. The mapping could be done with two new UI button beside "Add Button" and "Add Axis": "Add Press" and "Add Release". Mappings setup this way could only have a single button and would trigger exactly when the button is pressed and released, respectively, regardless of the state of any other buttons.
I could configure this with button press (switch turned on) mapped to SAS on and button released (switch turned off) mapped to SAS off. That way, staging with a different button would not cause SAS to disengage and I could map as many different state switches as I wanted. I could even create my own "states" by using two different custom action groups to turn the state I want on and off, respectively.
I have a controller with switches (non-momentary buttons) and I would like to use them for SAS and Breaks. AFBW supports this via the "SAS (hold)" and "Break (hold)" actions. However, if I press another button while "holding" that SAS or Break button (which is actually a switch so "holding" it doesn't require me to be touching it), the "hold" is broken; causing SAS/Break to be disengaged. To reengage the state I have to turn the switch off and back on. This is a pretty serious problem when using a switch to control SAS and then another button to control staging: Staging will disengage SAS.
Looking at the code it appears that the hold actions are implemented by setting the appropriate state when the correct button state (including all buttons on the controller) begins via a button press and clearing that state when the button state ends for any reason. This makes the above behavior make sense. Since combined button states are used instead of the state of a single button, overlapping button presses produces a state that is different from either button and hence a state that will not hold SAS (or whatever).
It appears that AFBW uses button states instead of individual buttons so it can support button chording to perform specific actions. However, the interaction with "hold" actions does not seem to be correct.
Proposed Solution
In my thinking about this, I have come up with the following solution, which I think would be backwards compatible with presets based on the current design.
Provide "set on" and "set off" actions for game states (like SAS, Breaks, and map view) and provide a way to map press and release events separately. The mapping could be done with two new UI button beside "Add Button" and "Add Axis": "Add Press" and "Add Release". Mappings setup this way could only have a single button and would trigger exactly when the button is pressed and released, respectively, regardless of the state of any other buttons.
I could configure this with button press (switch turned on) mapped to SAS on and button released (switch turned off) mapped to SAS off. That way, staging with a different button would not cause SAS to disengage and I could map as many different state switches as I wanted. I could even create my own "states" by using two different custom action groups to turn the state I want on and off, respectively.