This very well may be a bug so obscure it affects only me, and surprisingly, it’s not the only time I’ve seen it occur but … here we go.

Like many people with physical limitations, I use the Microsoft StickeyKey tool to make my control/alt/shift keys toggles instead of continuous presses. Sins has no problem with this in the vast main — except when it comes to zooming in or out using the scroll wheel after I’ve used the one-touch toggle to capitalize a key-press.

More specifically, let me lay out the sequence:

• I use the shift-twice to lock Shift on and type or hit keys or use the mouse, behavious is completely as expected for holding shift. Zoom is slowed, all letters are capped, things can be added to selections, no problem.
• I, while naming a ship or entering chat, hit shift-once, which only affects the next key press and the system leaves “shift on” after the next key press, and it functions perfectly reasonably except the non-text-entry section of the UI thinks shift is still on. This breaks any number of operations and is generally annoying.

Sometimes I can try and return to normal operations by shift-thricing to roll through the toggle-lock-on and toggle-lock-off states and it’ll recognize things as back to normal, other times it requires that I shift-five-times to turn off StickeyKeys altogether and then again to turn it back on.

The truly odd thing about it is that the text UI fields never have a problem. Even when the UI thinks that shift is on for zoom slowing, etc, when it shouldn’t the text chat and renaming fields act completely normally, accepting the SK shift adjustments just like everything should.

I know that as far as bugs go this isn’t a massive world-devourer (it would look silly on the front of an Evacuator, anyway), but it is annoying and so few developers seem to give a rip about accessibility issues that it’s nice Sins is as interface-friendly as it is.

Thanks in advance, guys.