Announcement

Collapse
No announcement yet.

Bug: Modifier keys in combos not released if trigger held when exiting a Shift layer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bug: Modifier keys in combos not released if trigger held when exiting a Shift layer

    OS: Windows 10 x64
    reWASD 5.3.0

    Description:

    If a button in a shift layer is set to any key combo that involves modifiers (Ctrl, Shift, Alt) and is set to "Hold until release" mode, if that button is held while the shift is active and the shift is exited (either through toggle or the release of a hold triggered shift) before the button with the combo assignment is released, the assignment keeps firing. This i can see perhaps being intentional, though I'd enjoy an option to have the button return to its regular function as soon as the shift is exited; however, the issue is that when the button with the modifier combo is finally released, the modifier keys are NOT released within the system. So the end state is that the modifier keys are still in the "Down" position despite nothing being held any longer.

    Non-modifier buttons appear to release correctly. Somehow this order of events seems to stop reWASD from sending the "Up" events for modifier keys.

    Expected Behavior:

    Either:
    1) An option for "Hold until release" combos ending (Up event being sent) immediately when a shift layer is exited even if the button the combo is mapped to is still held
    2) Modifier keys being released correctly when the button is finally let go.

    Steps to Reproduce the Problem:
    1) Create a reWASD remap on any shift layer that uses a key combo involving any modifiers and is set to "Hold until release".
    2) Assign a shift button to access the layer on either hold, or toggle mode, it does not matter.
    3) Hold or toggle into the shift layer
    4) Hold the button that the key combo with modifiers is assigned to
    5) Release or untoggle the shift mode
    6) Release the button that the key combo with modifiers is assigned to

    Any modifiers involved in that key combo are now stuck down until you tap (if in hold mode) or toggle and untoggle (if in toggle mode) the shift trigger button.

    Demonstration Video for Clarification:
    The test combo here is Ctrl + Alt + F3. In this video the keyboard testing website shows white for unpressed keys, grey for keys that are held down, and green for keys that have been released, notice how when I perform the steps above, the Ctrl and Alt keys get stuck down even though I'm not holding anything anymore, yet F3 gets released as it should. Also, how i have to tap the shift modifier again (to quickly re-enter and re-exit the shift layer) for the release event to be sent to the system.



    Why this is a major issue:

    I can see this being a non-issue for a lot of people and recreating this bug does require a bit of a particular setup that may leave you wondering why I even need this exact functionality. Well, I discovered this because I have an Elite controller paddle assigned to enter a shift layer when held and on that shift layer are all sorts of functions that take place outside the active game, one of those being rewind for Retroarch emulation. Holding down left trigger while holding the paddle to be within the shift layer is rewind. For me and the people I'm used to using Retroarch with the triggers are the most ideal setup for throttle control and using a shift layer and the paddle means I don't need to completely take up the left trigger for rewind and it can still function as L2 in games that need it. The problem is that intuitively when you want to stop rewinding you would let go of both the trigger and the paddle to go back to normal game play and normal controls. But, if you let go of the paddle even a few milliseconds before letting go of the trigger, and therefore exit the shift before the combo is released, the Ctrl and Alt keys in my combo get stuck down and you lose complete control of the game because right Control is my hotkey toggle key (there are various reasons why I can't really use another one) and so Retroarch is still blocking game input until it is sent back up.

    Having to retap the shift button every time this happens is really annoying. I can see the modifier keys getting stuck really messing up people in much faster paced competitive games like an FPS as well.
    Last edited by oblivioncth; 09.04.2020, 08:38. Reason: Typos

  • #2
    Hello!

    Thanks a lot for the detailed report, confirmed, I can reproduce it too.
    Will try to fix in the next releases. Stay tuned!

    Comment


    • #3
      Thanks for the prompt repsonse and prioritization! Glad my experience of this otherwise great software won't be soured for too long.

      Comment


      • #4
        Hello,

        I ran into a very similar issue. I also use an elite controller with paddles and I use rewasd to remap it.

        Let me describe my configuration.

        Since the game doesn't offer an option of holding or toggling for crouching for controllers this is what I did:

        Click image for larger version

Name:	Screenshot (137).png
Views:	1085
Size:	565.3 KB
ID:	218951Click image for larger version

Name:	Screenshot (139).png
Views:	964
Size:	565.5 KB
ID:	218952
        I am simulating O on start press and X on release press of the right lower paddle to simulate a hold version of crouching. In order for this to work properly I have to block sprint when crouching because the game cancels crouch when you sprint and then the player would jump when the button is released. So this is how I solved this:

        Click image for larger version

Name:	Screenshot (140).png
Views:	956
Size:	574.5 KB
ID:	218953Click image for larger version

Name:	Screenshot (141).png
Views:	983
Size:	582.1 KB
ID:	218954
        The same paddle works as a shift button that enters a layer (shift layer 2) where the run button (L3) is unmapped. Everything is good so far. The issue appears when another shift layer is introduced. I use the left lower paddle also as a shift button to access another shift layer (shift layer 1) with some support actions.

        Click image for larger version

Name:	Screenshot (142).png
Views:	958
Size:	577.0 KB
ID:	218955

        If I hold down the shift layer 1 button, then hold crouch (the first shift button described which is also shit layer 2 button) and release shift layer 1 button again, the X button which is supposed to be simulated when the original button is released is never performed. Instead the action is transfered to the shift layer 1 button and the first time I press it again X is triggered the player jumps. I am sure that this is unwanted behaviour and it causes issues because the only way be avoided is by remembering to release shift layer 2 button before shift layer 1 button.

        I agree with oblivioncth on having the option to cancel combos when a shift button is released. Another feature that I think would be nice to exist is having the option of accessing other shift layers without previously releasing shift buttons currently held down. I understand that this could cause some weird behaviours but it can be solved by only accessing the layer of the latest shift button pressed and completly ignoring all previous shift buttons held (it would also be nice to have the ability to choose whether you can return to a previous shift layer that its button is still held when latest one is released or completely ignore all previous layers until their buttons are released).

        Don't get me wrong. This software is already amazing. It offers much more than the official software provided by the manufacturer but small details like this would provide much greater functionality and make this app really shine.

        Also another thing noticed is that some games do not recognize the virtual xbox 360 controller. This is also the reason I am using a virtual ds4 controller.

        Comment


        • #5
          Hey georgek

          Thanks for your detailed message.
          We have reproduced this issue, it is not exactly the one that is described above, and frankly speaking, it is much harder to fix. Still, will do our best.

          As for allowing go to Shift directly from another Shift, this is almost impossible in the current architecture. You made correct assumptions, there are some logical inconsistencies (much more than the one you have described), and we are not sure if we ever do this. But will keep in mind that we have this request

          And finally, some good news. We managed to find a workaround for the games which do not detect virtual Xbox 360 on the fly, and this improvement will be released in a few weeks. Using DS4 controller at the moment sounds like a great idea. Also, you may try to restart the game after you applied a config with Xbox 360, or even reboot the PC to make it work. But if you are OK with DS4, then it is easier

          Comment


          • #6
            Thanks for the reply. It's nice to hear that you are working on the issue. Also, great news on the Xbox 360 virtual controller detection issue!

            As for the Shift changes I understand the complexity of the matter but I still hope it's added at somepoint, it would really make a difference

            Comment


            • #7
              Hello,

              Thank you for your feedback, we will try our best.
              Don't worry! Be Happy!

              Comment


              • #8
                Hello, oblivioncth
                Glad to inform you that we fixed the bug with modifier keys in combos in the latest 5.4 version. It's available now, so please update your current install version to the latest one and confirm that the issue is not relevant anymore.

                Thank you in advance.
                Don't worry! Be Happy!

                Comment


                • #9
                  Hadn't logged into the forum in a really long time so I missed this, but I've (obviously) been using the fix for quite some time now and definitely haven't run into the issue again.

                  Thanks!

                  Comment


                  • #10
                    We are glad to hear it!

                    Comment

                    Working...
                    X