Cinematic's Nameplates page asks `GetCVar(name) ~= nil` before it will offer a
row (`Effects.lua`'s `HasPlateSettings`). A nil answer is not "off" to an
addon written for a later client — it is "this client has no such setting" —
and the whole row goes grey, which is why grom could not touch Friendly NPCs.
The two rows that worked were the two that happen to name
`nameplateShowEnemies`/`nameplateShowFriends`, the only nameplate CVars this
client had, because 1.12 has none at all.
Seventeen rows registered. Sixteen are live: friendly players, friendly NPCs,
hostile players, and each side's pets/guardians/totems/minions — eight names on
the friendly side and four on the hostile one, each side driving one field,
because a 1.12 object update carries an owner and not a kind of owner and an
addon writes the whole set together. `nameplateMaxDistance` joins
`NameplateRange` and `NP_NameplateDistance` as a third name for one reach.
All default "1", the least-restrictive value, for the reason `NameplateRange`
gives: the two masters already decide whether plates show at all, and a
refinement shipped off would take away plates a player has today. Paired
against `VPlateMode::default()` in the defaults test, the pairing the
derived-Default trap forced on `occlusion`.
Five are registered and inert, each saying so on its own row and in the orphan
test's list: `nameplateShowAll` (1.12 has no in-combat-only mode),
`nameplateShowSelf` (no plate over the player),
`nameplateShowOnlyNameForFriendlyPlayerUnits` and
`nameplateForceShowUnitName` (no such plate mode here), and
`nameplateShowEnemyMinus` (the plate path has no creature rank).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
d39d3ec5cf