I do occasional dev work on an addon that deals with looting, and I've noticed some odd occurrences since Patch 5.4.2 under one specific scenario: when a player opens an item container from their inventory, sometimes GetLootSourceInfo(slot) will return 'nil' for argument 1 instead of a GUID.

I'm having a lot of difficulty replicating this error though. When I first log in, normally everything works fine. When I try containers that only have money after a few hours, they're fine too. After I loot a container with only an item (or multiple items) after several hours of playing (inevitably triggering whatever causes this bug in the meantime), then all containers forwards will be bugged as described in the first paragraph.

The code I'm using isn't really mine to post otherwise I would, but it's fairly simple. It securely hooks "UseContainerItem" and "UseItemByName". If the function hooked is UseItemByName, it converts the argument from an item link to an item ID. It looks through your bags with a loop to find the first bag_index and slot_index with the same item ID. UseContainerItem natively returns bag_index and slot_index. All of my testing is done by UseContainerItem anyway. Afterwards, it checks the "is_lootable" arg of GetContainerItemInfo. If it is lootable, it looks for the next "LOOT_OPENED" event to fire. When that fires, it looks at GetItemSourceInfo(), and the bug can occur.

Not sure if anyone else has encountered this or not - you would only notice this problem if you had an addon that watched every loot event, and you had extensive debugging code. If you have, it'd be a relief - the only two results on Google are completely unrelated.

Thanks!

P.S. While rapidly clicking boxes to attempt to replicate the bug, I managed some magic. I guess "AoE looting" truly does work for everything: http://i.imgur.com/ZizbwoQ.jpg

GetLootSourceInfo returns the GUID of the corpse in an AOE loot situation and I don't know why it would have a value for a container from your inventory.

It returns a GUID for the containers in your inventory as well. The GUIDs it returns in that case are actually just your own character's GUID with the 'identifier' (middle 6 hex digits) being the number of item containers you have opened since login (000001, 000002, etc).

What would you use this information for? I don't really want the GUID to learn anything from it like you would with other GUIDs. I want the GUID so that if I see the same GUID again this session, I know that the user is looting the same box as they did before (and that I should ignore this loot event's set of data).

Creating a workaround to catch players opening the same box many times in many different situations would be challenging.

I doubt it's really intentional that openable containers in your inventory pass a value where a GUID should be, especially if the behavior is not consistent.

Originally Posted by Simca

Creating a workaround to catch players opening the same box many times in many different situations would be challenging.

Why exactly do you need to keep track of this? You didn't say what your addon does, and neither of the addons you are listed as an author for appear to be related to looting, but I can't imagine it's a common scenario for users to open the same box over and over again without looting its contents.

I doubt it's really intentional that openable containers in your inventory pass a value where a GUID should be, especially if the behavior is not consistent.

Possibly, but it seems like a particularly specific value (number of boxes opened) to be contained within a GUID, so somebody at Blizzard must have at least considered this possibility.

Originally Posted by Phanx

Why exactly do you need to keep track of this? You didn't say what your addon does, and neither of the addons you are listed as an author for appear to be related to looting, but I can't imagine it's a common scenario for users to open the same box over and over again without looting its contents.

Mainly, it's because I just want to cover every base, really. Users always come to me with the most bizarre bugs, and it's usually because they're doing something highly abnormal (that they don't realize is highly abnormal).

I may be able to find an entirely different method of doing what I want for this specific addon, but I was curious about this bug, primarily because if it does exist and the problem is not mine, then it has reprocussions for database sites like Wowhead and WoWDB who most likely use this method of tracking opened containers as well.

Mainly, it's because I just want to cover every base, really. Users always come to me with the most bizarre bugs, and it's usually because they're doing something highly abnormal (that they don't realize is highly abnormal). I may be able to find an entirely different method of doing what I want for this specific addon, ...

Again, without knowing what you want to do it's basically impossible to offer any useful suggestions on how you might solve your problem.

Again, without knowing what you want to do it's basically impossible to offer any useful suggestions on how you might solve your problem.

I intended this thread to be more like "Has anyone seen this bug?" rather than "Help me with my addon!", but it's clear that most people probably haven't seen this bug.

At the very least, this bug is now on Google, and it wasn't before this. Hopefully it helps somebody in the future who comes here from a search engine like I would have.

I'll post back if I find any workaround, if I find that the problem was entirely (or partially) on my end, or if I manage to find the trigger for the bug. Overflow of the 6 hex segment is a potential possibility if they have changed the way those numbers are generated. In Patch 5.4.1, there was a bug with the 'double' variables in Lua overflowing when Blizzard passed massive integer values from C code. This could cause odd results if the game (or in some cases the server) had been running for a long time. I'm not sure how they handled the resolution of that issue, but it could have impacted this in some bizarre way.

The ID seems to persist between sessions so it shouldn't change while you're playing, but of course you'll need to do some testing to make sure.

