 |
https://www.benchmarksims.org/forum/showthread.php?41797-Sticky-DX-shift |
|
|
What would be the expected behavior? My expectation would be one of (a) release the shift, and release the shifted-layer button.. or (b) release the shift and invoke the unshifted-layer button. Definitely not (c) keep shifted layer button on forever |
|
|
I was about to simply stop using dx-shift buttons entirely .. but now I realize the problem is much bigger. It affects keyboard shift/ctrl/alt modifiers too. I sometimes notice my speedbrakes stick on at 100%, with gear down.. not auto-retracting to 72%. Releasing [shift] before [B] sticks the [B] keypress down forever .. tapping [shift] again, alone, is not enough to release it. You have to [shift+B] again and release the [B] key before the [shift] key. Most of my long-press-and-hold key bindings are nonshifted .. for obvious usability reasons. But there are plenty of momentary-hold keys which are shifted, like [shift+B] to deploy speedbrakes, which now seems almost certainly to have killed me once or twice. This is easily repro'd this .. gear down on approach .. [shift][B][^B][^shift] => brakes auto retract down to 72% [shift][B][^shift][^B] => brakes stuck on at 100% |
 |
Yup, well known since at least 4.32, and the reason combos are not recommended. Is stuck modifiers not an issue for other games? |
|
|
I've edited this to "confirmed" as this is a well known, long-standing bug, and "minor" severity, as a workaround exists (don't use combinations for anything needing to be held down, always ensure keys are released in reverse order of keypress). |
|
|
Thanks for the title edit. I can't speak to other games or sims but at the OS level this is handled better. [shift][B]...[^shift][^B] results in BBBBBBBBBBBBbbbbbbbbbbbbbb (and you'll notice Windows resets the repeat-delay timer, at the transition, so it's functionally equivalent to releasing both [shift] and [B], then quickly depressing [b] key again) BMS is more complex than Windows because certain callbacks have press-to-activate semantics, others have press-and-hold semantics (brakes, throttle, manual zoom, cursor slew, view panning, etc) and maybe even depends on context (eg. press pickle to fire sidewinder, vs hold pickle to consent bomb release) But certainly this is a very solvable problem. Just because something has been broken for a long time .. and documented with a warning, doesn't mean it's not a bug that should be fixed. Priority can be triaged by BMS team (with due consideration of level of effort .. and I can appreciate, from seeing evidence of how it uses GetAsyncKeyState in eg. issue 0000093 that this code may be quite old and hairy and fragile to change) But at some point this is consuming more time and effort to explain that it would cost to fix. Here's a thread from 2017, very smart people incl internal BMS dev who are confused by the laser stuck on.. and I'm pretty sure in hindsight OP is just using pinky-shift + trigger to activate TriggerFirstDetent, and releasing pinky before releasing trigger (which would seems quite natural to me, tbh). https://www.benchmarksims.org/forum/showthread.php?29879-Laser-permanently-lasing-after-short-manual-lase/page2 |
|
|
Of course. Note that I'm not making a determination of priority, just severity. The definition I'm operating on for severity is that minor and major bugs both affect our ability to use the software to simulate air combat, and that minor bugs have workarounds, while major bugs do not. Issues can be closed if they are not fixable, or suspended if they are planned to be fixed but cannot be fixed yet. I'm hopeful that this is more along the lines of difficult, but doable. I'm not arguing that this is not solvable. |
|
|
Cool, severity sounds right by that definition. My instinct here is to push back against those who say "it's not a bug" because it's documented.. or because "it's been that way for years". After all, if that were the bug bar, nothing would ever get fixed or improved and BMS would not exist. |
|
|
Also I should clarify my BBBbbb point above -- it's *good* that BMS doesn't behave that way. (I just did a quick smoke test, and it doesn't seem to.) Else, you can imagine a key combo like [ctrl+alt+shift+L] to toggle the carrier launch bar.. rolling off the keys in the wrong order would cycle your landing lights, toggle laser arm, and turn off power to your chaff/flare dispenser, and finally zoom your fov. lol |
|
|
It's not an ideal solution, but it's probably the easiest to implement. It's not a bug. It's supposed to be that way, even though it's obviously suboptimal. |
|
|
I don't agree that any reasonable PM would document "callback stays on forever" as expected behavior for user releasing keys a couple milliseconds out of order. It's insidious. There is a warning about this bug, in technical-manual sec 10.10.2 (troubleshooting section). But it's clearly a warning about undesirable behavior -- this is not the same as documenting intentional behavior of a feature -- it's a warning about a bug. Right after another warning that says "Why does BMS crash when ..." I suppose, if these problems are tracked and triaged elsewhere (internally by BMS team) and this bug report offers no additional value, we can close it. I'm just looking for ways to make BMS better. |
|
|
To clarify, the point of this tracker is to track bugs externally, for the purpose of making it clear what is a "known issue" to community members. If bugs are tracked and triaged elsewhere, that helps the BMS devs, but it doesn't help community members - and it leads to many duplicate threads on the BMS forums about the same issues. To that end, I suggest this report does add value to both the community and the devs, and I'd prefer we not close it, until or unless we can resolve it. |
- Anonymous
