grom/benilla-octo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

What the second player actually saw: four panel entries and no nameplates

Browse Source 
A second player's four `/errors` entries, all from one session, none of them a
fault in the two addons he was reporting:

  1. `FloatingChatFrame.xml: SetScript("OnInputLanguageChanged") unsupported`.
     Ours. The slot is real 1.12 and the *realm's own* FrameXML sets it on
     `ChatFrameEditBox`, so every player met a red error on every login for a
     line none of them wrote. `SCRIPT_KINDS` now accepts it and never fires it,
     which is also what the reference does — a client with no IME never fires it
     either. The rule the old test stated is unchanged and restated: a 1.12 slot
     benilla neither fires nor finds in a shipped file still raises.

  2. `bindings.xml: root element is <Bindings>, not <Ui>; tolerated`. Every
     `Bindings.xml` in the corpus has that root and `bindings_xml` reads it
     correctly. No longer said.

  3. `bindings.xml: Unknown frame type: Binding`, counted 69. Faithful — the
     reference logs the same line (`0x871124`) for every row while `0x51f400`
     registers them separately — and ours registers them too:
     AlternativeClassicActionBars' 69 bindings all answer `GetBinding`. Now a
     trace, so the terminal keeps it and the panel does not.

  4. `SetOwner: unknown anchor 'BOTTOMRIGHT' on owner 'WorldFrame'`, counted 292.
     The hunt for that caller ended a while ago: it is `Shop_ProcessEntries` in
     the realm's own `Turtle_ShopUI`, off the player's patch chain, and the
     reference accepts an unknown anchorType silently (mode 0, ANCHOR_LEFT), as
     we do. The diagnostic has done its job; it is now host-log-once
     (`Model::warn_host_only_once`) and not retained.

The panel is where someone looks to find what is broken in *their* interface.
A line that is faithful, or names a file they cannot reach, crowds out the ones
that are theirs.

----

A second player sent a video: Options → Nameplates with all six boxes ticked,
the V binding set, and no plates at all — while the overhead *names* drew fine.

`VPlateMode::default().range_sq` was `0.0`, and the gate is
`distance_squared > range_sq`. Zero is not "no cull"; it is "cull everything, at
any distance". `NameplateRange` is a registered CVar with default `"80"`, and a
registered default is not written to `config.toml`, so no `CvarChanged` ever
fired and the field never left its derived value.

This is the trap the paragraph three fields above already documents, and which
`occlusion` and `spread` were fixed by writing their registered defaults into
`Default`; `range_sq` was left behind. It stayed hidden because
`NameConfig::default()` — the overhead names — already carried `80.0 * 80.0`, so
names drew and only plates were missing, which reads as a nameplate-addon
problem rather than an engine one. It could not be reproduced here either:
grom's own `config.toml` carries `NP_NameplateDistance = "62"`, which seeds the
same field through the other observer arm.

`the_plate_range_default_agrees_with_its_registered_cvar` now pins the default
to `registered_pairs()`'s row and pins the plate and the name culls to each
other, since a disagreement between those two is what made this read as
somebody else's bug.

It also answers the other half of his report. The gate `continue`s before the
plate is seated at all, so with `range_sq` at 0 no plate frame ever exists —
and UnitPlates works by adopting the plate frames under WorldFrame. One bug,
both symptoms: "nameplates will not turn on" and "UnitPlates does nothing" are
the same line.

And a packaging answer that comes before both, for UnitPlates specifically:
GitHub's "Download ZIP" unpacks `Redbu11dev/UnitPlates` as `UnitPlates-main`
with `UnitPlates.toc` inside it. The client looks for `<Folder>/<Folder>.toc`,
so the addon never loads — here or on the real client. The harness says it in
as many words: "no manifest under other-addons/UnitPlates-main — is that an
addon folder?". It has to be renamed `UnitPlates`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
This commit is contained in:
grom
2026-10-30 09:02:47 -06:00
co-authored by Claude Opus 5
parent 5751857890
commit 89dc99f4d1
9 changed files with 180 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ADDON_COMPAT.md
+38
View File
@@ -1404,6 +1404,44 @@ the failure is silent on both clients.
`loader/tests.rs`'s `a_bindings_document_loaded_as_framexml_raises_nothing` pins the count
deliberately. Noise, faithfully.
### Round two: what the second player actually saw
He reported both addons "still not working" and sent four screenshots of the error panel. Not one
of the four was a fault in either addon — all four were **benilla telling him about things that
were either faithful or not his**, and the panel is the first place someone looks to find what is
broken in their interface:
| entry | count | verdict |
|---|---|---|
| `FloatingChatFrame.xml: SetScript("OnInputLanguageChanged") unsupported` | 1 | **ours** — a stock script slot we refused. Now in `SCRIPT_KINDS`, accepted and never fired, as the reference has it. The line is in the realm's *own* FrameXML, so every player met it on every login. |
| `bindings.xml: root element is <Bindings>, not <Ui>; tolerated` | 1 | noise — every `Bindings.xml` in the corpus has that root and ours reads it correctly. No longer said. |
| `bindings.xml: Unknown frame type: Binding` | 69 | faithful (the reference logs it too, `0x871124`), and the bindings all register — `GetBinding` answers for all 69. Now a **trace**: the terminal keeps it, the player's panel does not. |
| `SetOwner: unknown anchor 'BOTTOMRIGHT' on owner 'WorldFrame'` | 292 | `Turtle_ShopUI.lua:530`, the realm's own file, off his patch chain, and the reference accepts an unknown anchorType silently (mode 0). Now host-log-once and not retained. |
There is also a **packaging** answer, and it is the first thing to check with him: GitHub's "Download
ZIP" unpacks `Redbu11dev/UnitPlates` as a folder named **`UnitPlates-main`**, and it ships
`UnitPlates.toc` inside. The client looks for `<Folder>/<Folder>.toc` and finds nothing, so the
addon never loads at all — on this client or on the real one. Our own copy under `other-addons/`
has the same name, and the harness says so plainly: *"no manifest under
other-addons/UnitPlates-main — is that an addon folder?"*. It has to be renamed `UnitPlates`.
And the one he was really reporting, which was in neither addon: **nameplates would not turn on at
all.** `VPlateMode::default().range_sq` was `0.0`, and the gate is `distance_squared > range_sq` —
so zero does not mean "no cull", it means "cull everything at any distance". `NameplateRange` is a
registered CVar with default `"80"`, and a registered default is *not written to `config.toml`*, so
no `CvarChanged` ever fired and the field never left its derived value. Any player who had never
moved that slider got no nameplates, with both checkboxes ticked and V pressed.
And it is the other half of "UnitPlates does nothing" too: the gate `continue`s **before the plate
is seated**, so with `range_sq` at 0 no plate frame ever exists, and UnitPlates works by adopting
the plate frames under `WorldFrame`. One line, both symptoms.
This is the same trap documented three fields up for `occlusion` and `spread`, which were fixed by
writing their registered defaults into `Default`; `range_sq` was left behind. The overhead *names*
kept working the whole time, because `NameConfig::default()` already carried `80.0 * 80.0` — and
that asymmetry is exactly what made it look like an addon problem. `the_plate_range_default_agrees_
with_its_registered_cvar` now pins both to the registered row and to each other.
### The harness grew a `--plates` step
A nameplate addon is the one kind the survey could not see working: its subject is a `WorldFrame`