grom reports the `[noslamclip]` macro still never picks Slam, and that the same
macro works on the normal client. That rules out my last answer: if the window
were the 7.4% the realm's numbers give (2.70 s weapon, 2.5 s Slam), he would
land Slam on about one press in fourteen. His log has **0 in 477**. A narrow
window is not what that is; a conditional pinned false is.
`GetSlamWindowPercent()` returns a hard `0` whenever `st_timerMax <= slamCastTime`,
and `st_timerMax` can only ever be `UnitAttackSpeed("player")`. That value is
either the streamed `UNIT_FIELD_BASEATTACKTIME` or exactly `VANILLA_SWING_MS`,
because `base_swing` substitutes 2000 for absent-or-zero. 2.0 < 2.5, so a
substituted swing makes `[noslamclip]` false for every press of the session,
silently — and his own swing interval, measured off consecutive `You hit` lines
in `WoWCombatLog.txt`, is 2.71 s.
So the question is whether that field reaches us, and **nothing downstream can
answer it**: `UnitAttackSpeed` returns a number either way, `char_stats`' stand-in
warning fires only when no sheet at all was pushed, and 2.00 s is a real weapon
speed, so a substituted sheet and a genuine 2.00 s weapon are indistinguishable
from Lua, from the log, and from every test — because every test seats a sheet
before it asks. That is the same blind spot that let me invent a cast time and
call the chain healthy.
`warn_once_if_main_swing_substituted` says it at the one place that still knows:
the feed, holding the store, before `base_swing` erases the difference. Once per
process, naming the field and pointing at the combat log as the cross-check.
This is an instrument, not a fix. It makes the next session's log answer the
question instead of another round of reasoning from code that reads correctly
under both hypotheses.
grom
7c0a99c006