fix: visible item stride 2→4 (confirmed from raw field dump)

RAW FIELDS dump shows equipment entries at indices 284, 288, 292, 296, 300
— stride 4, not 2. Each visible item slot occupies 4 fields (entry +
enchant + 2 padding), not 2 as previously assumed.

Field dump evidence:
  [284]=3817(Reinforced Buckler) [288]=3808(Double Mail Boots)
  [292]=3252 [296]=3823 [300]=3845 [312]=3825 [314]=3827

With stride 2, slots 0-18 read indices 284,286,288,290... which interleaves
entries with enchant/padding values, producing mostly zeros for equipment.
With stride 4, slots correctly map to entry-only fields.
This commit is contained in:
Kelsi 2026-03-28 11:04:29 -07:00
parent f70beba07c
commit 05ab9922c4
2 changed files with 22 additions and 5 deletions

View file

@ -3105,6 +3105,22 @@ void InventoryHandler::updateOtherPlayerVisibleItems(uint64_t guid, const std::m
int nonZero = 0;
for (uint32_t e : newEntries) { if (e != 0) nonZero++; }
// Dump raw fields around visible item range to find the correct offset
static bool dumpedOnce = false;
if (!dumpedOnce && fields.size() > 50) {
dumpedOnce = true;
std::string dump;
for (const auto& [idx, val] : fields) {
if (idx >= 270 && idx <= 340 && val != 0) {
char buf[32];
snprintf(buf, sizeof(buf), " [%u]=%u", idx, val);
dump += buf;
}
}
LOG_WARNING("RAW FIELDS 270-340:", dump);
}
if (nonZero > 0) {
LOG_WARNING("updateOtherPlayerVisibleItems: guid=0x", std::hex, guid, std::dec,
" nonZero=", nonZero, " base=", base, " stride=", stride,