Also, after some brief testing with a Bag of Shiny Things, the GUID from GetLootSourceInfo is completely unrelated to the player's GUID (0x4480000418D9CC0B for the bag and 0x0480000002D6F631 for the player). It's also not the GUID of the unit that gave me the item as a quest reward, so I'm not sure what it represents.

It's possible the containers you were checking were created by the player and retained that information for a while before being discarded by the server.

The ID seems to persist between sessions so it shouldn't change while you're playing, but of course you'll need to do some testing to make sure.

Also, after some brief testing with a Bag of Shiny Things, the GUID from GetLootSourceInfo is completely unrelated to the player's GUID (0x4480000418D9CC0B for the bag and 0x0480000002D6F631 for the player). It's also not the GUID of the unit that gave me the item as a quest reward, so I'm not sure what it represents.

It's possible the containers you were checking were created by the player and retained that information for a while before being discarded by the server.

Interesting. I never actually checked the GUID against my own character's GUID - I just made the assumption because the third hex digit of both GUID is '8', which when you apply the proper bit mask is the identifier for 'players'.

I assumed this meant that you were just 'looting yourself' since you owned the bag. It seemed like the kind of simple workaround that Blizzard would use for an edge case scenario like this.

Also, items have a unique identifier built into the item links?! Mind = blown. Hero!

Edit: Looking on WoWProgramming, they list the field for uniqueID as 'optional' and say that the WoW server uses it for 'some items'. Any idea how extensive this use is?

The unique ID field is mentioned on the itemString page on wowpedia with some theories about how it works and what it represents.

From my own observances it seems to be capable of identifying a particular stack of cloth in my inventory as it's moved around with a clearly distinct ID from other stacks. Splitting the stack results in 2 stacks with the same ID and dropping new items onto an existing stack kept the existing stack's ID.

As long as the containers aren't stackable I doubt any two will have the same ID, and I don't think any containers that produce a loot window can be stacked. Clams can be stacked but simply dump their contents into your inventory when clicked.

I have a feeling that containers will all have a unique ID because of their unique contents, but I really can't say definitively.

If all else fails, it should be possible to uniquely identify an item by its slot if you keep track of what's in every inventory slot and compare it to the previous entries every time it's updated.

For example, if I know which slots are containers and I loot a new container that's identical to an existing one, I can still tell the difference between them because the new one is in a different slot than the existing one.

When the bag update event fires I can check my table of known container slots to see if any are missing, then check the rest of the inventory slots to see if it's been moved (same container that's missing is in another slot) or destroyed (no other slots contain the missing container).

The unique ID field is mentioned on the itemString page on wowpedia with some theories about how it works and what it represents.

From my own observances it seems to be capable of identifying a particular stack of cloth in my inventory as it's moved around with a clearly distinct ID from other stacks. Splitting the stack results in 2 stacks with the same ID and dropping new items onto an existing stack kept the existing stack's ID.

As long as the containers aren't stackable I doubt any two will have the same ID, and I don't think any containers that produce a loot window can be stacked. Clams can be stacked but simply dump their contents into your inventory when clicked.

I have a feeling that containers will all have a unique ID because of their unique contents, but I really can't say definitively.

Still, this is great. I don't have to entirely abandon the way I currently do it by GUID; I can set up code to always track the unique IDs (which will only take one additional table and one additional API command - not a big performance hit at all). Then, I can always look for the bug (if this is a locked item, we're looting it, and the GUID entry is blank, then...), and if it exists, I can fall back onto the unique ID system.

Even if the unique ID system isn't 100% present on every item, it will be accurate enough to cover these edge cases.

To the user, nothing really will seem amiss except for a split second (could be extremely small window at low latency) where the window will be blank.

This behavior may not be limited to items either. Because of my reliance on the GUID, the addon can account for 'weird' scenarios for objects and NPCs by extracting the objectID or NPCID from the GUID (so it will fail on the first LOOT_OPENED, but LOOT_OPENED #2 will process successfully because it can reconstruct the preset variables, even though they were reset by the first event). Since item container GUIDs do not contain the itemID of the container, my code there is different and is only able to fire on the first LOOT_OPENED event, which is why I had a problem because I never expected a bug which caused 'blank' duplicate events.

I would assume LOOT_OPENED might fire for every corpse in range for AOE loot when it populates the window with their items.

It could very well fire simply from opening the loot window and again when it's populated.

If you know it has the potential to fire multiple times you'll just have to code around that.

Yes, I should able to just use the 'backup' system that reconstructs NPCID/objectID and other variables from GUIDs for NPCs and objects, in a slightly modified form. Though you can't get the itemID of the container from the GUID, the item container will be 'locked' because it is in use, so the addon could scan the inventory for the locked item and get the itemID from that.

Still, I should make a bug report thread about this on the official forums now that I know what is happening (even if I don't know why).