LazyGripHow GRIP-EMS works
Before you build a sequence, you need the right mental model. Three things in particular will save you hours of confusion: understanding what WoW's secure execution environment actually restricts, understanding exactly how GRIP-EMS advances through steps compared to other rotation addons, and understanding how hold-on-failure behavior changes the way you write individual steps.
The secure execution environment
WoW runs addon code that interacts with combat in a restricted sandbox called the secure execution environment. Blizzard built this to prevent addons from automating decisions. Things like casting a spell when health is below 40% or using a cooldown when the boss is casting a specific ability are blocked because they would read arbitrary game state to make combat decisions. Inside a macro or sequence step, a meaningful portion of the Lua API is simply not available.
This catches many new users who come from programming backgrounds and assume they can write logic into their sequences. The most common example is trying to check a resource value like combo points or holy power with UnitPower("player") or timing logic with GetTime(). Both of those calls return nil inside a secure handler because they are part of the restricted API. The sequence does not error gracefully, it crashes.
What you can use inside sequence steps is the standard macro conditional system that Blizzard has explicitly allowed: [combat], [mod:shift], [known:SpellName], [noform:1], [nochanneling], and the rest of the documented macro conditional set. These are not API calls. They are tokens the macro engine parses directly and they are permitted because they do not read arbitrary game state.
GRIP-EMS's Variables system exists partly to work around this limitation. Variables are resolved outside the secure environment before the macro compiles, which means you can use them to make conditional decisions that would be impossible inside a step directly.
How the step engine actually advances
GRIP-EMS is a Sequential step engine by default, which means it fires step 1, then step 2, then step 3, advancing one step per keypress and looping back to step 1 after the last step. The important detail is in what happens when a step fails to cast.
| GRIP-EMS | GSE | |
|---|---|---|
| Failed cast | Holds on the current step. The sequence does not advance until the cast succeeds. Step 3 stays at step 3 until the spell actually fires. | Skips the failed step and advances to the next one. The sequence keeps moving regardless of whether the spell landed. |
For tank rotations this difference is significant. Ironfur uptime, Thrash frequency, and cooldown timing all depend on spells landing in the right order. When the engine skips, high-value spells get pushed back by failed steps accumulating ahead of them. When the engine holds, your uptime numbers are consistent pull to pull.
Hold behavior and proc-gated abilities
Hold-on-failure is not just a defensive measure against lag. It is the mechanism that lets you write cleaner sequences for proc-dependent abilities without any conditional logic at all.
The classic example is any ability that upgrades on proc. Warrior's Slam becomes Heroic Strike when the Sudden Death proc is active. In GSE, writing /cast Heroic Strike in a step means the sequence skips that step and fires Slam as the fallback when the proc is absent, because GSE advances past failed casts. In GRIP-EMS, the same line holds on that step when the proc is absent and does not fire Slam at all. The sequence waits there until Heroic Strike is actually available, then fires and advances. You get the proc version every time and never waste resources on the base version.
The rule that follows from this: bare /cast SpellName with no conditionals is the correct pattern for proc-dependent abilities. Adding [combat] or other guards changes the behavior because WoW then resolves a fallback when the guard's condition fails, which bypasses the hold. If the spell should only fire when its proc is active, write it bare and let GRIP-EMS hold.
The one exception is [nochanneling], which is the correct guard for finisher steps like Rip or Final Verdict. That conditional is needed to prevent the finisher from clipping a channel. Do not add [combat] on top of it, that causes silent failures.
Step functions
GRIP-EMS supports four step functions that control how the engine decides which step fires next. Sequential is the default and the one you will use for most rotations.
Fires step 1, then 2, then 3, loops to 1. One advance per keypress. This is the correct choice for rotations where order matters, including tank defensive cycling, opener sequences, and anything where a spell at step 5 is supposed to come after the spells at steps 1 through 4.
On every keypress, starts from step 1 and fires the first step that succeeds. Never advances past a step that can cast. Good for DPS rotations where you always want your highest priority spell to fire when it is available, regardless of where you are in the loop.
Starts from the last step and works backwards. In practice this means your lowest priority step fires almost every press because it is the last one checked and usually the easiest to satisfy. Avoid for finisher steps in any resource-based rotation.
Fires a random step each press. Useful for very specific situations like randomizing a proc-based spell into different positions to avoid predictable timing. Not useful for structured rotations.
The Pause step
GRIP-EMS includes a dedicated Pause step that holds the sequence without attempting a cast. It has three variants and they behave differently depending on what you need.
The Pause step is most commonly needed for specs with strict GCD relationships between abilities, for example preventing Steady Shot from firing too close to a proc window in Marksmanship Hunter. If you find a spell clipping something it should not, a one-GCD pause before that step is usually the fix to try first.
Reset conditions
Reset conditions send the sequence back to step 1. GRIP-EMS supports five of them and they can be combined.
Skyriding and mount behavior
As of v2.1.16, pressing your sequence keybind while skyriding behaves differently depending on whether you have a valid target.
This requires Auto Dismount in Flight to be enabled in your WoW settings. Druids also need Auto Unshift enabled to exit skyriding Travel Form mid-air with the same single press.
Getting dazed off a skyriding mount mid-pull used to leave your sequence keys dead until you dropped combat. That is fixed as of v2.1.18. The swap to your ground action bar now happens the moment you land, combat-safe, so your keys are ready the instant you hit the ground.
There was a separate bug on first takeoff of a session where ground binds stayed live mid-air or vehicle keys never woke up at all. Fixed in v2.1.20. The out-of-combat watchdog now heals the swap at takeoff and restores it on landing, so the first flight of every session behaves the same as every other.
Keybind recovery
GRIP-EMS added automatic keybind monitoring in v2.1.18. If your sequence keybinds go missing after a login, a loadout swap, or a deleted loadout eating its own binds, the addon now detects it and tells you. Running /gems binds restore puts your last working set back immediately.
The addon snapshots your binds on every clean load, so recovery is reliable even across sessions. If you see a warning about missing binds, run the restore command before assuming something is broken in your sequence.
/gems binds restore first. It takes two seconds and covers the most common cause of unexplained dead keys.Per-step Disable and the sequence tracker
Individual steps can be disabled inside the editor without deleting them. A disabled step is skipped entirely by the engine, which means you can comment out a step for testing purposes without losing the macro text. Re-enable it and the engine picks it up again on the next keypress.
Disabled sequences are hidden from the tracker overlay and from your action bar as of v2.1.14. A sequence that is toggled off does not occupy a visible tracker slot, which keeps the display clean when you have multiple sequences loaded but only some of them active.
The visual display layer versus what actually executes
This is worth knowing because it causes real confusion in the Discord regularly. GRIP-EMS has two separate things: the visual preview of your sequence in the editor, and the compiled macro output that actually runs when you press your keybind. They are not the same thing.
The visual layer renders steps it can match against known spells in its database. Steps it cannot match, including certain raw macro lines, some conditional constructs, and hero talent override spells under specific conditions, do not show in the preview. But they still exist in the compiled output and WoW's macro engine executes them correctly. A step that is invisible in the editor is not a broken step.
This passthrough behavior is intentional and is how GRIP-EMS supports custom macro syntax that the addon's parser does not explicitly recognize. If you see fewer steps in the preview than you built and your sequence is otherwise working, this is almost certainly why.