"While" loop sometimes stuck

[alexbib]

I'm building a rapid fire function for a game that needs the key to come up before it can be pressed again. Now my code looks like this:

Code: Select all

$a::   
While GetKeyState("a","P"){
    Send {b down}
    sleep 10
    Send {b up}
    sleep 10
}
Return

It works, but sometimes (maybe once out of 20), the loop gets stuck and keeps sending the b inputs even after I've stopped pressing a. The only way to get it to stop is to press a again (which is pretty weird).

I've searched an found similar issues, but none with a solution that works with my script. I cannot simply Send {b}, the game doesn't register the input unless the key comes up and down. Any ideas?

Thanks!
Alex

[Xtra]

Similar to a recent post:

Code: Select all

$a Up::run := false
$a::
    run := true
    While run
    {
        Send, {b Down}
        Sleep, 10
        Send, {b Up}
        Sleep, 10
    }
return

HTH

[alexbib]

Similar to a recent post:

Code: Select all

$a Up::run := false
$a::
    run := true
    While run
    {
        Send, {b Down}
        Sleep, 10
        Send, {b Up}
        Sleep, 10
    }
return

HTH

Just tried it, it behaves the same. I'm trying to understand what is failing and why it only does it once in a while, but for now I'm out of ideas.

[Xtra]

Try changing the "a up" hotkey to this:
$*a Up::run := false

[alexbib]

Try changing the "a up" hotkey to this:
$*a Up::run := false

Still doesn't work. Thanks for the help though, I do appreciate it!

[swagfag]

first off, do u have any other similar while loops or other infinite loops in your script, or is the script youre running comprised solely of what youve posted here?
if you answered yes, you need to realize that ahk doesnt support parallelism of this sort and that the loops will interfere with each other, often leading to unpredictable or otherwise undesirable results.

anyway, u can try sending B Up once again explicitly after the loop, see if it helps:

Code: Select all

$a::   
While GetKeyState("a","P"){
    Send {b down}
    sleep 10
    Send {b up}
    sleep 10
}
Send {b Up}
Return

[alexbib]

first off, do u have any other similar while loops or other infinite loops in your script, or is the script youre running comprised solely of what youve posted here?
if you answered yes, you need to realize that ahk doesnt support parallelism of this sort and that the loops will interfere with each other, often leading to unpredictable or otherwise undesirable results.

anyway, u can try sending B Up once again explicitly after the loop, see if it helps

I tried adding the extra B Up after the loop, it didn't help.

I do have 3 of these for different buttons. I tried splitting them off into their own script each. I also gave them all different variable names, just in case. It didn't change anything, buttons still got stuck fairly often.

[divanebaba]

Hi.
Help-file says:

P: Retrieve the physical state (i.e. whether the user is physically holding it down). The physical state of a key or mouse button will usually be the same as the logical state unless the keyboard and/or mouse hooks are installed, in which case it will accurately reflect whether or not the user is physically holding down the key or button (as long as it was pressed down while the script was running). You can determine if your script is using the hooks via the KeyHistory command or menu item. You can force the hooks to be installed by adding the #InstallKeybdHook and/or #InstallMouseHook directives to the script.

I've never used Keyboard-Hook. You can try it now and report later, if it works or not.

[alexbib]

I've never used Keyboard-Hook. You can try it now and report later, if it works or not.

Nope, unfortunately adding #InstallKeybdHook at the start of the script does not seem to help. It's a really weird bug, somehow it thinks the key is still being pressed, or it just stops checking.

Also, is someone able to replicate the bug? Searching gives a few similar issues so I'm not the only one, but no reliable solution seems mentioned anywhere:

https://autohotkey.com/board/topic/7908 ... ets-stuck/
https://autohotkey.com/board/topic/8331 ... ets-stuck/
https://autohotkey.com/board/topic/8713 ... tkey-help/

[Noesis]

