Source: every #OBJECTS block in the 58 files listed in area/area.lst, parsed directly from the area files (not via a running server). Armor AC values use this codebase's fread_flag() encoding, which accepts either plain decimal or a letter-sum bitfield (e.g. CE = C(4)+E(16) = 20) depending on which tool last saved the file — both are decoded to the same integer here.
Correction from the first pass of this report: the original total (1,728) was inflated by a regex boundary bug — 4 files with a genuinely empty #OBJECTS section (immort.are, mobfact.are, ofcol.are, quifael.are) let room/mobile data bleed in as phantom objects (65 of them, all landing in "not wearable" since room/mobile data doesn't match a real wear-flag pattern). Fixed by anchoring the section terminator to line-start instead of requiring an adjacent newline. Every real wear-location count from the first pass was already correct except the not-wearable bucket (496 → 439) and the total (1,728 → 1,663).
item_type = light objects (32 total, e.g. the rainbow staff) carry no wear-location flag at all — wear_obj() (act_obj.c:2180) special-cases them straight into the dedicated Light slot ahead of any flag check, which is why they get their own tab here instead of folding into Hold.
Second correction: armor AC values use fread_flag()'s letter-bitsum encoding (A=20 ... Z=225 , a=226 ... z=251 ), but the engine stores the result in a 32-bit int value[5] (merc.h). Some area files deliberately choose a letter combination whose bitsum overflows that 32-bit int and wraps around to a negative number — e.g. sesamest.are's banana (vnum 24025) encodes −3 vs. magic as ACDEFGHIJKLMNOPQRSTUVWXYZabcdef, whose raw bitsum is 232 −3. The first version of this report didn't emulate that truncation and read it as a huge positive AC instead, which is why the Head tab briefly showed the banana as a wild outlier. Fixed by reproducing the same 32-bit signed wraparound the engine itself does at parse time.