Open mmayers12 opened 5 years ago
I agree the behaviour you're seeing is not ideal as far as typical intent goes. The reason button remaps don't have this problem is that they get added to a system that ensures they get release no whenever the triggering button is released. The same issue was also happening when switching modes.
The underlying reason is that as far as Gremlin is concerned the press / release or various hat directions are completely independent and additional links have to be added to have Gremlin react "sensibly" to them. The current way that handles this for buttons works but is a bit awkward and has it's own issues with causing problems. So I think I may just have to look into a more intelligent way to decide when two actions are linked.
This seems similar to previous issues that look fixed, but I've found it persisting in conditional hat presses in release 12.
For example, I have dual Sticks, and I use the left trigger as a shift-state by binding it to
LEFT ALT
. Then I have my hats bound to a button onvJoy1
ifLEFT ALT
is released, and the same button onvJoy2
ifLEFT ALT
is pressed.If I want to use a shift-state on my hat, but I release the shift button before I release the hat, the virtual button that the hat is mapped to will be stuck on. Specifically, If I move the hat up with
LEFT ALT
pressed, then releaseLEFT ALT
before releasing the hat, thevJoy2
buttonhat up
is mapped to will remain stuck in pressed until I re-initiate the combo ofLEFT ALT
andhat up
again, this time releasing thehat up
before releasingLEFT ALT
.Similarly, the reverse is true. If I initiate the hat, then activate the shift state, the mapped button (or hat) on
vJoy1
will be stuck in pressed until I re-press and release that hat direction while the shift state is not active.As the user, the behavior that I'd expect is: when I activate the hat, produces the virtual action dependent upon the shift-state at the time of activation. Then when I release the hat, it releases that virtual action independent of the current shift-state (the virtual action remaining held as long as the hat is active, even if there is a change in shift-state). I believe this is how it works with mapping physical buttons to virtual buttons and a conditional shift-state.
Here's a snippet of the relevant section of my config.
For the sake of thoroughness, I've tested a direct mapping of physical hat to virtual hat, with a conditional shift-state, and encounter the same issue.