I have encountered a similar issue but nothing like the 1/20 you report, for me it's more 1/20000, if even that frequently, i.e very rarely but has happened on occasion, but only when the system is running under load (i.e CPU & GPU maxing usage).

One thing that could be causing a greater frequency of issues is that you have 2 other similar loops. Essentially they can interfere with each other, if more than 1 is trying to run at a time, the first activated key will be kind of locked on until the latest one finishes, since ahk is single threaded, and each hotkey starts a new thread. Rather than split the loops into different scripts (which I'd have thought would work btw) perhaps incorporate them all into a single routine instead would help, and/or using a timer instead of the loops could help here.

Another possibility is the length of the sleeps being too short. USB keyboards are polled anyway, unlike the old ps/2 style keyboards which were event driven, so a USB keyboard is only checked every x milliseconds or maybe x nanoseconds but either way they're polled, and since it's a game you're trying this with, games have their own input polling rate, and don't forget ahk itself has limitations on granularity of sleep delay, so increasing the sleeps to 15, 20, 30 each could possibly help.

[alexbib]

only when the system is running under load (i.e CPU & GPU maxing usage).

Rather than split the loops into different scripts (which I'd have thought would work btw) perhaps incorporate them all into a single routine instead would help, and/or using a timer instead of the loops could help here.

...so increasing the sleeps to 15, 20, 30 each could possibly help.

My system isn't under a very heavy load for that game, I've got one logical core (out of 8) at 80% and gpu around 30%.

I tried removing all but one of the routines to rule out interference between them, and it gets stuck anyway, so reworking them into a single one wouldn't help. Maybe I can try a timer/counter (and add to it while I keep the button pressed?).

I've tried increasing the sleep delays, it doesn't help at all, if anything it gets worse (but in the other direction it doesn't get better if I decrease the delays to 5 or 1).

[Noesis]

Fair enough, I'm just taking a few stabs in the dark, as I don't know why it's happening for you, it doesn't for me and my guess is it doesn't for most other people either.
Something that may help is increasing the script process priority to either above normal or high, using something like "Process, Priority,,High". But I'm not sure if it would make a difference or not, especially as you're system isn't being taxed when this happens. Sorry can't be much more of a help.

[alexbib]

Fair enough, I'm just taking a few stabs in the dark, as I don't know why it's happening for you, it doesn't for me and my guess is it doesn't for most other people either.
Something that may help is increasing the script process priority to either above normal or high, using something like "Process, Priority,,High". But I'm not sure if it would make a difference or not, especially as you're system isn't being taxed when this happens. Sorry can't be much more of a help.

Thanks for the suggestions

I tried increasing the process priority to high, didn't help (or maybe a little, but not much).

Also, I tried an explicit counter:

Code: Select all

*$a:: 
runa := 1
While runa >= 1
{
    Send {b down}
    sleep 10
    Send {b up}
    sleep 10
    If GetKeyState("a","P")
        runa++
    runa--
}
KeyWait, a
Return

Same bug happens.

[whereyomomsat_]

Having a very similar bug. Wondering if you have figured anything out? Thanks!

[mikeyww]

Specific questions:
1. Is this the entire script, or is there more code?
2. Are other scripts also running?
3. What other keys or buttons are being pressed?

Would also read about key jamming. viewtopic.php?p=460331#p460331

About the hook:
1. When the hook is used, it is also installed.
2. Wildcard hotkeys always use the keyboard hook, as do any hotkeys eclipsed by a wildcard hotkey.
3. If at least one variant of a keyboard hotkey has the tilde modifier, that hotkey always uses the keyboard hook.
4. The $ prefix forces the keyboard hook to be used.
5. Mouse hotkeys always use the mouse hook.
6. "Up" hotkeys and their key-down counterparts (if any) always use the keyboard hook.
7. Custom combinations involving keyboard keys always use the keyboard hook, as do any hotkeys which use the prefix key as a suffix.