How to Create Key Combination Binds in Quake Live

Creating a modifier inside Quake Live
Adding more keys to the second layer
Why WinKey works well as a modifier
Using WinKey with AutoHotkey
Limitations and cfg placement

Quake Live has a flexible binding system, but it cannot directly bind combinations of two keys. Regular binds are simple:

Code:

bind q "weapon 2"
bind e "weapon 5"
bind mouse4 "say_team ^7ENEMY LOW"

What you cannot do is write:

Code:

bind CAPSLOCK+Q "say_team ^7LEFT"
bind WIN+1 "say_team ^7QUAD"
bind WIN+MWHEELUP "say_team ^7HIGH"

This becomes limiting once the convenient part of the keyboard is already occupied. In team modes especially, weapons, item calls, locations, drop commands and other communication binds can quickly use most keys within comfortable reach.

The workaround is to turn one existing key into a modifier. While it is held, selected controls execute an alternative set of commands; release it and their normal actions return. In practice, this gives part of the keyboard and mouse a second bind layer:

Code:

Q -> normal action
Modifier + Q -> alternative action

1 -> normal action
Modifier + 1 -> alternative action

WheelUp -> normal action
Modifier + WheelUp -> alternative action

It is similar to holding Shift or Fn: the modifier itself does not need to perform a gameplay action. Its job is to temporarily change what other keys do.

Creating a modifier inside Quake Live

The basic setup does not require any external software. You only need a key that Quake Live recognizes and that is free in your config. For example:

Code:

CAPSLOCK
HOME
INS
PGUP
PGDN
PAUSE
MOUSE4
MOUSE5

For the first example, we'll use CapsLock.

Suppose the mouse wheel normally sends two positional team calls:

Code:

MWHEELUP -> HIGH
MWHEELDOWN -> LOW

While CapsLock is held, we want the same wheel directions to send:

Code:

CAPSLOCK + MWHEELUP -> LEFT
CAPSLOCK + MWHEELDOWN -> RIGHT

First create separate aliases for the normal and alternative actions:

Code:

alias mod_wheelup_normal "say_team ^7HIGH"
alias mod_wheelup_alt "say_team ^7LEFT"

alias mod_wheeldown_normal "say_team ^7LOW"
alias mod_wheeldown_alt "say_team ^7RIGHT"

Next, create variables that point to the currently active aliases:

Code:

set mod_wheelup "mod_wheelup_normal"
set mod_wheeldown "mod_wheeldown_normal"

The wheel itself is then bound through `vstr`:

Code:

bind MWHEELUP "vstr mod_wheelup"
bind MWHEELDOWN "vstr mod_wheeldown"

Normally, those variables point to the `_normal` aliases. The modifier only needs to switch them to `_alt` while CapsLock is held and restore them on release:

Code:

alias +modifier "set mod_wheelup mod_wheelup_alt; set mod_wheeldown mod_wheeldown_alt"

alias -modifier "set mod_wheelup mod_wheelup_normal; set mod_wheeldown mod_wheeldown_normal"

bind CAPSLOCK "+modifier"

The result is:

Normal

Code:

WheelUp -> HIGH
WheelDown -> LOW

CapsLock held

Code:

WheelUp -> LEFT
WheelDown -> RIGHT

The reason this works is Quake's existing press/release command system. Commands such as `+attack`, `+forward` and `+zoom` have corresponding `-attack`, `-forward` and `-zoom` actions when their key is released.

Custom aliases can use the same behavior. With:

Code:

bind CAPSLOCK "+modifier"

Quake executes:

Code:

CapsLock pressed -> +modifier
CapsLock released -> -modifier

So this is not a toggle that has to be enabled and disabled manually. The alternative layer exists only while the modifier is physically held.

Adding more keys to the second layer

The same modifier can control many keys at once. Each key stays bound to its own `vstr` variable, while `+modifier` and `-modifier` decide which version that variable points to.

