All ten ride `ui_cast_events.rs`'s existing `CastEventFeed` rows — the
same rows `UNIT_CASTEVENT` and the cast windows are folded from — with a
new `NpCastColumns` carrying the fields nampower's shapes want and
SuperWoW's one word has no place for. One row per packet, folded once,
which is this file's own rule: an addon woken by one of these and then
asking a getter must not be able to get a contradicting answer, and a
parallel queue over the same packets is exactly how that happens.
`NP_EnableSpellStartEvents` and `NP_EnableSpellGoEvents` go from
stored-only to LIVE. Their rows said the shapes wanted
"itemId/spellType/corpseOwnerGuid columns this client does not carry";
two of those three turned out to be a Spell.dbc lookup and a guid hop
the item-cooldown path already made. `itemId` is the cast item's entry
through `item_entry` (now shared with `item_cooldown`, which had the
same two hops inline) — `SessionEvent::SpellStart` was dropping the
guid the GO always carried, so it carries it now. `spellType` is
`AttributesEx & 0x44` for a channel and the auto-repeat bit for a shot.
`channel_ms` is `SpellDuration.dbc`. The GO's two counts are the
packet's own lists, capped at 255 because the server writes both as
`u8`s. `SPELL_FAILED_SELF`'s result byte is the failing
`SMSG_CAST_RESULT`'s reason — the number 1.12 turns into a red line and
then discards, so no addon on that surface can see why a cast failed.
`corpseOwnerGuid` is the one column that really is absent, and it is
not sent at all: a trailing nil in Lua is indistinguishable from an
absent return, and upstream sends nil for every cast without a corpse
target. For the handful that have one the gap is bounded and written
down — the targets block reads the corpse guid and drops it, and the
owner is a further hop through that corpse's own CORPSE_FIELD_OWNER.
Two subtleties, both pinned by tests:
- A channel's START is queued although its wire cast time is 0, and
`UNIT_CASTEVENT`'s START is still suppressed for it. Without the row,
`SPELL_START_SELF` would never fire for Mind Flay or Blizzard — pfUI's
reader expects exactly that row and falls back to arg7 "only for true
channels like Blizzard where arg6 is 0/nil". With the word, every
cast-tracking addon on this realm would get a SuperWoW START whose
arg5 is 0, which is a cast bar told to run for no time. So the
suppression moved from the producer to the fire, and SuperWoW's word
behaves exactly as it did before the row existed.
- The `_SELF`/`_OTHER` split is by caster here and by *target* for the
aura family next door. Neither is a guess: upstream's wording for the
aura pair is "casts that land on the active player", and for this one
pfUI handles both names in a single arm and then reads arg3 to learn
the caster, which only makes sense if the name already settled it.
A gate hole closed on the way past: `AURA_CAST_ON_SELF`/`_OTHER` were
fired through one `&str` variable, and `reference_ui.rs`'s beyond-1.12
event gate reads the string literal *at the call* — so it had been blind
to that pair for as long as they had existed. Both are literals now,
with their rows, and the probe confirms it: renaming either row makes
the gate name the event.
Tests read pfUI's own `local` bindings back out rather than a list of
values in push order, as the aura-cast block beside them does. A
positional shape got backwards here fails in silence — the handler binds
arg3 to casterGuid whatever arg3 happens to be — and this family is
where that would be most expensive, since pfUI's swing timer resets off
the START and its whole debuff bookkeeping gates on the GO's two counts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
dc59594389