BUGFIX: Fix L=A by comparing the rawkeys to the previous keyinput #2042
Conversation
AreaZR
force-pushed
the
L=A
branch
2 times, most recently
from
d57c480
to
9c1a90e
Compare
…tead of the converted keys Also remap newAndRepeatedKeys
|
Is there somewhere in-game where I can verify that this change works? |
Absolutely. Because heldKeys compares with keyInput, holding the L button alongside holding another button means neither button will never be considered to be held if L=A is set. Holding L button alongside another button means both buttons are repeating. Honestly, we can get away with not adding A to newandrepeating because it is never checked for newandrepeating, but what was mentioned about the check above still applies. |
|
Sorry, I think you misunderstood my question. Where in-game should I test the L=A repeating behavior so that I can check that this PR works? |
Any menu where holding a button has a behavior. For instance, if you hold the L button while also holding the down button in the Pokedex, it won't scroll downwards, and instead just go down by 1 and remain, which is changed by this PR. |
|
In all honesty, we can completely get away with not remapping newAndRepeatedKeys, as the only values checked in this value are DPAD values, but I just have it here for completion's sake. I can remove it if you want. |
|
What do you think @mrgriffin? Should I even bother remapping newAndRepeatedKeys? |
|
I haven't had the time to familiarize myself with the code and test your change in-game yet. But once I've done that I can give you an opinion about |
|
Please let me know when you get the chance :) |
newAndRepeatedKeys is only checked for DPAD values, so it doesn't affect pret at all.
|
newAndRepeatedKeys is only checked for DPAD values, so it doesn't affect pret at all. Going to just take it out. |
|
"newAndRepeatedKeys is never remapped either." Should probably be moved to where the remapping happens, honestly. |
Also remap newAndRepeatedKeys