GRIP-EMS v2.4.21

On a version like that, those lines are all the key runs, and until you reloaded the key kept running the old ones. Pinning a version or entering a context did the same when both versions had no steps. An action tree with nothing left to cast, such as one that only embeds a sequence you deleted, counts as having no steps. An edit made in combat lands when combat ends.

You can name a sequence My Rotation in the editor, but those four commands read the name only as far as the first space, so they went looking for a sequence called My and told you it did not exist. They read the whole name now. If you have both My and My Rotation, the longer one wins and My is still reachable on its own. Sending to another player was the worst of the four, because the error named a sequence you had not typed. Names without spaces behave exactly as they did before, and nothing about the way names are stored has changed.

Entering a dungeon reloads the sequences whose context override names another version. If one of those reloads stopped with an error, every sequence due after it kept casting its old version until you reloaded. Each one reloads on its own now, and with debug output turned on EMS names the sequence that failed. One way to hit it was an If block holding an Embed of a sequence with a damaged step, which only an import or another addon can store. The sequence holding that If block also failed to load. The damaged step is now left out of the Embed, and the embedded sequence's other steps play as before. A step stored as a list of lines is not left out: the Embed casts its lines.

An import string can carry an author, a class, a description or a fork history in the wrong form, and EMS stored it exactly as it came. Selecting that sequence could stop the editor part way, a sequence list sorted by class could fail to draw, and sharing the sequence privately could stop with an error. EMS now keeps each of those details only when it has the right form, and puts right the ones already saved when you log in. If a sequence you imported was signed by an author who had saved its class, spec, icon, description, link or talent code in the wrong form, it now shows as Tampered, because the signature covers the form they saved. Sequences you wrote yourself are signed again instead.

EMS looked at only the first 18 of your 30 character macro slots, so a macro in the rest was missing from the export list and never went with the sequence.

With that setting on, a change to the macro reached the step and what it cast, but exporting or sending the sequence still carried the macro's old text, and whoever imported it saw your own sequence marked Tampered. The refresh now saves the sequence the way the editor's Save does, so an export or a send carries the new text and doesn't import as Tampered.

In v2.4.20, /gems export, Export in the sequence list and the editor, a send and the export window left out a tagged macro with no slot, and nothing said so. EMS keeps a copy of each macro it makes for an import, and a macro step holds its macro's text. An export now takes the macro from your macro list, then from EMS's copy, then from a macro step of the sequence or of another sequence that uses the macro, the sequences being exported first. A sequence its author marked do-not-share gives none of its text. A macro none of them has is named in chat when you make an export string or send. The export window lists these macros too, and its warning line names one it can't find. Copy as Text prints them as well.

In v2.4.20 the import window's rename made the imported macro under a new name, but the list kept the old one, so the sequence's next export took your macro of that name and not the renamed one.

A legacy step can name a macro by its name alone. In v2.4.20 a step like that kept the name, which a press sends to chat, or took the text of a macro of your own with the same name. The import window also said the macro wasn't in the import, though the import made it. The step now gets the text of the macro the string carries, as /gems import already did. If you have a macro of your own with that name and the import leaves yours alone, the step still gets the string's text, and the step editor shows it out of sync with your macro. If you untick the macro, the step gets its text too, and the import names the macro as one it didn't make.

EMS gave steps like these their macro's text once before, at the first login after v2.1.23, and a character that had done that never did it again. Every character now does it once more. A step, Key Press or Key Release that names a macro by its name alone gets the text of the macro EMS made for it or, if there isn't one, of your own macro with that name.

In v2.4.20 the rename made the macro under its new name, but a step that named it took the text of your own macro of the old name, and a /click line or a Key Press or Key Release line that named it kept the old name. They now name the new one. A /cast line keeps the name, so a macro named like a spell doesn't stop that spell's casts.

In v2.4.20 they kept the old name, so they embedded your own sequence of that name. A sequence's list of the sequences it uses follows the rename too.

A rename gave the import its name with (2) after it whether or not you had a sequence of that name, so renaming A while you had both A and A (2) wrote the import over your A (2). It now counts up to a name no sequence of yours and no other sequence in the import uses, and the import window's row shows that name.

The rename moved every whole word that matched the macro's name, so with a macro named like a spell, such as Charge renamed to Charge (2), each /cast Charge in the steps became /cast Charge (2) and cast nothing. Now a line moves only where it runs the macro: a line that is the macro's name alone, or the name after /click, in a step, the Key Press or the Key Release. Steps in an action sequence kept the old name, so they clicked your own macro of that name, and they now move the same way.

After /gems import of a collection string that carried a macro, the next import's preview, and its Compare window, read that string's text for a step naming a macro of the same name by its name alone. Each import now forgets the macros it carried once it has finished, so the next preview reads your own macro.

In v2.4.20 the tab listed only the macros in your macro list, so a macro you deleted in /macro stayed ticked where you couldn't see it, and every save and export kept it. It now shows after your macros, marked not in /macro, and you can untick it. An unticked one keeps its row until you save or open another sequence, so you can tick it again.

Exporting or sending one before its first save said an unknown author had written it, not you, and asked whether to share it anyway. A sequence made with New also didn't stay yours if you reloaded or logged out before that save. The next login marked it as imported, so EMS asked you to confirm before sharing your own sequence and never signed it. EMS now signs it as yours when you make it. Since it's yours from the start, the editor no longer shows the author picker for it, so you can't pick an alt's name or a pseudonym for it before its first save. It takes your pseudonym if your Default privacy mode for new sequences is Pseudonymous and you've set one, and your character's name otherwise. Its first save now adds an "edited" entry to its history, so after one save someone who imports it sees Modified where v2.4.20 showed Verified.

It turned amber at 14, less than half of what a character can hold.

It didn't redraw its macro line, slot number and macro count on its own, so they stayed as they were until you pressed Refresh or left the tab and came back.

