Gaming Config (Tips & Tricks?)

Configuration question
21

$onInit:

releaseKey LS

Update: as @kareltucek noted below, it should be:

releaseKey persistent LS
1 Like
22

I suspect ifHold.

Yep. Conditions that look into the future unfortunately take some time to evaluate ;-).

(ifDoubletap looks into the past instead. That’s why ifGesture $thisKeyId (which is the same but looks into the future) is sometimes needed instead of ifDoubletap.)

•If LShift is toggled on when performing a reboot, all the above macros have a stuck LShift afterwards (until tapping LShift again).

This is actually surprising.

All the above macros persist across keymap changes (expected?).

Yes.

Of course, adding setVar runningLS 0 to $onKeymapChange fixes it for Karel’s original macro, but is there a way to fix it for the new toggleKey macros as well?

Actually:

releaseKey persistent LS

I am wondering if releaseKey without persistent should remove the scancode from both sets of usb reports to avoid bugs like this one. Any opinions?

2 Likes
23

Yeah, probably. I can’t think of a use case where you wanted to releaseKey only in this macro, but when the macro ends, the releasing should stop and re-enter the global state, i.e. press it again. That would be super weird.

For me, persistant is more like doNotAutoreleaseAtEndOfMacro. But I guess for modifiers it has a few more implications than just suppressing the sending of release reports.

24

releaseKey doesn’t trigger any kind of negative mask, so if it is active in global state, then releaseKey (without persist) will have no effect actually.

25

Which is also weird, or at least, quite incomprehensible, will need explicit documentation, and I am sure a number of people will stumble.

26

Not suggesting to actually implement it that way, but a thought experiment:

Let’s say everything is persistent without that keyword. So it would be obvious what the engine does – it just follows the order of press and release and toggle commands, no matter in which macro they are executed. Pressed keys remain pressed until released or toggled etc.

Then, we add 1 additional keyword, autorelease, which makes sure that when you pressKey autorelease b that key (b) is automatically released when the macro ends.

That would be very logical and easy to understand – at least in my view of the world.

1 Like
27

Interesting idea. I am not convinced so far.

Let’s say that I have a simple shift macro:

pressKey iLS
delayUntilRelease
releaseKey iLS

or even just

holdKey iLS

and I have it bound on both left and right shift.

Now what happens if I press both shifts and then release one of them?

Clearly keeping just the global state isn’t what we are after. I am wondering if there is a way to fix this aspect.

Of course, we want to keep backward compatibility, so I am not happy about changing the default behavior.

28

Actually I can’t reproduce this.

Although it is plausible that UHK80 isn’t sending an empty report at the beginning of its operation and the host OS just keeps the pre-reboot usb report states even though the usb interface has been restarted.

I am wondering - what exactly happens when you toggle the shift and disconnect the keyboard instead? :smiley:

1 Like
29

The clue bar just hit me upside the head. (Damn that hurt.)

Documentation suggestion for the macro reference: Where applicable conditions should be annotated with “looks into past” / “looks into future” (annotation: probably an icon) That should help clear this up for anyone trying to get macros of this kind to work correctly.

2 Likes
30

I checked for output events from the UHK80 and my eight-button mouse (Corsair M65 RGB Ultra) using a few games and AutoHotkey 2’s mouse/keyboard hook. Nothing is reported from the UHK80’s 6-20 buttons, and the Corsair mouse only shows events that are mapped to normal scancodes with it’s dedicated software/driver.:disappointed_face: Oh well, it was worth a shot.

31

Ok, you’re correct; Windows is retaining the LShift state when I unplug the UHK80’s USB. Weird. My android phone releases the state as expected when rebooting the UHK80.

Apparently, it’s been a known issue since Windows 8. :roll_eyes::

Although, I can’t reproduce it by disconnecting the UHK while manually holding down a regular (non-macro) modifier, like they say in that link.

32

Now after reading through the rest of this stuff, I’m even more confused. :thinking: This is why I don’t often mess with macros that aren’t either super-simple one-liners, or click-to-add an action.:sweat_smile: I have a hard time remembering the interplay of all the variables, and I have no idea how to structure stuff. Idk how you guys do it… :face_without_mouth:

I promise, I’m much dumber than I might seem. :rofl:
Old dog/new tricks, as they say…

Ok, so I think I’ve got a useable macro by mimicking similar behavior to “Activate the layer by holding this key”, with “Lock layer when double tapping this key” enabled. Do you guys see any potential issues with the following?:

Mimic Double-Tap Layer Lock

holdKey LS
ifDoubletap toggleKey persistent LS
ifNotDoubletap releaseKey persistent LS

Does that even need to be persistent for my usecase of toggling sprinting in-game? It seems to work great as it is above. I also added releaseKey persistent LS to $onKeymapChange any and I’ll probably add it to certain $onLayerChange keys as well.

And while I’m at it; is it possible to add a color change only when toggled on, and then change it back when released?

33

Try this instead and see if it does what you want:

ifDoubletap final pressKey persistent LS
releaseKey persistent LS
holdKey LS

My interpretation of what you want:

  • doubletapping should lock shift key
  • single press (tap or hold) will unlock shift key
  • single hold will act as normal shift (while held)

Structure of the macro:

  • if double tapped (= on second tap of a double tap), press LS down and keep it pressed. This is the final instruction; stop executing the macro here.
  • otherwise (= on first tap of a double tap, or on a subsequent single tap, or on holding): First, release any locked LS, second, hold LS as long as the key is held (acting as a normal shift key).

I haven’t tested this; there may be errors.

1 Like
34

Yeah, I see the problem with this use case.

What if we added a counter? Every pressKey would need a matching releaseKey until the key is actually released. If pressCount > 0 then the key is pressed.

When $pressCount[$scancode] transitions from 0 to 1, issue a press report for $scancode.
When $pressCount[$scancode] transitions from 1 to 0, issue a release report for $scancode.
Other transitions (to and from values > 1), do not issue any report.

35

So… No toggleKey at all. :melting_face:

Thanks!
Your macro works fine. I can’t notice any real difference between the two in real use, but your explanation is much more “MAX Concise”. :wink: That helped me to understand a little better.

1 Like
36

What if we added a counter? Every pressKey would need a matching releaseKey until the key is actually released. If pressCount > 0 then the key is pressed.

Just no.

(Reasons: memory, you loose information about where that press came from, …)

That should work too :wink:

1 Like
37

How about the UHK 60 in this respect?