For example, Q could normally select a weapon:

Code:

alias mod_q_normal "weapon 5"

but send a team message with the modifier:

Code:

alias mod_q_alt "say_team ^7RUSH ROCKET"

The complete Q setup is:

Code:

alias mod_q_normal "weapon 5"
alias mod_q_alt "say_team ^7RUSH ROCKET"

set mod_q "mod_q_normal"

bind q "vstr mod_q"

Then add Q to the two modifier aliases:

Code:

alias +modifier "set mod_wheelup mod_wheelup_alt; set mod_wheeldown mod_wheeldown_alt; set mod_q mod_q_alt"

alias -modifier "set mod_wheelup mod_wheelup_normal; set mod_wheeldown mod_wheeldown_normal; set mod_q mod_q_normal"

Now the same physical key has two functions:

Code:

Q -> weapon 5
CapsLock + Q -> RUSH ROCKET

The pattern works equally well with letters, number keys, the wheel and mouse buttons. A larger second layer might look like this:

Normal layer

Code:

1 -> weapon
2 -> weapon
3 -> weapon

Q -> weapon
E -> weapon
R -> weapon

WheelUp -> normal action
WheelDown -> normal action

Modifier layer

Code:

Mod + 1 -> QUAD
Mod + 2 -> BATTLE SUIT
Mod + 3 -> SAFE

Mod + Q -> LEFT
Mod + E -> RIGHT
Mod + R -> HELP

Mod + WheelUp -> ENEMY HIGH
Mod + WheelDown -> ENEMY LOW

There is no requirement for both layers to be related. A weapon key can become a team call; a mouse button can become `dropweapon`; a number key can send powerup information. The useful part is that secondary actions remain on keys already within easy reach instead of being scattered across F-keys or the navigation cluster.

For any ordinary one-shot bind, the reusable template is:

Code:

alias mod_KEY_normal "NORMAL COMMAND"
alias mod_KEY_alt "ALTERNATIVE COMMAND"

set mod_KEY "mod_KEY_normal"

bind KEY "vstr mod_KEY"

Add:

Code:

set mod_KEY mod_KEY_alt

to `+modifier`, and:

Code:

set mod_KEY mod_KEY_normal

to `-modifier`.

Once the first few keys are configured, expanding the layer is mostly a matter of repeating this pattern.

Why WinKey works well as a modifier

CapsLock is convenient because Quake Live can bind it directly, but WinKey is arguably a better physical modifier on many keyboards.

The left Windows key usually sits between Ctrl and Alt. It can be held with the left thumb while the other fingers stay around the normal movement and weapon area. That makes combinations such as these relatively comfortable:

Code:

Win + 1
Win + 2
Win + 3

Win + Q
Win + E
Win + R

Win + WheelUp
Win + WheelDown

It is particularly useful when the second layer includes mouse controls. The left thumb holds WinKey, while the right hand remains completely free to use WheelUp, WheelDown, Mouse4 or Mouse5.

There is also no real opportunity cost for many players. Making CapsLock your modifier means CapsLock can no longer be used as a normal Quake bind. The same applies to Mouse4 or Mouse5. WinKey, on the other hand, is usually doing nothing useful inside the game, so it can provide an additional layer without taking away a valuable gameplay key.

The problem is that WinKey is not an ordinary Quake key – it is also handled by Windows. Pressing it may open the Start menu, and simply disabling the Windows-key behavior does not necessarily make it a reliable bindable modifier inside Quake Live.

You may also see configs containing something like:

Code:

bind 0x00 "+modifier"

Do not treat `0x00` as a universal Quake name for WinKey. Raw hexadecimal key identifiers may appear for inputs the game does not identify normally, and the physical key associated with a particular value can depend on the keyboard and input setup. A raw bind copied from somebody else's cfg is therefore not a reliable WinKey solution.

Using WinKey with AutoHotkey