EMS could take a character macro that clicked a sequence's button with /click for that sequence's own macro, even one you wrote to cast something first. When yours came before the sequence's macro in the game's macro window, each login replaced your macro's text with the sequence's, and deleting, renaming or disabling the sequence deleted yours and kept EMS's. Clean Orphans in the Macros tab deleted it the same way once the sequence was gone. When the sequence had no macro of its own, EMS used yours at login and made none. An import that brought a macro with the same name as yours wrote over it, and the import preview didn't offer to rename it. EMS now counts a macro as a sequence's only when EMS named it, with a name starting GEMS:, and leaves yours alone.

An imported step can hold a colour code written with a single |. Clicking into that step's box in the Steps tab or the Source tab cut the code's |r, so its colour ran on to the end of the box, and took a code in lower case out whole. A Tab completion in the Steps tab did the same. The first key you typed next put the cut step into the editor, and Save kept it. Applying the Source tab cut it too. The preview's Copy button took every colour code out of the steps it copied, and left a code you had typed as stray | characters. EMS now keeps each colour code as the step holds it.

Not imported lists what an import leaves out and why, such as a sequence it refuses, or an Embed of a sequence it can't find and a Loop with nothing in it. The preview put its notes on what it brings in there too: that a sequence's author marked it do-not-share, that its steps hold raw macro commands, and how a sequence from another sequencer was converted, such as a Loop whose count was capped at 50. They now sit under Import notes, and a sequence you leave unticked keeps its notes there, its do-not-share mark among them.

Holding a modifier you had set to send a sequence back to step 1 did nothing at all: the press cast nothing and the step did not move. A reset timer never fired either, though those presses cast normally. Both went through a button attribute the game refuses to let a sequence read or write. That attribute has a name the game accepts now, and the gap is measured before the press instead of after it, so coming back after a long pause puts you on step 1 on the very first press. A pause that ends while you are in combat is held until the fight is over, so your next press after that starts from step 1 wherever it happens, and it is dropped if you go back to pressing during the fight, because at that point you have not paused. Every other kind of reset was unaffected throughout: leaving combat, changing target, swapping gear, changing specialisation, and the manual reset.

Each variant could keep the old setting until you reloaded. With Hold While Channeling turned off, a variant press during a channel still held the sequence in place. The reset modifiers had the same problem, whether you changed them on the sequence or in the settings panel.

The variants could stay as the old version had them until you reloaded. Holding a modifier could still cast the old version's variant steps, and a variant only the new version has was missing.

Switching to a version with no steps left the sequence casting the old version's steps until you reloaded. The other way round, from an empty version to one with steps, the keybind did nothing until you reloaded. A version with fewer steps could cast one of the old version's steps on the next press and then skip step 1. These switches now rebuild the sequence and start it at step 1, as a reload does, and so does any switch to a version with a different number of steps or a different Step Function. Switching between two versions with the same number of steps and the same Step Function keeps your place, as before. After either button a context override could also be ignored, so entering a dungeon whose override named another version kept the sequence where it was until you reloaded. That override takes effect now.

Priority and Reverse Priority repeat your steps, so they have more of them to walk through than Sequential does. If you had pressed far enough into the sequence, the switch left it past its new last step. The next press then cast the same step as the press before it, and the sequence could go on to skip its first steps. It now goes back to step 1 when that happens, and so do its variants. A sequence still on one of its steps stays where it is.

A pin or a context override onto a version with no steps, or clearing a pin when the default version has no steps, left the sequence casting the old version's steps until you reloaded. The other way round, from an empty version to one with steps, the keybind did nothing until you reloaded. Switching away from a damaged default version onto one without variants did the same, and so did Set Default. Pinning or switching context between a Random version and a version with any other Step Function kept the old version's behaviour, so the Random version walked its steps in order or the other version picked them at random. These switches now rebuild the sequence the way a reload does. One kind of damaged Step Function setting, which only an import or another addon can store, made a pin or a context switch onto that version stop with an error and keep the old steps. It now plays the version in order. /gems reset typed in combat before a switch that rebuilds the sequence now resets the rebuilt button. It used to leave the macro icon showing the old version's first step until your next press.

The game will not load a sequence step that contains a curly brace, and a raid marker such as {rt8} in a /yell line is written with two, so a version holding one cannot run. Pinning that version, entering a context that uses it, clearing a pin back to it, Set Default and Delete Version all left the sequence casting the old version. After Set Default or Delete Version, a modifier variant whose new steps hold a marker also kept its old steps. The sequence now behaves as it does after a reload, and its keybind casts nothing for that version until the marker is taken out. Saving an edit that adds a marker to a step used to keep casting the step as it was before the edit. It now casts nothing as well.

Editing the embedded sequence left the one embedding it casting the old steps until something rebuilt it. Logging in could drop the embedded steps altogether. Whether it did came down to the order the game handed your sequences back, and the shortened copy was then saved over yours. A sequence that embeds itself grew by one copy of its own steps every time it was rebuilt, and a save was enough to do that. Two sequences that embed each other grew the same way. Now every sequence that embeds another is rebuilt when that one's steps change, and starts again from step 1. An edit that leaves the steps as they were, such as a Key Press change, doesn't send it back to step 1. An embed that leads back to the sequence it sits in adds nothing, and the rest of that sequence plays as normal.

An import or another addon can store a version that isn't a real version at all. Pinning one, entering a context set to one, or clearing a pin when the default is one left the sequence casting the version it was on, from the step it had reached. The editor already showed the new version as live. After a reload that keybind casts nothing, and the switch now does the same. Modifier variants from the old version are removed too. A version stored past the end of the version list, such as version 7 on a sequence with two, was skipped as well. Clearing a pin onto it or entering a context set to it kept the old version casting. It now switches to that version and starts at step 1, as a reload does.

Saving one from the editor, the popup editor or the raw tab threw the save away. The sequence kept its old steps, and those are what stayed in your saved sequences. Quick changes such as the reset timer did stick, which is why this was easy to miss. A sequence for another class, which EMS keeps loaded but not active, lost a save made in combat the same way. Both keep the save now, and a disabled sequence stays disabled when you save it.

