Sending true F13-F24 keypresses to macro keyboards, mice, etc

First and foremost, I need to dispell some misinformation out there.

At one point decades ago it may have, but Windows has long since discarded that convention. Most any macro capture today will capture it as Shift+F1, not F13.

Second, some may wonder why you’d want to use F13-F24. In a word, deconfliction. Star Citizen uses a LOT of keybinds by default, not leaving a lot of free keys for Push-To-Talk and such. While Star Citizen doesn’t recognize F13-F24 many other applications do, such as Mumble and TrackIR’s software. In the case of TrackIR the default keys are F7, F9, and F12, which are also used by SC. TrackIR, Mumble, and many others will however recognize F13 and above.

So, how to go about this? Some devices software has this built-in such as Corsairs iCue software with a K95 keyboard. You can assign a G key to F13-F24 via a drop-down menu. However, some software such as Logitech’s Options+ does not, but relies only on capture. That is where AutoHotKey comes in. Note you only have to run AHK while you are performing the capture. Afterward you can close it or uninstall as you like.

  1. Got to and download the latest stable 2.0 version.
  2. Install AHK
  3. Create a blank text file and paste the following
    Sleep, 5000
    Send {F13}
  4. Rename the file to FDelayed.ahk (must not end in .txt)
  5. When your device’s software is about ready to capture your “keypress”, double left-click on the .ahk file and then immediate go the capture field. F13 will be sent 5 seconds after you clicked on the file.

You can go to to test if it is working, to rule out issues with your software. You will want to edit the file for F14 and beyond, but once you are done, you can quit AHK or remove it completely.

I hope you find this useful and not too confusing. If you have any questions or suggestions, please let me know.


One thing to add regarding running applications “as administrator”. I understand some do this as a workaround to other issues, and with Mumble in particular. This is NOT recommended generally, and I don’t just mean from a security POV. It can have unintended consequences and can mask a larger problem that should be resolved.

In our case it can block Mumble’s ability to see the F13-F24 keypresses in my post above.

Nearest I can figure is running it in admin mode removes it from user isolation and so it can’t communicate correctly for the lack of drivers that the user is still running separately in it’s own virtualized isolation/workspace/desktop.