nil error Cata

[Hendo72]

Just started getting this NIL error yesterday when i mouseover a slot or a button that references one of the slots.

After checking with Github and doing some test prints, it appears that AutoGearBestItems and info.guid are both nil in this situation.

Seems like the issue was introduced with 2024-06-24-release. Error goes away if I rollback to 2024-06-18-release. Upon further investigation, this error is limited to Cata. Vanilla is not effected.

3x AutoGear/AutoGear.lua:4324: attempt to index global 'AutoGearBestItems' (a nil value)
[string "@AutoGear/AutoGear.lua"]:4324: in function `AutoGearGetBestSetItems'
[string "@AutoGear/AutoGear.lua"]:4419: in function <AutoGear/AutoGear.lua:4383>
[string "=[C]"]: ?
[string "=[C]"]: ?
[string "=[C]"]: ?
[string "=[C]"]: ?
[string "=[C]"]: ?
[string "=[C]"]: ?
[string "=[C]"]: in function `SetAction'
[string "@ElvUI_Libraries/Core/LibActionButton-1.0/LibActionButton-1.0.lua"]:2642: in function `SetTooltip'
[string "@ElvUI_Libraries/Core/LibActionButton-1.0/LibActionButton-1.0.lua"]:2346: in function <...ies/Core/LibActionButton-1.0/LibActionButton-1.0.lua:2338>
[string "@ElvUI_Libraries/Core/LibActionButton-1.0/LibActionButton-1.0.lua"]:1218: in function <...ies/Core/LibActionButton-1.0/LibActionButton-1.0.lua:1216>
[string "=(tail call)"]: ?
[string "=[C]"]: ?

Locals:
info = <table> {
 Intellect = 5
 isGear = true
 isRangedWeapon = 1
 bop = 1
 item = <table> {
 }
 usable = 1
 equipped = false
 shouldShowScoreInTooltip = 1
 validGearSlots = <table> {
 }
 invType = 26
 link = "|cff1eff00|Hitem:57844::::::::46:::::::::|h[Crawling Wand]|h|r"
 rarityColor = <table> {
 }
 numValidGearSlots = 1
 classID = 2
 id = 57844
 rarity = 2
 name = "Crawling Wand"
 DPS = 32.900000
 subclassID = 19
 isWeaponOrOffHand = 1
}
setSlots = <table> {
 1 = 18
}
bestSetScore = 0
bestSet = <table> {
}
lowestBestItemIndex = 0
lowestBestItemScore = 0
bestItem = nil
thisIsABestItem = nil
(for generator) = <function> defined =[C]:-1
(for state) = <table> {
 1 = 18
}
(for control) = 1
i = 1
slot = 18
(*temporary) = nil
(*temporary) = "AutoGearBestItems"
(*temporary) = nil
(*temporary) = "attempt to index global 'AutoGearBestItems' (a nil value)"

[Hendo72]

UPDATE: It wasn't until i started comparing the changes between each release that i realized I have auto-update turned on in Curseforge and I was getting conflicting facts because of it.

This notwithstanding, I still have the error with the new release.

I'm going to start looking into what's causing it.

[AlexFolland]

Thanks for the report and for investigating. I'm out with my family today, so I'll only be able to investigate later tonight, if I'm not too tired from the day out. I'll try my best to solve it soon though.

[Hendo72]

I think i found where the error is kicking...

When i comment out the if statement block at 4416, the error disappears. Your error lies somewhere within that code block.

** I'll keep an eye on your progress while I go back to working on my own Addon.

[AlexFolland]

Does it still happen if you have no other addons enabled, or is it only with ElvUI enabled? The stack trace mentions ElvUI.

I'm expecting there to be no way to not have AutoGearBestItems populated yet at the time of hovering over any item buttons, but I guess it can somehow, even though I haven't seen that happen. I will add a guard for that for now and think about how it could happen.

[AlexFolland]

I've released an update. Do the errors go away, at least? If so, what behavior can you observe with the tooltips? Can you show me with /ag debuginfo on so I can see the maximum amount of information?

[Hendo72]

Everything seems to be working as intended now. To follow up with your earlier question, the old version was throwing the error with and without ElvUI.

I'll give it a couple days to see if it comes back or the fix broke something else. :)

[AlexFolland]

Thanks. Can you please check various item tooltips with /ag debuginfo on and let me know if any information looks unexpected to you?

[Hendo72]

Not seeing anything amiss. I consider this issue resolved.

[AlexFolland]

Well, AutoGearBestItems being nil at that time in the first place is a major issue that I haven't anticipated and still don't understand, so I need to fix that. It should never be nil by the time you're able to view a tooltip.

[Hendo72]

I'm not sure if this is a side effect, but I ran '/ag scan' and I got this: Cool, but none of it was equipped. I still have an open Trinket spot. I ran it twice to see if it was a one-off.

[AlexFolland]

Oh, this is exactly what I need to figure out. There's another issue ticket where other users have reported this behavior, but I still haven't reproduced it on my own character I've been leveling recently. I need as much information as you can give me.

Are you able to /dump AutoGearBestItems[INVSLOT_TRINKET1] and copy the text output with a chat addon like Prat that lets you copy-paste from the chat? Also /dump AutoGearEquippedItems[INVSLOT_TRINKET1] and /dump AutoGearActionQueue might tell me something.

Please do these dumps just after reproducing the issue.

[Hendo72]

Here's your dump. Do you need anything else?

EDIT: It looks a lot better when I'm editing it. Sorry

Dump: value=AutoGearBestItems[INVSLOT_TRINKET1] [1]={ bag=0, score=6.06, slot=11, info={ Intellect=6, isGear=true, guid="Item-4387-0-4000000569DED60A", bop=1, item={ GetItemLocation=, SetItemLink=, HasItemLocation=, LockItem=, itemLocation={ Clear=, IsEquipmentSlot=, IsEqualToBagAndSlot=, SetBagAndSlot=, IsBagAndSlot=, SetEquipmentSlot=, HasAnyLocation=, slotIndex=11, GetEquipmentSlot=, IsEqualToEquipmentSlot=, bagID=0, GetBagAndSlot=, IsEqualTo= }, GetItemID=, IsItemDataCached=, GetInventoryTypeName=, GetCurrentItemLevel=, GetItemQualityColor=, UnlockItem=, Clear=, GetItemIcon=, IsItemLocked=, GetItemLink=, SetItemLocation=, GetItemName=, IsItemInPlayersControl=, GetItemQuality=, GetItemGUID=, GetInventoryType=, IsItemEmpty=, GetStaticBackingItem=, SetItemID=, IsDataEvictable=, ContinueWithCancelOnItemLoad=, ContinueOnItemLoad= }, equipped=false, usable=1, validGearSlots={ [1]=13, [2]=14 }, invType=12, link="|cff1eff00|Hitem:56847::::::::50:::::::::|h[Chelsea's Nightmare]|h|r", rarityColor={ hex="|cff1eff00", r=0.11764706671238, color={ a=1, b=0, g=1, GetRGBA=, IsRGBEqualTo=, SetRGB=, GetRGB=, r=0.11764706671238, GenerateHexColorMarkup=, WrapTextInColorCode=, GenerateHexColor=, IsEqualTo=, OnLoad=, GenerateHexColorNoAlpha=, SetRGBA=, GetRGBAsBytes=, GetRGBAAsBytes= }, g=1, b=0 }, numValidGearSlots=2, classID=4, shouldShowScoreInTooltip=1, Stamina=6, name="Chelsea's Nightmare", rarity=2, subclassID=0, id=56847 } }

[AlexFolland]

Yes, the other 2 dumps I mentioned in my previous comment would be extremely helpful here. This has equipped=false, meaning it should have added an action to the action queue to equip it, and that action should have executed PickupContainerItem(curAction.container, curAction.slot) and EquipCursorItem(curAction.replaceSlot), resulting in the item being equipped. It would be nice to see if the action queue is empty and what the AutoGearEquippedItems has for that slot.

[Hendo72]

Sorry, i didn't see the other two.

This time when I tried to reproduce, it worked as intended.However, as soon as I did a reload, I was able to reproduce it again. Dump: value=AutoGearEquippedItems[INVSLOT_TRINKET1] [1]={ equipped=1, score=0, info={ empty=1, item={ GetItemLocation=, SetItemLink=, HasItemLocation=, LockItem=, itemLocation={ Clear=, IsEquipmentSlot=, IsEqualToBagAndSlot=, equipmentSlotIndex=13, SetBagAndSlot=, IsBagAndSlot=, SetEquipmentSlot=, HasAnyLocation=, GetEquipmentSlot=, IsEqualToEquipmentSlot=, GetBagAndSlot=, IsEqualTo= }, GetItemID=, IsItemDataCached=, GetInventoryTypeName=, GetCurrentItemLevel=, GetItemQualityColor=, UnlockItem=, Clear=, GetItemIcon=, IsItemLocked=, GetItemLink=, SetItemLocation=, GetItemName=, IsItemInPlayersControl=, GetItemQuality=, GetItemGUID=, GetInventoryType=, IsItemEmpty=, GetStaticBackingItem=, SetItemID=, IsDataEvictable=, ContinueWithCancelOnItemLoad=, ContinueOnItemLoad= }, name="nothing" } }

/dump AutoGearActionQueue is too big for the chat window to show.

[AlexFolland]

Thanks for that. I can see that the equipped item is correctly updated as nothing for that slot. Was that true at that time? There was nothing in that slot? If so, the updating of equipped items is working as intended.

However, the fact that AutoGearActionQueue isn't cleared is a problem. It should be executing and emptying the queued actions, including the equip action. I need to see an element in AutoGearActionQueue, and the first element should be fine, so please try /dump AutoGearActionQueue[1] after reproducing the issue. I think that should dump the first element in the table.

[AlexFolland]

This may have given me enough information to reproduce the issue myself, too. I'll try to reload UI with an empty trinket slot but a trinket in my bags, then scan. I'll try that later today when I have time for WoW.

[AlexFolland]

By the way, the reason I'm asking for all this is that I've inspected the whole code path for equipping and there's nothing that looks wrong. I've considered all the logic and can't see anywhere that the logic could go wrong, and haven't reproduced the issue myself. So, your help with these dumps is much-appreciated.

[Hendo72]

I'm out and about right now. I'll see what I can do when I get home in a few hours. I'm looking for a way to show more of my chat. /chatlog doesn't seem to be working. Trying to expand elvui.

[Hendo72]

It seems odd, but when I logged in I was able to run the scan and it equipped my trinket no problem. Reloading caused it to break.

/ag scan AutoGear: [Chelsea's Nightmare] (6.06) was determined to be better than nothing (0.00). Equipping. Dump: value=AutoGearActionQueue[1] [1]={ action="localupdate", t=326789.33 }

[Hendo72]

I'm not sure if this is the same issue that we've been looking into. Previously, we were working with an empty slot. This itime it's a lower grade for a higher grade item.

I just did a /AG scan because I had an item that was showing as an upgrade and it's not swapping the item.

It says it did it, but it didn't.

I even tried manually swapping it and then using AG after I swapped back; still didn't work.

It was working fine on this toon until now.

[AlexFolland]

The BoP warning would have been on-screen there. It's a BoP white item, so you'd have to click the BoP confirmation. There's a setting to have AutoGear confirm the BoP warning though.

https://www.wowhead.com/item=57400/gold-dust-belt

Here's the relevant code for this.

elseif (event == "EQUIP_BIND_CONFIRM") or
(event == "EQUIP_BIND_REFUNDABLE_CONFIRM") or
(event == "EQUIP_BIND_TRADEABLE_CONFIRM") then
    local rarity = Item:CreateFromItemLocation(C_Cursor.GetCursorItem()):GetItemQuality()
    if rarity == nil then return end
    if ((rarity ~= 3) and (rarity ~= 4) and (AutoGearDB.AutoConfirmBinding == true)) or
    ((rarity == 3) and (AutoGearDB.AutoConfirmBindingBlues == true)) or
    ((rarity == 4) and (AutoGearDB.AutoConfirmBindingEpics == true)) then
        EquipPendingItem(arg1)
    end

This basically means that if you enable "Automatically confirm binding for non-blues/non-epics", the BoP warning will be confirmed and the item will be equipped. Do you have that setting enabled?

[Hendo72]

There is no BoP confirmation because it's a quest reward for Gold Dust Exchange.It was working for every other item I've gotten the same way.

[AlexFolland]

Oh yeah, my comment makes no sense now that you mention that. It wouldn't have a binding confirmation on equipping. I'm not sure what I was thinking. How strange.

[AlexFolland]

I can't reproduce this. I don't know why it gets messed up for you, but I haven't been able to reproduce it even once in my questing in the past 2 weeks.

[Hendo72]

I have disabled every addon except AG and Bugsack and I'm getting the same result.

I tried reinstalling and same result.

I even went nuclear and deleted everything with no success.

For some reason, it says it's equipping the items, but it doesn't.

I've tried tracing the code to see what might be stopping it from equipping the items. Save me some time by telling where in the code is the item actually equipped.

[AlexFolland]

It's in AutoGearMain.

PickupContainerItem(curAction.container, curAction.slot)
EquipCursorItem(curAction.replaceSlot)

[Hendo72]

I think I may have stumbled onto something...

I've been in the right area all along. (thanks for confirming.) I'll do some research when I'm done work.

[Hendo72]

Ok here's where we are at... if I run /ag scan when i first start the game, it works properly. If I unequip the items and run the scan again, it will equip them.

If I reload, it stops working until I restart again

I think the issue is AutoGearItemDataIsGenerallyAvailable. When I restart, it's set to 1 and it stays 1. As soon as I reload, it becomes nil and stays nil until I restart again.

As long as AutoGearItemDataIsGenerallyAvailable is nil, it will go through the motions of doing it, but won't actually equip the items.

What causes the "GET_ITEM_INFO_RECEIVED" event to fire? That's the only way AutoGearItemDataIsGenerallyAvailable gets reset to 1.

This seems to have fixed it.

[AlexFolland]

GET_ITEM_INFO_RECEIVED is fired after any GetItemInfo call gets data back from the server. Here's the documentation.

I tried it a few times, and when I reload UI and /dump AutoGearItemDataIsGenerallyAvailable, I see that AutoGearItemDataIsGenerallyAvailable is 1 every time. That being said, It's possible I have some other addon that calls GetItemInfo and I've been relying on it without realizing it. I purposely avoid calling GetItemInfo in AutoGear since it's not instant if the item is not yet cached and causes a server call every time it's called. Thanks for identifying this. I'm going to refactor AutoGear in a way that it doesn't rely on this to determine initialization readiness.

[AlexFolland]

I did that and committed. Would you mind testing with the latest commit?

[Hendo72]

It's working now, even after a reload.

These error messages in chat are just because I have debug turned on?

[AlexFolland]

Looks like my logic for displaying that message was incorrect, so that message was just wrong. I've fixed that in the new latest commit. Thanks for pointing that out.

By the way, the reason you were able to see that message at all even though its logic was incorrect was because you have AutoGear's logging verbosity set to 3 ("debug" level), which makes sense if you're figuring out issues. You can set /ag verbosity 1 to make AutoGear less verbose if you want, at least until you see something super messed up again.

If the issues are resolved for you after your next test result, I'll close this and tag a release. So, I'm eagerly awaiting your next message. Thanks for all your help with this stuff.

[Hendo72]

Not a problem. I appreciate your addon.

Good to flex my skills once in a while.

The boss at WoWPro is pretty good at fixing things before I get to it.

[AlexFolland]

There's no test result in your comment, but you sound positive, so I'm closing this. Please let me know if there are still issues either here or in a new ticket. Thanks again for your help.