Pressing a Shift variant means you're holding Shift, so with Any Shift or Any Modifier set as a reset modifier, every press of that variant cast nothing, and with Left Shift or Right Shift set, every press made with that Shift key did. Ctrl and Alt variants had the same problem. A variant now doesn't count the reset modifiers its own key holds down, and every other reset modifier still sends it back to step 1. Turning on a reset modifier that a variant ignores now says so in chat.

With Left Click set to reset a sequence, every press of its keybind cast nothing, because EMS passed each keybind press on as a left click. A keybind press no longer counts as a click, so the sequence plays through its steps. Clicking the sequence's macro with the left mouse button still sends it back to step 1. The default action bars pass a key press on to a macro as a left click, so a macro you press through its action bar key still goes back to step 1 on every press. Turning Left Click on now says so in chat.

A Shift variant on a key with Ctrl or Alt in it, such as Ctrl+4, never fired, and neither did a Ctrl variant on a key with Alt in it. EMS bound them under a name the game never matches. They're bound the way the game names the key now. A variant whose modifier is already part of the key, such as a Ctrl variant on Ctrl+4, would be the same key twice, so it isn't bound and the key keeps playing the sequence. A key typed into /gems bind with its modifiers in another order, such as shift-ctrl-4, never fired either, and it works now unless another sequence is already bound to that key. Keys without a modifier are bound exactly as before. If a sequence's own key holds a modifier you have set to reset that sequence, every press starts it again at step 1, and EMS now says so in chat.

If a stored version's reset modifiers had been damaged, changing a reset modifier in the settings panel, or switching profile, stopped with an error at that sequence, and the change didn't reach the sequences after it. Switching to that version, by pin or by context, stopped the same way and left the sequence casting the old version's steps. Both now fall back to the global reset modifiers for that version. Saving, renaming or duplicating the sequence, or duplicating that version, also stopped with an error. Opening that version in the editor could stop part way through, or show a per-sequence setting with every modifier off. The editor now shows the global reset modifiers for it, which is what that version uses, and saving the sequence clears the damaged setting. The Repair panel lists it too, with a fix that clears it.

A branch like that runs while you hold the modifier the game's options give that action. The panel didn't read it, so a key taken by something else still showed as clear. When one was combined with another modifier, as in [mod:SELFCAST,mod:ctrl], the panel checked the wrong key. A variant's own key, such as Shift+F3 for a Shift variant on F3, wasn't checked unless the sequence's own macro lines also branched on Shift.

Only plain steps took the new name. Steps in an action sequence and in modifier variants kept the old name, which no longer existed, so that part of those steps came out empty. Your other characters' sequences, and copies you staged for them, take the new name the next time you log in on each of them. An editor open on a sequence now shows the new name at once, and EMS asks you to save or discard unsaved changes in an editor before it renames a variable, since saving them afterwards would put the old name back.

A sequence called Fury v2 and the first modifier variant of a sequence called Fury had the same button name, so whichever loaded second took the other's place, and holding the modifier on Fury's key could play Fury v2. Now the sequence keeps its button, and chat says the variant has none. Two saved sequences whose names differ only in characters a button name leaves out, such as Fury and Fury!, shared a button the same way. At login the one EMS loaded last took it, and the game doesn't hand your saved sequences back in the same order every time, so which one ran could change after a /reload. Now the one whose name sorts first keeps the button at every login, and chat says the other doesn't run. If that one is disabled, made for another class or damaged, the other one runs instead. EMS also refuses a name that would share a button when you make, rename, fork or import a sequence. A sequence saved earlier under a name EMS uses for itself, such as OOCEvent, switched that part of EMS off; it now stays in your list without running until you rename it.

The Variables tab said it wasn't used, and deleting it didn't say a sequence uses it. Exporting or sending the sequence left the variable out, and when a sequence did bring it along, the import preview left it unticked, so it wasn't imported unless you ticked it. Repair didn't report it missing. A change to its value didn't reach the variant until the sequence was next rebuilt.

Tab, Shift-Tab, Page Up, Page Down and the number keys 1 to 9 moved no keyboard cursor there, so no setting on those pages could be reached from the keyboard. Tab and Shift-Tab now step through a page's settings in order. On the Accessibility and CVar Health pages the number keys, Page Up and Page Down jump between sections. On EMS's other pages those keys have nothing to jump between. They did nothing while one of those pages was open, and they now go to the game there, such as to your action bars. Space ticks a checkbox, opens a menu, puts you in a text box or presses a button. In the theme editor, Space on the Preset menu, a saved theme's Name box or the Import and Export boxes did nothing, and it now opens the menu or puts you in the box.

With some CVars pinned or combat-locked, it still said each row has Undo, and it said so even when none was reset at all. With none reset it now says no CVar was reset and leaves Undo out. Otherwise it says a CVar it changed has Undo in its row.

On the CVar Health page in the game's Options window, the list of sections had no height, so none of them could be seen or opened. In the theme editor the list of elements had no height either, and Import / Export, Reset All and Copy to All Profiles sat below the bottom of the window. The page's own settings now sit under Overview, the first entry in its list, and the list takes the page's height. The Manage Profiles page puts its own settings under Overview the same way. The theme editor shows its own settings on an Overview tab and the elements on a Customise tab, as the Per-Element Theming tab in EMS's options does.

If something had asked a sequence to rebuild its steps earlier in the same fight, such as a change to one of its variables, pinning a version, clearing a pin or entering a context was undone when combat ended. The sequence went back to casting the old version's steps, and its macro kept the old version's Key Press. Set Default in the same situation, between a Random version and one with another Step Function, left the old Key Press in the macro. Both lasted until the sequence was next rebuilt, for example by a reload. The version you switched to now stays in place.

Helpers such as GRIPEMS.InCombat normally become a native conditional that the game reads as you press. Where the shape around one is not something EMS can turn into a conditional, the variable is worked out when the sequence is built instead, and that path did not know those helpers, so the variable put nothing at all into your macro. It puts its value in now. That value is settled when the sequence is built, so it holds until the sequence is built again. The six helpers the Insert Helper picker offers were never affected, because they have always been available on that path.

