Three of the DLL's own manifest, and two of them needed no new feed at
all — which is the point worth recording, because the row that called
this family "todo, blocked: each needs new app-side state" was wrong
about two of the three.
`CanLootUnit` is the loot sparkle's test read through the token map:
`UnitState` already carries `dead` and raw `dynamic_flags`, so a corpse
that sparkles answers 1 and there is one source of truth for "has loot
for me". The bit is per-viewer on the server, so "can" means can.
`UnitNameplate` goes through the SAME `plate_frame` wrapper as
ClassicAPI's `C_NamePlate.GetNamePlateForUnit`, welded by a test that
asserts both names hand back one object — an addon may feature-detect
either, and two different frames for one plate is the kind of bug that
only shows up as an anchor in the wrong place.
`GetSpeed` is the one that needed a field: the posture snapshot gained
`speed`, filled from `net::current_speed`, the reference's own
`CMovement::GetCurrentSpeed 0x7c4c90`. What could not be settled is
written down rather than guessed over — upstream publishes no prose and
nothing in the corpus calls it, so "current" is a reading, taken because
it is the more informative of the two and because it is the only function
in the client named after speed that a hook would return. Standing still
it is 0, as that getter is.
`SelfMovement` loses its `Eq` (an f32 field); nothing compared two
snapshots — the feed assigns a fresh one each tick.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
ac857ada36