⚡ [performance improvement] Use SetTimer for non-blocking AHK loops

[Ven0m0]

💡 What: Refactored the core execution loops (BalconyLoop, BankRoofCleanLoop, BankRoofLootLoop, BankRoofAlwaysLoop, HoldClickLoop) in ahk/Black_ops_6/bo6-afk.ahk. They were transitioned from thread-blocking while + Sleep constructs into asynchronous, non-blocking state machines driven by SetTimer. Added explicit state cleanup (e.g., releasing {RButton up}) to handle mid-sequence aborts safely.

🎯 Why: The previous architecture used long-running blocking while loops (some up to 40 seconds, or infinite) combined with sleep calls. In AutoHotkey's pseudo-threading model, this effectively locked the executing thread. This caused unresponsiveness, dropped hotkey inputs, and the risk of hitting MaxThreadsPerHotkey limits. The new event-driven SetTimer approach frees the main thread instantly after every execution step.

📊 Measured Improvement:
Due to environmental constraints (running in an isolated Linux CI container without Wine or AHK execution capabilities), a live runtime benchmark could not be executed. However, this is a known architectural optimization in AutoHotkey. By converting blocking while loops into non-blocking SetTimer state machines, thread execution time per cycle theoretically drops from ~40+ seconds (blocking) to <1 millisecond (event firing), fundamentally removing the threading bottleneck and eliminating max thread exhaustion.

---

PR created automatically by Jules for task 9385229865483644965 started by @Ven0m0

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[gemini-code-assist]

Code Review

This pull request refactors the AFK loops in bo6-afk.ahk from blocking while loops to a non-blocking, timer-based architecture using SetTimer. Feedback focuses on addressing potential key-stuck issues due to AutoHotkey's threading model during interruptions, improving timing precision by using DllCall for short delays to comply with low-latency style guidelines, and simplifying conditional logic for better readability.

[gemini-code-assist]

The comment on lines 168-170 is slightly incorrect about AutoHotkey's threading model. A sleeping thread can be interrupted by a hotkey thread (like the one triggered by F7 to call StopAll). If WalkForwardAndBack() is interrupted, it could leave the {W} or {S} keys in a pressed state, as StopAll() only releases {LButton}. This can cause the character to be stuck moving. You should add cleanup logic here to release these keys.

            ; If aborted, ensure any keys from WalkForwardAndBack are released.
            Send("{W up}")
            Send("{S up}")
            return

[gemini-code-assist]

For short, precise delays, it's better to use DllCall("Sleep", "UInt", ...) instead of the Sleep command. The Sleep command can be imprecise, often sleeping for a minimum of 10-16ms regardless of the value provided. Since you're already using DllCall for sleeping elsewhere, it would be good to be consistent for better performance and predictability. This aligns with rule #40 of the repository style guide (Preserve low-latency behavior).

                DllCall("Sleep", "UInt", 10)

[gemini-code-assist]

For short, precise delays, it's better to use DllCall("Sleep", "UInt", ...) instead of the Sleep command. The Sleep command can be imprecise, often sleeping for a minimum of 10-16ms regardless of the value provided. Since you're already using DllCall for sleeping elsewhere, it would be good to be consistent for better performance and predictability. This aligns with rule #40 of the repository style guide (Preserve low-latency behavior).

                DllCall("Sleep", "UInt", 10)

[gemini-code-assist]

For short, precise delays, it's better to use DllCall("Sleep", "UInt", ...) instead of the Sleep command. The Sleep command can be imprecise, often sleeping for a minimum of 10-16ms regardless of the value provided. Since you're already using DllCall for sleeping elsewhere, it would be good to be consistent for better performance and predictability. This aligns with rule #40 of the repository style guide (Preserve low-latency behavior).

        DllCall("Sleep", "UInt", 10)

[gemini-code-assist]

This condition is functionally correct, but can be simplified for better readability. The only integer value for step that satisfies step > 4 && step <= 5 is 5.

            if (step == 5) {
                Send("{RButton up}")
            }