HelloRangeDisplay
v0.1.0 (2026-07-25)
Full Changelog Previous Releases
- Add in-game icon and set the addon category
IconTexture points at a 64x64 Icon.png downscaled from the 1254x1254
project image, which is what the client draws beside the addon in the
AddOns list. Same split as HelloBuffCap: the large image is for the
CurseForge listing and is excluded from the packaged zip, Icon.png is not
excluded because the TOC references it and it has to ship.
Category: Combat — the same string ThreatClassic2 and three other addons
on this client use, so it lands in an existing group rather than creating
a near-duplicate one.
The project image also picked up a .pkgmeta rule it was missing: at 2.1 MB
it is larger than the rest of the addon put together and the client never
reads it.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com - Add CurseForge project ID
Project ID 1624157 in the TOC, which is what the BigWigs packager needs to
target the CurseForge upload.
That upload still no-ops until a CF_API_KEY repo secret exists; the GitHub
Release half of the workflow works either way, so a missing key looks like
success rather than a failed upload. Noted in DESIGN.md.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com - Use one description everywhere
"See how far away your target is, in colours that mean something for your
class." — the TOC Notes and the options panel subtitle now say the same
thing as the GitHub repo description.
The old TOC line named the units it covers, which is neither what the addon
is for nor what distinguishes it. Deriving the colour bands per class is.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com - Initial commit — estimated range display for Classic Era 1.15.9
Replaces RangeDisplay, which broke on 1.15.9. The failure is in its
dependency rather than in RangeDisplay itself: LibRangeCheck-3.0 registers
LEARNED_SPELL_IN_TAB unconditionally in lib:activate(), the last statement
of the file, and 1.15.9 retired that event. The throw aborts the main
chunk, so the library never installs its handlers and every GetRange()
returns nothing. RangeDisplay pcalls the call and renders an empty string,
so it fails silently. Upstream now guards the same call with
C_EventUtils.IsEventValid; RangeDisplay ships an older copy.
Rewriting rather than patching drops ten bundled libraries (7,703 lines), a
separate load-on-demand options addon, and ~3,600 lines of static range
tables covering every expansion at once.
Range is bracketed, never measured: collect every "is this unit within N
yards" test the character can perform, sort by range, binary-search the
boundary. Two adjacent checkers bound the answer.
Notable differences from RangeDisplay's model, each documented in DESIGN.md:- No spell yardage is hard-coded. Ranges come from the client at build
time, so talents that move them and every SoD rune are handled without a
data update. LibRangeCheck needs a library release per rune. - Spells are classified by the client (IsSpellHarmful / IsSpellHelpful),
with hand-written hint tables only as a floor. - Colour bands are derived per character rather than configured: amber
below your longest attack's minimum, green comfortably in range, gold at
the edge, red out of reach. Melee classes band against melee, druids by
shapeshift form, shamans by talent tab. RangeDisplay ships six
configurable colour sections per unit, which are the same yardages for
every class and so wrong for most of them. - Focus, arena and pet readouts are gone: the first two don't exist on this
client, and the pet one only ever answered "can I still heal my pet".
Four settings survive: enabled, locked, scale, followCursor.
Three classes of checker would answer "no" forever if left in a list, and
IsSpellInRange returns nil rather than false for them, so the binary search
reads it as out of range and nothing errors — a party member standing next
to you reads 30 - 45. Resurrection and pet-only spells are pulled into
their own lists; passives are excluded outright.
Verified against a live client via /hrd dump, which writes diagnostics to
saved variables because the chat window can't be copied from. That caught
two bugs no amount of reading could: C_Spell.GetSpellInfo reports maxRange
0 for every spell on 1.15.9 — collapsing every caster to a 2-yard melee
character — and GetSpellBookItemInfo's isPassive doesn't exclude passives.
Both now read the legacy global and C_Spell.IsSpellPassive respectively.
Tests.lua runs the engine outside the game under plain lua against a
stubbed API: 892 checks over eight simulated characters, asserting both
specific brackets and the invariant that the reported bracket contains the
true distance at every half-yard from 0 to 60. Not in the TOC.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
- No spell yardage is hard-coded. Ranges come from the client at build