Currently, the macro keeps the fork - once started - running forever.
I was thinking about stopping the forked macro whenever the user releases both keys. That’s easy to implement, because it would just exit when it returns to state 0.
The next press of one of the keys would then fork it again.
Now I am imagining a user in an action game repeatedly tapping the key. There will be a lot of forks and exits. Would it be better to keep it running?
We don’t mess up things 
… never
(I keep a running state and do not start it again as long as an instance is active.)
I’ve optimised the macros a bit more.
The worker (snap-leftright-worker) will now self-terminate if more than 5 seconds have passed and you release both keys. As long as you keep at least one of the keys pressed it will keep working (looping). And it will always run for at least 5 seconds even if you release both keys during that time.
This limits the amount of forking to a maximum of 1 fork per 5 seconds, and it also limits the runtime of the worker to a maximum of 5 more seconds once you let go of the keys.
It will indicate when the worker is running by showing <-> on the Led display.
The initiator (snap-leftright) is now also shorter and more concise. Less code to execute on each keypress. Faster to set the new mode when it registers a new keypress.
snap-leftright:
if ($thisKeyId == $keyId.j) setVar snap_mode 1
else if ($thisKeyId == $keyId.l) setVar snap_mode 2
else setVar snap_mode 0
if ($snap_running == 0) fork snap-leftright-worker
delayUntilRelease
ifKeyActive $keyId.j final setVar snap_mode 1
ifKeyActive $keyId.l final setVar snap_mode 2
setVar snap_mode 0
snap-leftright-worker:
setVar snap_running 1
setVar snap_state 0
setLedTxt 0 '<->'
loop:
if ($snap_state == 0) {
if ($snap_mode == 1) {
releaseKey right
pressKey left
}
else if ($snap_mode == 2) {
releaseKey left
pressKey right
}
}
else if ($snap_state == 1) {
if ($snap_mode == 0) {
releaseKey left
releaseKey right
}
else if ($snap_mode == 2) {
releaseKey left
pressKey right
}
}
else if ($snap_state == 2) {
if ($snap_mode == 0) {
releaseKey right
releaseKey left
}
else if ($snap_mode == 1) {
releaseKey right
pressKey left
}
}
setVar snap_state $snap_mode
if ($snap_mode != 0) goTo loop
ifNotPlaytime 5000 goTo loop
setVar snap_running 0
setLedTxt 1 '<->'
This is interesting. Some online PvP games anti-cheat detects this behaviour implement in software as bannable. That’s what has kicked off such a controversy with Razer’s product as, being implemented in firmware, it is undetectable by anti-cheat.
Offering up for info, not judgement.
I played for a couple hours using these & it seems to work fine so far. The “<->” indicator is a nice touch BTW.
I get your point here, but it’s ridiculous to even try to ban hardware. Maybe they should just start scanning systems for hardware IDs. Oh wait… they already do, and people spoof those too. Maybe gamers should be forced to use 10" 720p 30Hz monitors & the lowest tier CPU/GPU. Two button binary keyboards and monophonic audio only. Wearing an eyepatch and socks on their hands…
Let’s really level the playing field 
derp
If the speed at which you can change direction is really that crucial to fairness, it should be baked into the game’s code. The devs should consider limiting movement with an animation delay or whatever, instead of using buggy system crashing anti-cheat systems. Treat the source, not the symptom.
I almost always stick to PVE or single player games due to my neuropathy. But with this snap-tap feature, I’m one side-step closer to working my way back into PVP. Without it, no amount of practice would help.
If this comment comes across as being rude, I don’t intend it to be. I just honestly don’t see why this isn’t an option for all keyboards. It’s a tool. A very useful tool.
Thanks for the feedback! Happy to know it’s working. I didn’t do any gaming with it myself; it’s been a while since I played some Counterstrike etc. but I was spurred on by the macro programming challenge 
– just to prove how flexible the UHK and its smart macro programming language are. (Well done, @kareltucek!)
Maexxx, thank you and all the others that take the time to read through the forums and help us all.
I absolutely appreciate mlac & kareltucek’s work (and everyone else involved). Minds like all of yours are a gift for sure.
I bought a V1 way-back-when through Crowd Supply (snagged V2 recently too). I’ve been lurking around here and Github since the early days. I don’t understand half of what I read, but it’s fascinating nonetheless.
The UHK has actually improved my life tremendously over last few years. I know that may seem silly, but it really has. It’s ergonomics have reduced my physical limitations quite a bit, and automating tasks with smart macros significantly cuts down the time it takes to do just about everything.
I saw this today. I don’t play CS2, but hopefully this doesn’t extend to too many other games…
Yay! The battle between anti-cheat mechanics and hardware vendors has begun. We’ve just passed level 1.
Level 2: figuring out when the anti-cheat triggers, and optimising the snap-tap feature to be just a bit slower.
Level 3: making sure the deliberate slowing down of snap-tap is not constant, but jiggles over time just as a user would not always have the exact same timing.
Level 4: use machine learning and AI to figure out where the border for anti-cheat detection lies.
Level 5: human players are now affected by anti-cheat because snap-tap passes the Turing test and is indistinguishable from human players. Competitive playing is now only allowed on certified hardware with locked-down software installation (certificate chains, TPM, locked-down bootloader etc.)
Gaming is fun! Gaming the game is even more fun!
Made my day! 
SnapTapGPT, here we come! 
As expected, Valve have implemented detection for hardware based SOCD.
