wow.jim.wiki

Format and limits

How an import string is actually put together, and the client rules that decide whether an aura can work at all on Forever.

Written from the sources rather than from a screenshot: the format was worked out against the upstream libraries, and every string on this site is decoded again on each build to catch a generator that has drifted.

01 — The string

One line of text wrapping a compressed Lua table.

An import string is not a file format the game reads from disk. It is a single line beginning !WA:2!, and everything after that prefix is a serialised Lua table run through two compressions and an encoding:

  1. the aura table is serialised (LibSerialize),
  2. compressed with raw DEFLATE,
  3. encoded six bits at a time into a printable alphabet with LibDeflate.

The details are the parts that break people's own tooling, so they are worth stating plainly:

  • Alphabet a–z A–Z 0–9 ( ) — 64 symbols, 6 bits each, least-significant bit first, and no padding at the end.
  • Compression is raw DEFLATE (wbits=-15): no zlib header, no Adler-32, no checksum anywhere. A zlib-wrapped stream is a different thing and will not import.
  • Envelope keys are short — m (message type, "d"), d (the aura or group), s (addon version at export), v (transmission format) and c (descendants, keyed from 1).
  • Aura objects use full field names — regionType, triggers, conditions, load, actions, subRegions, semver, internalVersion, tocversion. The short-key layer people remember belongs to the envelope only.
  • Groups: at transmission format 1421 the parent/child link fields are stripped on export and rebuilt on import from the order of c. Format 2000 transmits them, and is used when a nested subgroup exists.

None of this is Forever-specific. The format is client- and flavour-independent; the only thing that changes on Forever is the interface stamp inside the aura (16001) and what the aura is allowed to read at runtime.

02 — The limits

What this client will not let an aura do.

These are the constraints that decide whether an aura is buildable at all, as opposed to merely written. Each one has killed a reasonable-looking aura:

  • Health, power and threat are secret values in combat. A custom trigger that reads them throws, or returns something that cannot be compared. A live health bar must be driven by a widget, never by arithmetic in Lua.
  • The combat log is restricted — threat meters and combat-decision addons cannot work here.
  • SavedVariables are never persisted. A client-side bug, not an addon fault. Auras live for the session; the import string is the durable copy.
  • Lua errors stop being delivered after 100 in a session. Clear the flood before you try to debug anything, or the error you are chasing is simply not arriving.
  • Creature, pet and vehicle GUIDs are obfuscated, and the old Classic-era globals (UnitAura, UnitBuff, GetSpellInfo, GetItemInfo, GetTalentInfo, CombatLogGetCurrentEventInfo) are gone. ReloadUI() is protected.

An author's tooling can flag the risky calls before you ship anything — the generator's lint step looks for exactly these inside custom code.

03 — The invisible aura

The most expensive bug on this client is an aura that is fine.

A status trigger only draws its aura while the trigger is active. So a trigger whose event never fires on Forever gives you an aura that imported, reports no error, appears in the aura list — and never appears on screen. Nothing is broken, and no amount of debugging the trigger will help.

The fix is a Trigger State Updater: custom code that computes the value itself and sets show = true on every run, so the aura cannot be invisible. That is how the XP Bar here is built. Wrap those reads in pcall and check them with issecretvalue, because of the secret-value rule above.

And when you are not sure which side of the line you are on, import the import test first. It always fires, so its outcome tells you whether to keep debugging the aura or look somewhere else entirely.

04 — How these strings were made

Generated, then read back.

Every string on this site comes out of a small tool that builds the aura table, serialises and compresses it, and writes the import string — the same pipeline the addon itself uses, implemented independently. Before a string is published it is decoded back and checked, so a generator that drifts shows up as a failed build rather than a string that will not import.

The table below is what that tool exposes; it is where future strings will come from too.

PieceWhat it does
wa_codecDecodes and encodes import strings. The decoder is also used against real exports to check the understanding is right, not just self-consistent.
wa_genBuilds auras from templates — buff, proc, cooldown, bar, text — with trigger helpers for aura, spell cooldown, status, custom and raw triggers, plus a Forever safety lint.
baselineA field-complete skeleton captured from a real export, so generated auras inherit the exact field set a real export has instead of a remembered one.
The honest boundary. Decoding proves structure, never appearance. A string can be provably well-formed and still draw in the wrong place, with the wrong colour, or not at all. Judging that needs a paste into ForeverAuras in game — which is why every aura page here says whether it has been through that test.

05 — Sources

Where the above comes from.

Written against client build 1.60.1. Where something here came from a survey rather than a direct check, it says so — the addon list on the addons page is the main example.