Emptying or breaking a recommend function, switching to a version that has none, or deleting or disabling the sequence all left the bar overlay and the tracker strip showing the last advice until you reloaded. They go back to normal at once. Switching versions or reloading does not flash them, because a sequence that comes straight back is not treated as having gone away.

Turning the variant indicators off, or dragging a different sequence onto the button, left it dark until a reload, and the variant border came back on the next keypress after the advice had gone. The overlay is drawn from the current advice every time it is redrawn. With the indicators off nothing is dimmed and no border is shown.

Steps stored the way some older imports saved them weren't read at all, and a branch that a variable adds, such as a variable whose value is [mod:shift], wasn't seen. A key taken by something else could still show as clear.

It ran the body without the limits a sequence puts on a variable, so a variable that reached past those limits showed a value in Test and came out empty in the sequence.

The first three still said they weren't available, and the Source tab's help promised a view of the generated macro text, which isn't what it shows. The Macros tab's help described Key Press lines instead of the macro stub and dependency list the tab holds. The Variants tab gets help of its own too, where the button used to show the general editor text.

In v2.4.20 the import window, /gems import and a friend's auto-accepted send read the string's sequences and variables and ignored its macros, so a sequence that used one arrived without it. The import window now lists each one, and all three make it, account-wide or for your character as the export says. A macro of your own with the same name is left alone, and the import window offers to rename the imported one. A friend's auto-accepted send now also makes the macros a legacy collection string carries, which it skipped in v2.4.20.

In v2.4.20 the report of /gems import and migrate counted sequences and variables only, and a friend's auto-accepted send printed only the names of the sequences it took. That send also prints the import's warnings now. When a sequence in an EMS string uses a macro that the import doesn't make and you don't have, the import window, /gems import and a friend's auto-accepted send now name it.

In the Variables tab, a new name typed in the Name box and saved stored the variable under that name with an empty body, events and comments, and a disabled one came back enabled. A variable made with New Variable and given its name and body in one Save lost them the same way. The Events box couldn't be saved unticked either. Save stored the events as on and ticked the box again. Save now stores what the editor holds when you press it.

With a variable selected, saving a sequence that started or stopped using it left the line as it was, whether you saved with the tab open or came back to it later, until you selected the variable again. The line now changes as soon as you save with the tab open, and the tab reads it again each time it opens.

When a talent or a form makes the game cast a different spell for a step, the Steps tab shows that spell's name. A step saved with new text, and every step of a sequence you renamed, showed the spell's own name instead until something else brought the tab up to date, such as the end of your next combat or a spec, talent or form change. After you renamed a variable, a step using it showed the spell's own name as well, and once the tab caught up, every step of the version in use that named it showed the variable's old name. The display never changed what was cast. The tab now catches up half a second after the save or the rename, or when combat ends if you're in combat.

A popup with nothing unsaved kept its own copy of the steps when the sequence changed somewhere else, such as a save in the main editor or a renamed variable. Saving the popup later put that old copy back over the change. A popup with nothing unsaved now reloads the sequence, and one with unsaved changes keeps them. It stays on the version it showed while EMS can still find it, and otherwise goes back to the default version. It keeps the step you had selected while that step is still there. Colour changes in the syntax highlighting settings also take effect at once, where they waited for a reload.

In the Variables tab, choosing Delete from another variable's right-click menu while you were editing one, then Cancel, left that other variable selected behind your editor. Save then said your variable already existed and saved nothing. If you had typed a new name, Save renamed the other variable instead and gave it an empty body, events and comments, so its own were lost, and the plain steps that used it took the new name. Confirming Delete on another variable also closed the one you were editing, and your unsaved changes to it were gone. Delete from a variable's menu now asks about that variable and leaves the one you're editing open.

The menu Tab opens in a popup editor's step box, for a spell, a variable or a sequence, opened under the main editor instead. If a step was selected in the main editor, the popup's step, completed, replaced it and marked the main editor unsaved. The popup's box showed the completed word, but the popup kept what you had typed, so saving the popup stored the unfinished word. The menu now opens under the popup's box, and a pick changes only that popup's step.

Pointing at Export Selected in the export window showed Export Selected (0) as the tooltip's title, however many sequences, variables and macros you had ticked. The title now reads the same as the button.

Going back to the list from Export Metadata or from the export string unticked everything, and Export Selected read 0. The list now comes back as you left it, with each sequence, variable and macro ticked or unticked as it was. That includes a macro you unticked yourself.

Say one sequence is on 4 with a Shift variant and another is bound to Shift+4. Both claimed Shift+4, and which one played came down to the order EMS happened to read your keybinds in, so binding an unrelated key could swap it. Shift+4 now always plays the sequence you bound to it, and that Shift variant has no key until one of the two keybinds changes. The Keybind tab tells you when the key you're setting is another sequence's variant key.

Each change of form in combat, and each loading screen you went through while still in combat, added another keybind rebuild to the list that /gems status and the minimap button count, and every one of them ran when combat ended. Each kind of rebuild now waits once, however many times it was asked for.

Only the key for your current spec and talent loadout moved to the new name. Keys saved for your other specs and loadouts stayed on the old name and did nothing, and they came back if you ever made a sequence with that name again. If the sequence was enabled, a rename made in combat lost even the current key, and chat said the sequence was not found. Every saved key now moves with the rename, straight away, and the chat line that used to confirm the one key it carried is gone.

If EMS loaded none of your saved keybinds, for example right after a login, it checked again three seconds later. When you were in combat by then, that check could not load them, so it printed the message that says your keybinds didn't load and tells you to type /gems binds restore, and then the keybinds came back after the fight. The check now waits for the load to run, and only tells you if the keybinds are still missing after it.

Setting a keybind straight after the rename said the sequence was not found, and applying an edit in the Source tab stopped with a missing-field error, until you selected the sequence again.

They shipped in v2.1.8. With Per-loadout keybinds off, which is the default, the tab now says new keybinds save per spec and where to turn the setting on. With it on, that line is gone and the tab names your active loadout instead, or says there isn't one, as on the Starter Build.

A typo such as F88 or BANANA was saved and reported as bound, though no key you press could reach it.

