Label every bag with the type it really is - #24
Open
uga wants to merge 2 commits into
Open
Conversation
A user reported that Altoholic does not recognise some of the higher-end bags, the Satchel of Cenarius (a 24-slot herb bag) among them. It turned out that no bag type was ever resolved correctly, and that the ones which did show a type were showing the wrong one: a warlock's Soul Pouch was labelled "(Ammo Pouch)", while a hunter's Quickdraw Quiver got no label at all. ScanBag saves the item family as a bit index, because the field is only 5 bits wide and the raw family of a mining bag (1024) would never fit: if bagType and bagType > 0 then bagType = Log2(bagType) end but bagTypeStrings was keyed on the raw family instead: [4] = ... -- "Soul Bag", [32] = ... -- "Herb Bag" so the lookup in _GetContainerInfo could only ever match by accident. A soul bag saved 2 and picked up "Ammo Pouch", an inscription bag saved 4 and picked up "Soul Bag", and every other type saved a value the table had no key for, hence no label. Plain bags were fine only because they save a 0 that matches nothing. Key both tables on what ScanBag actually saves. The saved value is now offset by BAG_TYPE_OFFSET, for two reasons: - 0 has to keep meaning "no specific type", but a quiver is family 1, whose Log2 is also 0, so every ordinary bag would become a quiver; - data saved by earlier versions holds the plain Log2, 0 to 10. Placing the new range above it means those values match no key and read as "no type", which is what they already displayed, rather than picking up a wrong label until the character is scanned again. The highest value is now 26, so the 5 bits still hold it and the layout of bag.info is unchanged. Bags are rescanned on any BAG_UPDATE, so each character corrects itself on its next login. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A hunter carrying a full quiver was reported as having eighty-four slots with twenty-one free, sixteen of which were quiver slots that hold nothing but ammunition. A warlock's soul pouch added twenty more of the same kind. The totals were arithmetically right and told the user something that was not true: how much room there is for ordinary things. The bag type is saved correctly now, so the two kinds can be told apart. Bags and bank bags that only take one family of items no longer count towards the totals of either. Nothing is hidden: each bag is still listed in the tooltip with its size, its free slots and, since the type is read properly, its name. A character's totals are rewritten by the scan that runs a few seconds after their next login. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A user reported that Altoholic does not recognise some of the higher-end bags, the Satchel of Cenarius (a 24-slot herb bag) among them. It turned out that no bag type was ever resolved correctly, and that the ones which did show a type were showing the wrong one.
On Classic Era, the "Bags" tooltip of the summary showed a warlock's Soul Pouch as
(Ammo Pouch), while a hunter's Quickdraw Quiver got no label at all.Root cause
ScanBagsaves the item family as a bit index, because the field is only 5 bits wide and the raw family of a mining bag (1024) would never fit:but
bagTypeStringswas keyed on the raw item family instead:so the lookup in
_GetContainerInfocould only ever match by accident:bagTypeStrings[saved]Plain bags were fine only because they save a 0 that matches nothing.
Fix
Both tables are now keyed on what
ScanBagactually saves. The saved value is offset by a newBAG_TYPE_OFFSET, for two reasons:0has to keep meaning "no specific type", but a quiver is family 1, whoseLog2is also 0, so every ordinary bag would otherwise become a quiver;Log2, 0 to 10. Placing the new range above it means those values match no key and read as "no type", which is what they already displayed, rather than picking up a wrong label until the character is scanned again.The highest value is now 26, so the 5 bits still hold it and the layout of
bag.infois unchanged. Bags are rescanned on anyBAG_UPDATE, so each character corrects itself on its next login.Checked with
luac5.1 -p, and with a round-trip harness replicating LibBit64 +ScanBag+_GetContainerInfo: all 11 families come back with the right label, rarity/size/free slots/icon unaffected, and every possible legacy value reads as no type.