BuffBoard-0.45.1.zip
What's new
Changelog
0.45.1
Fixed
A pet's class is now asked for rather than assumed. The record copied the owner's class, which filed every hunter pet under HUNTER. Now, it does not do that: it calls UnitClassBase on the pet's own unit and files it under whatever comes back, which in practice is not the owner's class — which is why pets are seen under warrior blessings there.
That distinction is the whole thing. Whichever class the game says a pet shares is the class whose Greater Blessing actually reaches it, so filing it elsewhere tallies the pet against a blessing that never lands on it and leaves a count that cannot clear.
BuffBoard now makes the call, so the result is validated against the classes the addon renders — a token outside that list would file the pet into a column that does not exist, making it invisible rather than merely misplaced — and falls back to the owner's class only if nothing usable comes back.
The previous entry claimed this was already correct on the strength of reading petsShareBaseClass. That flag governs whether pets get their own PET column, not which class they are filed under, and reading it as the latter was wrong.
Changed
/bb petsnow prints what the pet is filed under, whatUnitClassBaseandUnitClasseach return, and the owner's class, so the four can be compared directly.
0.45.0
Verified
Pets belong under their owner's class, and BuffBoard already had this right. It carries a petsShareBaseClass flag, true for TBC and Wrath and false for Classic era: on Classic a pet gets its own PET class column, and on TBC it keeps UnitClassBase, which returns the owner's class. Its own option tooltip says pets "appear under the respective class they share Greater Blessings with", and the branch that skips pets when auto-buffing is guarded by not petsShareBaseClass — so on TBC pets are blessed as part of their owner's class.
A hunter pet under HUNTER is therefore correct for this expansion, and a pet without the class blessing is a real gap rather than a display error.
Added
Show pets, under Display, on by default. Off ignores pets entirely, for raids that would rather not spend reagents on them.
Pets that cannot or should not be blessed are excluded: a phase-shifted imp cannot receive anything, and a succubus is usually kept for Demonic Sacrifice rather than to fight. Water Elementals and Shadowfiends are excluded on the same grounds. Hunter pets have no such case.
Fixed
- Five settings tooltips had never been translated and showed English on a Chinese client. The translation check could not see them: they are passed as a bare argument and translated inside the helper, rather than wrapped at the call site. It now reads them, and distinguishes prose from the identifier arguments that sit in the same position.
0.44.1
Added
/bb petsreports, for every pet in the roster, what class the addon has filed it under, what class the game reports for it, its creature family, and which tracked buffs are on it right now. Added because whether a pet belongs under its owner's class depends on a game mechanic worth confirming rather than reasoning about.
0.44.0
Fixed
Pets resolved to their owners everywhere a name was looked up. A pet's roster key is <owner>-pet, and nearly every lookup shortens a name first to strip a realm suffix — but ShortName cannot tell -pet from -Realm, so it returned the hunter and the pet's own record was never found.
That one mismatch produced several symptoms:
- The exception picker listed pets by their bare name, so a hunter and their pet were two entries in the same class list with nothing to tell them apart. Pets now carry their owner there, as they already did in the duty picker.
- Exception chips took their class colour and state from the owner.
MissingForPlayermeasured the owner's auras for a pet exception, so a pet pinned to a blessing reported the hunter's coverage as its own.- The PLAYER axis did the same for duties aimed at a pet.
- Pruning kept or dropped a pet's exception according to whether its owner was still in the group.
Lookups that may receive either kind of name now go through Roster:Find, which tries the full key before shortening. ShortName is unchanged: teaching it about pets would mean guessing whether a suffix is a realm, and a realm called "pet" is likelier than a reliable rule.
Lookups that can only ever receive a player — a message sender, an assignment owner, yourself — were left alone.
0.43.1
Fixed
- The icon shape note in the settings panel had no translation, so it showed English on a Chinese client.
- The hardcoded version in
Core.luastill read 0.37.0. It is a fallback used only when the addon metadata API is unavailable, so the addon reported its version correctly in practice, but the two should not disagree.
0.43.0
Added
Hunter pets are scanned and tracked. A hunter's pet joins the roster as a record of its owner's class, which is exactly enough to make everything else follow: the class-wide blessing tally counts it, a bare or expiring pet lights the class button, the lesser-rank right-click aims at the pet when the pet is the one missing (players sort ahead, so a player gap always wins the aim), and UNIT_AURA on pet tokens updates it as promptly as a player. UNIT_PET rebuilds the roster, so a fresh summon is seen within a second rather than at the next unrelated roster event.
What pets deliberately do NOT join: group prayers (they do not land on pets, and the count could never clear), provider columns, and the class headcount -- "Hunters: 3" still means three hunters. The greater rank is never aimed at a pet. State is keyed "<owner>-pet" rather than the pet's own name, which collides with player names and changes on a whim, while one hunter has one pet slot.
Pets appear in the player picker for duties and exceptions, labelled with their owner, so a specific pet can be pinned to a blessing like anyone else. Warlock pets are deliberately excluded -- sacrifice and resummon churn would keep a phantom on the bar -- and adding a class to PET_CLASSES in Roster.lua is the whole job if that ever changes.
0.42.1
Fixed
Individual exceptions now honour the refresh cushion. A member pinned to their own blessing was invisible to it entirely: the class-wide tally correctly excludes them, and the exception task tested only "has it fallen off yet" -- so as their blessing ran down, nothing anywhere said so until it was already gone, which is the one moment the cushion exists to get ahead of. Plainly visible next to any addon showing raw member timers: theirs read 2:02, the bar read nothing.
The exception loop now reads the expiring count and soonest time that MissingForPlayer was already returning, so a pinned member inside the cushion puts their button on the bar with the same amber countdown a class-wide cast gets. The board's exception chips speak the same language: red ! for a gap, amber countdown inside the cushion, quiet when covered.
This gap has existed since exceptions became their own buttons -- it is not fallout from the reverted releases -- which is why the bar disagreed with per-member timers on every version.
0.42.0
Changed
Reverted 0.40.0 through 0.41.1. In the field, buffs stopped updating as they approached expiry and greater blessings failed to appear when missing. Those releases contained an optimization pass (cached bag scans, skip-keyed bar refreshes, per-pass board tally memoisation) and a scan-state change on roster events; rather than debug which of them is at fault, the scanning, refresh and display code is restored wholesale to 0.39.0, which is known good. The version number moves forward so this release supersedes any installed copy of the reverted ones.
Knock-on worth knowing: the roster-event flash fixed in 0.41.1 -- the full bar appearing for half a second whenever somebody zoned -- returns with this revert, since its fix rode on the reverted scan change.
Rounded remains the default icon theme. Re-applied on top of the 0.39.0 baseline as the one survivor of the reverted range: it is a stored default and four nil-fallbacks, touches no scanning or refresh logic, and was an explicitly requested change rather than part of the optimization pass.
0.39.0
Added
A third icon theme: Rounded. Square icons with rounded corners, sitting between the untouched square Default and the fully circular theme. The circle has no stock rounded-square equivalent in the client files, so this one ships as a small antialiased mask in the addon's art folder; the same rules apply as before — any spell icon works, and the border colour and thickness settings bend to follow the shape.
Changed
The circular theme is now called "Round". With a rounded-square theme in the family, "Rounded" describing a circle stopped making sense. The saved- variable key moved with the label: a 0.38 profile that had picked the circle comes back as the rounded square and needs one click in the settings to restore. Accepted, over shipping a key that disagrees with its label forever.
The status strip is gone from the action bar. The thin coloured line along the bottom of each icon was the last remnant of the old four-ways-at-once status display. With it gone, state on the bar is carried by the badge — whose colour still distinguishes red missing count, amber countdown, blue create step and so on; the missing count itself is now drawn red, so nothing was lost with the strip — plus desaturation for finished work and the tooltip for the full story. The assignment board keeps its strips and state borders unchanged.
0.38.0
Added
Icon themes. A new Icons chooser sits in the settings panel next to the colour presets, with two shapes for the action bar's icons:
- Default — square, exactly as before.
- Rounded — circular icons, cut with mask textures rather than pre-baked artwork, so every spell icon works and the existing border settings still apply: the inset ring simply becomes a circular ring in your chosen colour and thickness. The cooldown swipe, hover highlight and status strip are cut to the same circle.
The theme applies to the bar and its previews only. The assignment board is a dense grid where circles would waste a third of every cell, so it stays square.
Also available as /bb icons default|rounded.
Changed
No more red/green frames on the action bar's icons. Status on the bar was being said four ways at once — the coloured frame, the status strip along the bottom edge, the badge count, and desaturation when the work is done — and the frame made the bar the loudest thing on screen. The frame is gone from the bar; the other three carry the state, unchanged.
The assignment board is untouched: its cells keep their coloured state borders, which is where a wall of identical cells genuinely needs them to say which buffs are assigned and covered.
This mod has no additional files

