GRIP-EMS v2.4.11

Some exports store each sequence in a collection as a two part package, the name followed by the sequence, instead of the sequence on its own. EMS unpacked that package when a sequence arrived still encoded and not when it arrived as plain data, and that gap sat in every route it has: the preview, the import itself, and the older migration path. A collection built the second way reported "no macro versions found" for every sequence in it. The preview named the sequences it had just read and then showed nothing, which is the confusing part: it had reached them, it just could not see inside. Nothing was wrong with those strings and nothing you already had was changed. Every route unpacks it now, so the versions and their steps come through. Reported on 26 August with two strings: the one that failed for this reason imports on this build, and the other is an encrypted sequence EMS still cannot read, exactly as before.

When you paste a sequence you already have, the preview builds a fingerprint of each copy so it can tell an unchanged re-import from a changed one, and several parts of that fingerprint were assumed to be plain text. Older sequences can hold a keypress as a list instead, and one of those stopped the preview before it drew anything. Every part is converted before it is used now, for stored variables as well as sequences.

An import holding a version in a shape EMS did not expect could stop the preview, or get past the preview and then stop when you pressed Import. Both points check the shape before reading it now. The preview lists what it could not read in the "Not imported" section with the reason and offers you the rest; a sequence still unreadable when you press Import is set aside whole, with the reason printed in chat, and the other sequences in the same paste import as normal.

If a sequence ended up saved in a shape EMS did not expect, whether from an old import or a hand edited file, reading it could stop whatever was asking. That included activating it, saving it in the editor, the step count and step text on the tracker, and what another addon was told when it asked about the sequence through the plugin interface, which could stop or hand back a step count that was plainly wrong. One of these sequences could also quietly empty itself: rebuilding it read the steps back out of a shape that could not be read and wrote the empty result over the ones you had, leaving the sequence with no steps, nothing on screen to say so, and the loss still there after a reload. Those reads check the shape first now, so a sequence EMS cannot use is passed over and the steps it does have are left alone.