Clicking into the step box in the editor, or accepting a Tab completion there, cut a colour code you had typed, such as |cffff0000 and |r in a /run print line, down to stray | characters. The first key you typed next, or the completion, put the cut text into the step, and Save kept it that way. Applying the Source tab did the same to every step holding a typed colour code. EMS now keeps a colour code you typed.

With Per-loadout keybinds on, a key saved to your active loadout, which the game binds and /gems binds lists, was missing from the panel you open with /gems keys or Check Conflicts. The spec key that the loadout replaces or turns off was checked in its place and could show as a conflict. The panel now checks the same keys the game binds, and it follows a switch of talent loadout or spec while it's open. A switch of spec with the panel open used to leave it checking the keys of the spec you'd left.

A row you had fixed kept its Fixed mark after the conflict returned, for example when you switched from character to account key bindings and pressed Refresh, so it showed Fixed beside Conflict and a Fix button. It now reads as a conflict again and offers its Fix. A saved key binding that comes back under the sequence's own binding, shown as Covered, loses the mark too.

With Per-loadout keybinds on and a key saved per spec, the Suppress in this loadout checkbox sat on the left end of Check Conflicts, where a click could tick it and turn the sequence's key off in your loadout instead of opening the conflict panel. The "(Press ESC to cancel)" line shown while you set a key was hidden behind Check Conflicts. The line under Keybinds by Spec sat right on top of the Vehicle / Override Bar Keybinds header. The checkbox now has a row of its own under Set Keybind, the Escape hint sits to the right of Check Conflicts, and the vehicle section starts below that line.

The switch took your old spec's keybinds off, but the list and the Keybind tab kept showing them, and the tracker kept showing the sequences they belonged to, until something else redrew them.

With Per-loadout keybinds on, switching from a saved talent loadout to the Starter Build left the keybinds saved to that loadout in place. The Starter Build has no keybinds of its own, so it now gets the ones saved for your spec.

With one of those pages open when combat started, the number keys 1 to 9, Tab, Space and the page's other keys stayed the page's keys for the whole fight. Your action bar buttons 1 to 9 didn't fire, Tab didn't target anything and Space didn't jump. If you closed the window during the fight, those keys stayed the page's after it too, until you opened and closed the page again or reloaded. The page now lets go of them when combat starts and takes them back when combat ends if it's still open.

If the last key you pressed in one of them before combat started was one it uses itself, such as Tab, it kept every key you pressed in the fight for as long as it stayed open. Your action bar keys and your sequences' keybinds did nothing. Every EMS window now lets your keys through as soon as combat starts.

Once you had closed a popup editor, Tab and Shift-Tab moved no keyboard cursor in the main window while no sequence was open in the editor. With a sequence open, the number keys 1 to 6 went to the game, such as to your action bars, instead of switching the editor's tabs. Deleting the sequence open in the editor while its Keybind tab showed stopped Tab the same way until you picked a sequence. Closing a popup editor with its X, Escape, Save or Discard now leaves the main window's keys working, and so does that delete.

The fixes for "Stub body out of sync" and "No keybind and no stub" kept the name and the lines the sequence had when the Repair panel showed it. Pressed on a Repair panel left open while you renamed or deleted the sequence, or pressed in combat and run after such a rename or delete with Auto-reload sequences at combat end turned off, they made a macro that clicked a button that no longer existed. If a new sequence had taken the old name, they rewrote its macro with the old sequence's lines instead. A fix that ran after you saved the sequence, pressed in combat or on a panel left open, also wrote its macro from the old lines. They now do nothing once the sequence they were built for is gone, and otherwise use it as it is when they run.

EMS already used one like that when it could turn the variable into a macro conditional. Everywhere else it read the body as broken: the Variables tab marked it invalid, the Repair panel listed a parse error, importing one warned that its body was invalid, and a step that used it could cast nothing. It works in all of those now. One that wraps a single call in function() ... end was never flagged, but it gave nothing, so a step that used it cast nothing as well. It now gives what the call returns.

Each /reload added one more macro that clicks their button. Its name was one of theirs with a number on the end, such as GEMS:Fury1 and then GEMS:Fury2. Now no new one is made. Repair lists the extra macros earlier versions left on your character and offers to delete them.

The game hands a macro's text back with a line break on the end, and Repair counted it as a change. On a sequence for another class that still had a macro on this character, it showed "Stub body out of sync" and offered to rebuild a macro that was fine. It did the same on every sequence after a /reload in combat, until combat ended or, with Auto-reload sequences at combat end turned off, until you typed /gems apply. It ignores that line break now.

With the warning that a variable returns a spell name showing, the Function Body box sat at the bottom edge of the tab, partly outside the window. When that spell's aura is private as well, both warnings showed and the Function Body box covered the Events row and the top of the events box. With no warning, the Insert Helper button sat at the bottom right of the tab. The Function Body box and its Insert Helper button now sit under the Name box and under any warning that shows, and the Events row and everything below it move down with them.

With a popup editor, the Repair window, the comparison window, the tutorial, the theme editor, the export window, the import window or one of EMS's dialogs open, such as the one that asks before you delete a sequence, Enter opened no chat and Space made no jump. Both now reach the game unless the keyboard cursor presses something. Enter no longer presses the button under the keyboard cursor in those windows, and Space still does. Enter in a dialog's own text box still accepts the dialog. Space on that text box put you in the box and typed a space there, and now it only puts you in the box. In the export window Space on a text box now puts you in that box. On EMS's pages in the game's Options window Space made no jump either. There it now reaches the game unless the keyboard cursor is on a setting Space can press, such as a checkbox, a menu, a text box or a button. In the spell picker Space works the same way now, and Enter still starts a new line in the macro you're writing. Space on a conditional there, such as [mod:shift], put a space in your macro after the conditional, and now it adds the conditional alone. Space on Insert beside the picker's Custom box did the same after that box's text, and now it adds the text alone.

Creating, saving, deleting or renaming a variable, letting Repair create one, or importing one stopped every variable with game events in its Events box from refreshing on the events it already refreshed on, until you reloaded. A sequence using one kept the value it had unless something else rebuilt it. Each variable now keeps refreshing on its events.

