That is very odd. GetItemLink checks the slot for an item, which then generates a link from the id of said item. That the item has an id (as my script shows it does), but doesn't have a name (which code65536 script shows it does not) can only be explained as data corruption.
I love a good mystery, and this one has been very fascinating.That you have us all stumped and invested in your issue is somewhat hilarious and heartwarming.
I love a good mystery, and this one has been very fascinating.
That is very odd. GetItemLink checks the slot for an item, which then generates a link from the id of said item. That the item has an id (as my script shows it does), but doesn't have a name (which @code65536 script shows it does not) can only be explained as data corruption.
As the script @code65536 just gave you also utilizes the slot number then it should destroy the box. If it doesn't then it is possible it's a anonmylous id and that is that is causing the problem. i.e. the id of the item doesn't match the one @code65536 provided - it should. You can check with this. Same script I gave earlier but it outputs the item id:/script for Slot in ZO_IterateBagSlots(BAG_BACKPACK) do local ItemLink = GetItemLink(BAG_BACKPACK, Slot) if ItemLink ~= "" then d(GetItemLinkId(ItemLink)) end end

@Grega I'm curious if this will fix the problem./script for i in ZO_IterateBagSlots(BAG_BACKPACK) do if GetItemId(BAG_BACKPACK, i) == 190167 then DestroyItem(BAG_BACKPACK, i); d(i) end end
This will go through your inventory, find an inventory slot containing item ID 190167 (which is the glorious non-vet FG box), and if it finds it, tries to destroy it and display the slot index at which the phantom item was located.

That is very odd. GetItemLink checks the slot for an item, which then generates a link from the id of said item. That the item has an id (as my script shows it does), but doesn't have a name (which code65536 script shows it does not) can only be explained as data corruption.
- Your code checked all 215 slots, and checked if the slot had an item name.
- Dack's code checked all 215 slots, and checked if the slot had a non-zero count.
- My code looks at the bag cache, which is a list of all the items in the inventory (so it's not checking every inventory slot, at least not directly--that part is done by ZOS's code to generate the bag cache) and grabs the name of the first item. Evidently the code that generates the bag cache is taking the count into consideration since it returned an empty list.
The corruption seems to be the slot getting into a bad state where the count was decremented to 0, but the slot was not cleared, and my hope is that calling DestroyItem on that bad slot will clear it.I love a good mystery, and this one has been very fascinating.That you have us all stumped and invested in your issue is somewhat hilarious and heartwarming.
@ZOS_CouchTato im going to go ahead and close the ticket, @code65536 @Gabriel_H solved this for me - but maybe pass this thread along to that specific team in case other OCD ppl like me find out to have this issue when clearing inventory lol. The not-able-to-be-looted undaunted box was affecting quite a few ppl back in September.