A cleaner approach is to let AutoHotkey v2 translate the physical WinKey into an ordinary unused key that Quake Live already understands.

Before doing this, make sure Quake Live itself is not disabling the Windows key. Your cfg must contain:

Code:

winkey_disable 0

This is required for the WinKey setup to work correctly. If `winkey_disable` is set to `1`, Quake Live disables the Windows key and it cannot be used as the physical modifier for this setup.

AutoHotkey can then translate WinKey into any unused key recognized by Quake Live. For example:

Code:

Left Win -> HOME -> Quake Live

Quake then only needs:

Code:

bind HOME "+modifier"

All actual alternative actions remain in the Quake cfg. AutoHotkey does not need separate rules for Win+Q, Win+1, Win+WheelUp or any other combination.

Create a file such as:

Code:

quake_winkey.ahk

and use:

Code:

#Requires AutoHotkey v2.0
#SingleInstance Force

#HotIf WinActive("ahk_exe quakelive_steam.exe")

*LWin::SendEvent "{Home down}"
*LWin Up::SendEvent "{Home up}"

#HotIf

The script only performs this conversion:

Code:

Left Win pressed -> HOME pressed
Left Win released -> HOME released

The complete chain is therefore:

Code:

WinKey down
-> AutoHotkey sends HOME down
-> Quake executes +modifier
-> alternative bind layer active

WinKey up
-> AutoHotkey sends HOME up
-> Quake executes -modifier
-> normal bind layer restored

HOME is only an example. The intermediary key itself is irrelevant as long as Quake recognizes it and it is not already used in your cfg. Other possibilities include:

Code:

INS
PGUP
PGDN
PAUSE

For example, to use Pause instead:

Code:

*LWin::SendEvent "{Pause down}"
*LWin Up::SendEvent "{Pause up}"

and in Quake:

Code:

bind PAUSE "+modifier"

Nothing else in the modifier setup has to change.

Why not put every WinKey combination into AutoHotkey?

You could define separate AutoHotkey actions for:

Code:

Win + Q
Win + E
Win + 1
Win + 2
Win + WheelUp
Win + WheelDown

but then the gameplay configuration would be split between two places. Some binds would live in the Quake cfg, while others would live in the `.ahk` file.

Keeping AutoHotkey limited to one translation makes the setup easier to edit, troubleshoot and share:

AutoHotkey	WinKey -> one unused Quake Live key
Quake Live cfg	Normal binds, alternative binds, +modifier and -modifier

If you use CapsLock, Home, Pause or another normal Quake key as the physical modifier, AutoHotkey is not needed at all.

Limitations and cfg placement

The simple `vstr` method is best suited to one-shot commands – actions that execute when the key is pressed and do not remain active until release.

Typical examples include:

Code:

weapon
say
say_team
dropweapon
droppowerup

Held commands require more care:

Code:

+forward
+back
+moveleft
+moveright
+attack
+zoom
+speed

Those commands have separate press and release states. If a key activates one command and the modifier changes its `vstr` value before that key is released, the release state may no longer correspond to the command that was originally pressed.

For weapons, messages, drops and similar one-shot actions, the simple system above is sufficient. Movement, attack and other held actions should not be moved into the same template without accounting for their release behavior.

❗ There is one more common cfg issue to check. If your config contains:

Code:

unaliasall

the modifier aliases must be defined after it. Otherwise `unaliasall` will remove aliases that were created earlier in the cfg.

A typical order is:

Code:

// settings
// regular binds

unaliasall

// normal and alternative aliases
// modifier variables
// +modifier
// -modifier

bind CAPSLOCK "+modifier"

When using WinKey through AutoHotkey, make sure `winkey_disable` is also set to `0` and bind the intermediary key instead:

Code:

// settings
// regular binds

winkey_disable 0

unaliasall

// normal and alternative aliases
// modifier variables
// +modifier
// -modifier

bind HOME "+modifier"