A /cast, /use, /castsequence or /castrandom whose spell is a variable, such as /cast ~MyVar~, or holds one, was looked up as a spell name. Repair listed it as an Unknown spell error, the sequence list's health badge dropped for it, and the export and send warnings counted it, so it could ask whether to export or send anyway on its own. The Steps tab coloured the step's number red and its tooltip said Not found: ~MyVar~, and the import window counted it among spells that may be invalid. A #showtooltip ~MyVar~ line was listed in Repair as a stale tooltip. A misspelled spell in a line of its own, or after a ;, is still reported.

After an import, the chat line's issue count also counted things the Repair window never lists, such as the sequence being open in the editor, a variable used in its steps, being in combat, or the Repair window being open. A sequence with nothing to repair could read "Found 3 issues". The warnings before an export or a send counted the sequence being open in the editor, and every selected sequence once more while the Repair window was open, so a sequence with nothing to repair asked whether to export or send it anyway. /gems repairall opened its window for those same rows instead of saying all sequences are healthy, and with the Repair window open it printed nothing at all, even with nothing to repair. The import line and both warnings also counted what Repair says about your own character. A sequence with no keybind and no macro made an export or a send ask, and so did every sequence while your click rate was 0. The import line and the two warnings now count what the Repair window lists for the sequence and leave out its rows about your character: the sequence's macro, its keybind, its button name, its class, spells of your class you can't cast right now, your click rate and your tap controls setting for empowered spells. /gems repairall counts everything the Repair window lists, so with nothing to repair it says all sequences are healthy.

The export window reuses its rows, and a row kept part of the layout of the last kind of row it showed. A macro's account or character column sat out of line with the rows around it, and after Back a sequence's name sat over its own icon. The import window could put a sequence's name over its icon the same way. In the Steps tab a step's row could keep the !! or ! spell warning of a block it showed in an action sequence.

The tag was a pixel too narrow for WARN, so every warning row read WA... instead. Every tag now takes the width of the widest one. In v2.4.20 a row whose fix changed nothing read [No change] on two lines, because its status column was too narrow for it. The status column now takes the width of its widest mark.

With the Repair window open and something to repair, they printed nothing and opened nothing. Each now says the Repair window is already open and leaves the window as it is.

A step that cast one, such as a Felguard's ability while your Imp was out, was treated like a misspelled spell. The export and send warnings counted it, so they could ask whether to export or send anyway on its own. The import line counted it, the sequence list showed its warning icon and its health badge dropped, and the editor showed its spell warning and marked the step's spell as not found. Repair now lists it as Spell not learned. The export and send warnings, the import line, the sequence list's icon and health badge and the editor's spell warning leave it out, and the Steps tab marks it as not in your spellbook instead of not found. A misspelled spell is still reported, and so is a spell your class doesn't have.

Fix All fixed nothing. After you fixed one row, the next row showed [Fixed] and offered no Fix. A row you fixed and then undid kept its [Fixed] mark, and Undo after Redo left the fix in place. Closing the window after you undid a fix still said in chat that it was fixed and recorded the sequence as repaired. Each row now keeps its own mark, Fix All fixes every row it can, Undo and Redo put the sequence and the marks back as they were, and closing the window counts only the fixes you kept.

A #showtooltip or #show line that names an item, such as #showtooltip Healthstone above /use Healthstone, is how a macro shows that item. When the game had loaded the item that session, Repair listed it twice: as an item in a non-/use command, a warning, and as a stale tooltip. Both lowered the sequence list's health badge, and the import line counted both. Repair now leaves such an item alone, and the editor's spell warning, when it shows for another spell, no longer lists it among the tooltip lines. The game can only look an item up by name once it has loaded the item that session, so the tooltip of an item it hasn't loaded yet is still listed as stale, as before. An empowered spell named only in a #showtooltip line no longer draws the channeling warning, the note that its release is available or the note about empower tap controls. Repair also checks a step stored as a list of lines, a form an import can bring in, where it skipped one. A misspelled spell in it is listed as an Unknown spell, which the export and send warnings and the import line now count, as the editor's spell warning already did, and an empowered spell in it under a channeling conditional draws the channeling warning.

/cast uses an item when the name finds no spell, /castsequence uses an item it names, and /castrandom uses an item whose spell has the item's own name, such as the Hearthstone or a hearthstone toy. When the game had loaded the item that session, as it does for an item in your bags, Repair listed it as an Unknown spell error and as an item in a non-/use command, a warning, so the export and send warnings counted it, the sequence list's health badge lost 13 points, and the editor's spell warning listed it. It now reads as the item, and the editor's preview no longer tints a step that uses an item red. Repair keeps a note for an item in /cast alone: an info row, which costs the badge 1 point, and whose help no longer says that items need /use. The import line still counts that note, and an export string, which carries how many problems Repair finds in each sequence, still counts it as a warning. A number in a /cast in place of an item's name now reads as an Unknown spell, an error, where it drew the item warning. An item the game cannot find by name yet, and one /castrandom will not use, are still listed as unknown, as before.

Most map rows were matched to a different map. Tol'Viron Arena and Tiger's Peak were swapped. A version ticked for Ashamane's Fall ran in Blade's Edge Arena instead, and the same went for Hook Point in The Robodrome, Mugambala in Empyrean Domain and Empyrean Domain in Maldraxxus Coliseum. Ticking Blade's Edge Arena, Nagrand Arena, Maldraxxus Coliseum or The Robodrome did nothing. In battlegrounds, a version ticked for Silvershard Mines ran in Warsong Gulch, Seething Shore in Arathi Basin and Wintergrasp in Deepwind Gorge, and ticking Warsong Gulch, Arathi Basin or Deepwind Gorge did nothing. Map ticks still apply only in unrated arenas and battlegrounds.

Apply refused it with a missing-field message and saved nothing.

The rename dropped the pin, so the sequence went back to its ticks and its default version without telling you.

The first step you turned off on a sequence of plain steps made it an action sequence, and saving it dropped every step's label.

