BazBags

069 (2026-05-02)

Full Changelog Previous Releases

• Categories: lock Other as a protected catch-all + decouple Match Priority from display order. Two related changes that fall out of the same conversation about handling rule conflicts cleanly. Other was the load-bearing fallback for any item that didn't match another category's rules; if a user deleted it, hid it, or accidentally added rules to it, items the classifier couldn't place would silently disappear from the bag panel. Marking it isProtected makes Delete / SetHidden / AddTag / UpdateTag / RemoveTag / SetMatchMode / ResetTagsToDefault refuse on it, EnsureDefaults re-creates it on every login if it's somehow missing, and the detail page hides the Match Rules section + the Delete section + the Hide-from-bag toggle (rename and reorder still work since those are cosmetic). The category list shows a grey "(catch-all)" suffix on protected entries so the protection is discoverable. Match Priority is the second piece: every category now carries a matchPriority field independent of its display order. Lower numbers match first. Defaults ship with priorities matching their factory display order (Equipment 10, Consumables 20, ... Other 999) EXCEPT Junk which sits at display order 50 but gets matchPriority 5 - that preserves the old "grey items always go to Junk" behaviour without needing the special-case quality=0 shortcut Classify used to have. Custom categories get matchPriority = display order at creation, which keeps "what you see at the top matches first" behaviour for users who don't touch Priority. Users who want a category to live at the bottom of the bag visually but still claim items before broader rules above it can drop its Priority via a numeric range slider in the new Match Priority section on every category's detail page. Classify now walks Categories.GetByMatchPriority() (priority asc with stable tie-break on order then key) instead of Categories.GetAll(). Existing installs get matchPriority backfilled from their order field on first load post-update so behaviour stays identical until the user explicitly changes it, bump to 069