gromandClaude Opus 5
02e6fc4208
grom is keeping `patch-A.mpq` — it is almost certainly textures — so the shadowing it causes is handled in the chain instead of on his disk. `mount_order` stays the reference's law, letter above digit and all, and `demote_stale_snapshots` runs after it: an archive whose `FrameXML.toc` is a **strict subset** of another's is an earlier edition of the realm's manifest, so it mounts just below the patch set — above `patch.MPQ` and the base archives, so anything only it carries still resolves. A toc that differs by *removal* is a different manifest rather than an older one and is left exactly where its name puts it. `WOW_CHAIN_DEMOTE=0` keeps the reference's order for comparison. On his install `patch-A.mpq` (Aug 7) now loses to `patch-5.mpq`, so the realm's current data is what loads: its `FrameXML.toc`, its `GlobalStrings.lua` and a `Spell.dbc` with **28019** rows against the 27992 his last session reported — 27 spells the update added that were invisible. Reading the realm's real files then broke ten tests, all of which had pinned August's behaviour, and each is now pinned the realm's way: - `AIOHandlers.lua` claimed the `OctoRadio` block as a no-op on the evidence that the radio file carried no AIO call. The update built the radio out into a file twice the size whose `RegisterNowPlayingFeed` registers that name at `VARIABLES_LOADED`, and `AIO.RegisterEvent` asserts on a duplicate, so our shim raised through seven tests. The row is gone, and the shim now claims at `PLAYER_LOGIN` through `pcall` so a realm that implements one of these takes the name and we step aside. `no_aio_block_we_shim_is_one_the_realm_now_handles` fails a row the realm has implemented — verified by putting `OctoRadio` back. - `BATTLEFIELDS_CLOSED` no longer hides the battlefield list, by the realm's decision: the server stamps `SMSG_BATTLEFIELD_LIST`'s battlemaster guid with the player's own, so the client anchors the window to the spot it opened and closes it when you step away, on foot or on a boat (bug tracker #330 and its follow-up). Pinned that way, with the close button proving the list still closes. - `MAX_QUESTLOG_QUESTS` is 25, not 1.12's 20. The test reads the realm's global now, so the next bump is data and not a failure. - The realm's `OctoQuestLogPoller` redraws the log every 0.2 s, which legitimately costs a layout gate walk. `POLLS_ON_A_TIMER` stands it down by name before the quiet-frame bench measures, rather than raising the threshold and blunting the one instrument that catches an every-frame writer. A timed realm handler that is not listed fails. 269 data-gated failures, identical to the baseline at HEAD name for name, and all nine gates green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
42 lines
2.6 KiB
Lua
42 lines
2.6 KiB
Lua
-- benilla's own: tolerate the server's AIO blocks this client has no feature for.
|
|
--
|
|
-- AIO dispatches a server block by name through `AIO_BLOCKHANDLES`, and an unregistered name is
|
|
-- an `error()` (`AIO.lua:547-549`). That is the right shape — except **pfUI replaces the global
|
|
-- `error` with one that prints to chat and returns** (`pfUI.lua:453-460`, which it does to feed
|
|
-- `seterrorhandler`). A non-raising `error` turns AIO's clean abort into a fall-through: the
|
|
-- next line calls the handler it just failed to find, so the player sees two errors, the real
|
|
-- one being `attempt to call local 'handledata' (a nil value)` at `AIO.lua:558`.
|
|
--
|
|
-- That is pfUI's bug and it would bite the reference client the same way; what changed here is
|
|
-- only that benilla now loads AIO at all (for the calendar). So the blocks this client does not
|
|
-- implement are registered as no-ops, which is what "no handler" was always supposed to mean.
|
|
--
|
|
-- `IGNORED` is empty, and the shape around it is what matters. `AIO.RegisterEvent` *asserts* when
|
|
-- a name is already taken (`AIO.lua:736`) and AIO has no way to unregister, so a name claimed
|
|
-- here is claimed against every later registration — including the realm's own, if a client
|
|
-- update implements the block we were standing in for. That is not hypothetical: this file used to
|
|
-- claim `OctoRadio` on the evidence that `OctoRadioPlaceholder.lua` carried no AIO call at all,
|
|
-- and the 2026-10-23 update built the radio out into a file twice the size whose
|
|
-- `RegisterNowPlayingFeed` registers exactly that name at `VARIABLES_LOADED` — ten tests' worth of
|
|
-- raise, from a row that had simply gone stale.
|
|
--
|
|
-- Hence both halves below. The claim waits for `PLAYER_LOGIN`, after the `VARIABLES_LOADED` where
|
|
-- FrameXML and addons register and before any block can arrive, and each name goes through
|
|
-- `pcall`, so a realm that implements one of these takes the name and this file steps aside
|
|
-- instead of raising. `reference_ui`'s tests fail a row the realm has implemented, so the next one
|
|
-- is caught in the gate rather than in a session.
|
|
local IGNORED = {}
|
|
|
|
if AIO and AIO.RegisterEvent and not AIO_SERVER then
|
|
local claim = CreateFrame("Frame", "BenillaAioShimFrame")
|
|
claim:RegisterEvent("PLAYER_LOGIN")
|
|
claim:SetScript("OnEvent", function()
|
|
for _, name in ipairs(IGNORED) do
|
|
-- Discarded on purpose: a failure means the name is taken, which is the good case.
|
|
pcall(AIO.RegisterEvent, name, function()
|
|
-- Nothing: the block is for a feature this client does not implement.
|
|
end)
|
|
end
|
|
end)
|
|
end
|