The Shift, Ctrl and Alt buttons always read Add, so after you added a variant its button still said Add, and clicking it again removed the variant. The Source tab's button kept reading Edit while your text was open for editing, and clicking it applied your changes. Now a variant's button reads Remove while the variant is there, and the Source tab's button reads Apply while you're editing.

They drew empty, and typing into one replaced that step with what you typed. Each box now shows its step coloured, and a step too long to colour within the box shows plain.

In a popup opened on a sequence whose version is built as an action tree, picking a version without one from the version button, editing a step and saving gave that version the action tree of the version the popup opened on. The popup now keeps each version's own tree, or none.

Each of them, pressed with unsaved changes in the editor, reloaded the sequence with no prompt, so your changes and your undo history were gone. The editor now keeps them, and your next Save keeps the pin or the disable. With unsaved changes the editor also keeps them through a change made to the sequence elsewhere, and your next Save replaces that change to the version you're editing. If the editor can no longer find that version, as when it was deleted elsewhere, a line under the version bar says so, and your next Save adds your work as a new version at the end of the sequence.

With the window closed, a change made elsewhere that removed an earlier version of the sequence open in the editor left the editor on the old version number, so your next Save wrote over the version that had moved into that place. The editor now catches up with such a change before it shows the sequence again or saves it, and a Save writes over no other version.

The prompt asks whether to save your changes before you switch version or pick another sequence. Escape threw the changes away, as its Discard does. It now does what Cancel does: the prompt closes and the editor keeps your changes, on the sequence and version you had open. Discard now sits beside Save, and Cancel last.

With a version open that isn't the one in use, Apply put the editor back on the version in use, so the next step you edited and saved went into that version and changed what the sequence casts.

EMS turns [GRIP-EMS: Player - Sequence] in chat into a link that asks that player for the sequence when you click it. In v2.4.20 a line someone posted from Discord into guild chat got that link too, so a Discord user could type the tag and point it at any name. EMS now leaves Discord lines as they are.

The picker inserts a helper as GRIPEMS.HasBuff(0, "player"). Variables understood that form and recommendations did not, so a recommendation built from a picker snippet failed on its first line and never lit anything. With debug output off, which is how it ships, nothing in chat said why. Recommendations read the same form as variables now. The plugin condition call GRIPEMS.API:EvaluateCondition("id") reached neither before and works in both now. The plugin documentation only ever shows it inside a variable body, and that is the case that was broken.

A sequence whose Step Function came from a plugin kept casting in that plugin's order after the plugin was disabled. It went on doing so until you reloaded or the sequence was next rebuilt, and that rebuild could repeat the previous cast on one press before the sequence started over. The sequence now plays its steps in order from step 1 as soon as the plugin is disabled. Turning the plugin back on returns it to the plugin's order from step 1, which used to wait for a reload.

A sequence imported from a string could carry a created, updated, forked or last modified date that isn't a date at all, or fork and edit history stored in the wrong shape, and a plugin could hand EMS a created date like that too. Selecting such a sequence stopped the editor with an error after the name and details, and the steps and tabs below kept showing the sequence you had open before. The editor now leaves a damaged date blank and loads the rest. The author badge in the import preview had the same problem, in its hover details and in the full chain list a click on it opens, and is fixed too. The Last modified line no longer shows 1970-01-01 when no date was recorded, and shows ? when the name of whoever changed it is missing. A sequence a plugin adds shows no Created date, since plugins add their sequences again every session.

EMS loads a plugin's sequences before your own saved ones, so it didn't see yours yet and saved the plugin's over it, and yours was gone. Yours now wins.

Deleting a character macro moves the ones after it, and the tab kept the old position until you pressed Refresh, so it could name another macro. The Repair panel could call a sequence's macro out of sync for the same reason, and a plugin asking for the macro could get the wrong one. If you delete the macro itself, the Repair panel says so and its Fix makes a new one, and a plugin that asks EMS to make the macro gets a new one.

Pressing Preview on one whose default version held a Pause stopped with a Lua error and showed nothing, so the import window couldn't import it. The preview's note that the Pause became empty steps sits under a heading of its own, Import notes.

Repair checks whether a version with no steps holds its macro lines in Key Press or Key Release instead. On one stored as a list of lines, that check stopped with a Lua error, and so did the Repair window, /gems repair, /gems repairall, a sequence's Repair menu entry, the issue count after an import and the warnings before an export or a send. Repair now reads such a Key Press or Key Release as the lines it holds, and lists one holding a /cast or /use line as Content in keyPress not steps or Content in keyRelease not steps, as it does one stored as text.

v2.4.20 stopped at a Lua error at every Forever login, because two spec functions it called are gone from that client. Nothing after that point in the login ran, so the settings panel never registered, sending and receiving sequences didn't work, and plugin sequences, the tracker HUD and the floating menu never loaded. The spell cache stayed empty for the whole session. Selecting a sequence filled in its name and icon, then stopped with an error before its steps and its Keybind, Macros, Variables, Variants and Source tabs loaded, so there was no way to bind a key to it. Every press of a sequence key after the first threw an error as well, though the cast still went off. The keybind conflict panel listed none of your sequence keys, and a spec check in a RECOMMEND expression or a custom variable always read false.

The notice says the All Classes spell list may be out of date for your game build. A Forever build never matches the retail build that list comes from, so v2.4.20 printed it at every Forever login. Retail prints it as before.

