Building sequences

This sequence runs 30 steps in a Sequential loop with resetOnCombat enabled, meaning it fires the opener every pull and loops through the rotation continuously from there. At 150ms intervals on Razer hardware this produces Thrash at roughly 47% of total damage done, Ironfur uptime in the 91 to 97% range, and zero deaths across the validated keys.

Two modifiers run throughout the entire sequence. Shift fires Frenzied Regeneration on demand without breaking the loop. Ctrl fires Ironfur manually when you need it outside the automatic cycling. Every step except the two MOONSPAM steps and steps 15 and 30 carries both modifier lines so they are always available regardless of where you are in the rotation.

The sequence has a clear internal structure once you see it: an opener block, then a repeating loop built around Thrash and Mangle with Ironfur cycling at fixed intervals, Lunar Beam weaved at positions 5, 12, 19, and 26, and MOONSPAM at positions 8 and 22 handling Moonfire delivery and Barkskin as a reset gate.

GRIP-EMS has a KeyPress field that fires on every single keypress regardless of where the sequence is in its step list. It is not a step in the rotation. It is a persistent header that runs before every step fires.

Modifier handling belongs here and only here. If you put [mod:shift] lines inside individual steps instead of in KeyPress, every step has to carry that conditional which eats into the 255-character step limit and reduces CPM across all abilities. Putting modifiers in KeyPress means a single line handles the modifier for every press and your steps stay clean.

There is a meaningful secondary benefit. When modifiers live in KeyPress, the Rotation Preview panel in the GRIP-EMS editor can display your actual spell names instead of showing only the raw conditional text. If your sequence preview shows /cast [mod:shift] instead of the spell name, the modifier is in the steps rather than in KeyPress.

Some abilities should fire once on each new target rather than on a timer or as a rotation step. Hunter's Mark is the canonical example. You want it to apply when you engage a target, reapply when you switch targets, and not spam continuously on every keypress.

The correct pattern for this in GRIP-EMS is a castsequence with a target reset, placed in a step near the top of the loop:

This fires Hunter's Mark on the first press after you acquire a target, then advances the castsequence to null, which is a no-op. The sequence stays on null for every subsequent press against that target, so Hunter's Mark does not repeat. When you switch targets the castsequence resets to Hunter's Mark and fires again on the first press.

The [exists] conditional prevents the line from attempting to fire when you have no target. The [nochanneling] prevents it from interrupting a channel. Both guards are necessary for the pattern to work cleanly in M+ where target switching is frequent.

The same pattern works for any ability you want to fire once per target: Faerie Fire, Misdirection to a specific target, any debuff that should land on engage and reapply on target change. Swap Hunter's Mark for the ability name and the behavior is identical.

Everything in this guide so far writes conditional logic directly into macro text, using bracket conditionals like [mod:shift] and [nomod:shift, nomod:ctrl, combat] right inside each step. That is a deliberate choice. It keeps you in full control of exactly what compiles and exactly how many of your 255 characters it costs, and it is the pattern the Elune's Chosen example above uses throughout. But it is not the only way GRIP-EMS lets you build conditional logic, and for some patterns it is not the right tool.

Beyond the flat step list, GRIP-EMS has a hierarchical action tree with a visual node editor. Five node types are available: Action, which is a single macro step and the leaf of the tree; Loop, which repeats its children a set number of times or indefinitely; Repeat, which runs its children N times and then moves on; Conditional, which evaluates a Lua condition before running its children; and If, ElseIf, and Else, which give you proper branching with multiple condition paths instead of chaining bracket conditionals by hand.

An If node compiles a True branch and a False branch into a single chunk of macro conditional text, the same kind of output you have been reading throughout this page, except the editor builds it for you from whatever you put in each branch. If your True branch is empty, the compiler does not emit a clumsy empty-clause-with-semicolon-fallthrough. It automatically applies De Morgan negation and emits the shorter negated form instead, the same way [noindoors] reads cleaner than an empty bracket followed by a semicolon. A path indicator badge next to the Cond box tells you which compile path the node took, Single line, Two-line split, Per-step, or Optimised fall-through, and the Compiled Output preview pane shows you the literal macrotext the engine will actually run. That preview is the real value here: it lets you verify exactly what is going to fire before you save, which is easy to get wrong reading raw bracket syntax by eye once a branch has more than one action in it.

That last point is the actual reason to reach for the node editor instead of hand-written brackets. A single toggle, like the Shift modifier pattern used throughout the Guardian Druid sequence above, is faster to write and easier to scan as a flat inline conditional, which is why this guide teaches it that way. But once a branch needs more than one action, an opener that casts two or three different spells depending on whether you are indoors, mounted, or in a specific stance, hand-chaining semicolons gets error-prone fast and a single mistake silently breaks the branch. The visual tree keeps each branch's actions grouped and editable on their own, and the Compiled Output preview catches mistakes before they reach your action bar instead of after.

Charged spells and empower spells, Evoker's Fire Breath and Upheaval being the clearest examples, behave differently from a normal cast and that difference is what causes automated sequences to hitch, freeze, or feel wrong even when every step looks correct on paper.

A normal spell either casts or it does not. A charged or empower spell has stages: holding the button charges it up, and releasing early locks in whatever charge level you have reached so far. Mechanically each charge level is treated as a different spell, and moving between them stops the previous cast rather than smoothly continuing it. When that stop happens automatically instead of on your own release, it costs a hitch, roughly a full GCD of dead time, before anything can be cast again. This is not a bug in GRIP-EMS. It is the same behavior press and hold casting has always had with charged spells, and automating the press does not remove it.

Two approaches have actually worked for players sequencing these spells, and one approach that sounds reasonable does not.

None of this is Evoker specific in principle, it applies to any spell WoW treats as charged or empowered, but Evoker is currently the class where it comes up. If you are building a sequence around Aug Evoker's Ebon Might upkeep or a Devastation opener that leans on Fire Breath or Upheaval, plan for one of the two working approaches above rather than assuming a normal cast-step pattern will behave the same way it does for every other ability in your kit.