Lines that put a number before a word read wrong when the number was one, such as "Found 1 issues", "1 sequences, 1 variables", "1 versions, 1 steps", "Sequential | 1 steps" and "Modifier chain has 1 entries". The Repair window's summary and its "Fixed 1 issues" line, the step list's Loop and Pause summaries, and /gems memcheck, /gems monitor and /gems perftest were also in English in every language, and the Repair summary's severity counts read "2 error". Sending several sequences at once named them in English too. Each of these now reads right at one in every language EMS ships. The comparison window's tooltip for step 5 read "5 steps", and it now reads "Step 5:". The import report's two skipped lines read "Skipped: 1 (already exist)" and "Skipped 1 variable(s) (already exist).", and they now read "Skipped: 1 sequence (already exists)" and "Skipped: 1 variable (already exists)". A Key Press on a version with no steps said "Fits in all 0 steps", and it now says the version has no steps. The word after an interleave box read "steps" with 1 in the box. Most lines that hedged a count with "(s)", such as "Restored 1 keybind(s)." and "Imported: 2 sequence(s), 1 variable(s)", now take the right word for the number in every language. A few French lines still hedge their count, such as the Repair summary's count of what it can fix, and so does the Italian count of spells known but unlearned in the import window. On Korean and Chinese clients /gems loadclass swapped its two numbers, so its line gave the count as the class and the class as the count. Counts also take the form your language uses for each number, where every count took one plural form. In Russian a count of 2 to 4, or of 21, 22 and so on, took the form for 5 and up. French and Brazilian Portuguese now take the singular at zero as well as at one. More count lines read right at one in every language, among them the line after /gems create, the Steps tab's count of selected steps and the question before it deletes them, the import report's count of sequences kept for other classes, and the theme editor's question before Unsilence all.

When EMS copied them, at your first login or from Re-detect accessibility settings, chat printed ACCESS_CVAR_MIRROR_TOAST_APPLIED, the line's internal name, in every language. It now says how many settings it copied, in your language.

In Spanish, Mexican Spanish, Brazilian Portuguese and Russian the label above the step editor and the preview's step tooltip read "Step 3:" in English. The "Every:" beside an interleave box and the Add menu's Action (Interleave) were English in every language but Chinese. The Repeat label in the editor and on a Loop, the Add menu's Step, Loop, Pause, If, Embed and Macro, the names of Loop, Pause, If and Embed actions in the Steps tab, and the "Loop > Action 2:" line over an action you edit were English in every language. So were the Repair window's title, its section headers, its Fix, Done and Undo buttons, its [Failed], [Queued] and [No change] tags and its line about repairs queued in combat. The tooltip on the editor's Repeat box was English in every language too, and in Spanish, Mexican Spanish, Italian, Brazilian Portuguese and Russian so was "Unavailable during combat", the line a Save button's tooltip shows in a fight. They're now in your language.

In Simplified and Traditional Chinese, the chat line after you set a manual click-rate override and the SQW advisory line on the Options page stopped with a Lua error, and so did the line for a spell cache received from another player with debug output on, which also failed in Korean. In Korean the warning about a Key Press too long for some steps stopped with a Lua error when it named more than one step, and gave the step and the step count the wrong way round when it named one. In Italian the debug line after a spec change reset a sequence stopped with a Lua error. Fourteen Russian lines now name the sequence, key, slot or count they are about, where they left it out, such as the line for a sequence /gems can't find.

A step can be stored as a list of lines, a form an import can bring in. In the Steps tab, clicking such a step stopped with a Lua error, and its row took no spell warning colour, showed no modifier badge and no tooltip, and counted its lines instead of its characters. The popup editor drew its row for it as an empty box with no count, and the game raised a Lua warning. Disabling a step, or adding a Loop, If, Pause, Embed, Interleave or macro, in a sequence holding one and then saving erased its lines. The comparison window stopped with a Lua error on it and called it changed against the same text. Applying the Source tab saved it as a line starting with table:, which casts nothing. The Key Press status line could say the Key Press fit such a step when it did not, the Dependencies panel missed the sequences it clicks, and an Embed step's spell and combat warnings in the Steps tab missed the spells and commands in it in the sequence it embeds. An If block holding an Embed of a sequence with such a step stopped with a Lua error, so the sequence holding the If block didn't load. Each now reads the step as the text it casts, and an Embed inside an If block casts that text too, the If's condition on each of its lines. Applying the Source tab saves such a step as that text, and so do a save after you turn a step off or add a block, a press of a step's toggle key, EMS putting the sequence's spell names into your client's language, and the repair EMS runs once at login that puts a spell's own name back where a talent's name for it was saved. Opening, checking or casting it leaves it stored as a list of lines.

The command tries EMS's spell name translation on one of your sequences whose steps are tagged for it, and checks its step, its Key Press and its Key Release. When one of them was stored as a list of lines, the translation turned it into its text, and the command stopped with a Lua error partway through its report. It now compares each as the text it casts, so one that came back as its own text reads as a match.

If you disabled a sequence during combat and then used Set Default on another of its versions, the sequence could vanish when combat ended. It was gone from your list and from your saved sequences. Adding or removing a variant during combat did the same to any disabled sequence, from the Variants tab or with /gems variants, however long ago you had disabled it. The sequence now stays in your list and stays disabled.

A save that changes the number of steps or the Step Function waits for combat to end before it takes effect. If you saved again before then, and that second save had the same number of steps and the same Step Function the sequence had before the fight, the first save replaced it when combat ended. The first save is also what stayed in your saved sequences. A save made after you disabled and re-enabled the sequence in the same fight was lost the same way. Your second save is the one that stays now. A save that waits for combat to end is also written to your saved sequences straight away, so a reload before the fight is over keeps it.

EMS keeps up to four popup editors open. One with no unsaved changes, closed by Escape in combat, still counted as open, and with four of those closed, opening another said you had hit the editor window limit with none on screen. A popup with unsaved changes asks whether to save them before it closes. Choosing Save there in combat closed the popup and threw your changes away. It now prints "Unavailable during combat", the line the Save button's tooltip shows in a fight, and keeps the popup open with your changes.

Clicking one there changed nothing on the page. It already worked in the window /gems settings opens.

It started as Public whatever that setting said.

Both sat at the bottom of the page, under every other section. They're now its first two sections, and the others keep their order.

With no sequences there, it asked whether to migrate all sequences and said it had found 0. It now says there's nothing to migrate and asks nothing.

A step of two lines took the If's condition on its first line only, so its second line cast whatever the condition, and a step opening with #showtooltip got the condition on no line at all. Each line that casts now takes the condition, a step in the If's other branch takes the opposite condition on each line, and a #showtooltip line stays as it is.