Paying bounty to guards triggers EVENT_INVENTORY_SINGLE_SLOT_UPDATE for all items

[thifi]

Whenever you have a bounty on you, a guard catches you and you decide to pay, an EVENT_INVENTORY_SINGLE_SLOT_UPDATE event is triggered for each and every slot in your backpack with updateReason 0. So it is completely indistinguishable from normal update events.

Things i found:

1. EVENT_INVENTORY_SINGLE_SLOT_UPDATE isn't fired with a justice system related updateReason.
2. There is no START and END event for guard interactions.

Did anyone manage to get around this? Or any ideas how to get around?

Thanks,

[QuadroTony]

the same here

http://www.esoui.com/forums/showthread.php?t=4400

[thifi]

It took me hours to figure out a solution to the problem and it's very hacky but until there is a proper solution from ZOS i think i'll leave it this way.

1. I subscribed to EVENT_CHATTER_BEGIN and disabled my inventory update function
2. I subscribed to EVENT_CHATTER_END and reenabled it (and triggered a force refresh to make sure quest item receives are counted)
3. Entering combat -> disable
4. Leaving combat -> enable

There are two things can happen with you if the guard catches you:

1. You pay: thankfully EVENT_CHATTER_END fires after all the inventory updates happen, so we're good here.
2. You refuse to pay and get away with it or die trying (and dying triggers a full inventory update if you have stolen goods in your inventory):
   - first EVENT_CHATTER_END fires (makes it enabled)
   - then you enter combat (so gets disabled right after)
   - (if you die, inventory full update happens here)
   - leave combat (gets enabled)

This way it seemed to work in all scenarios.

The proper solution would be to implement a new updateReason in EVENT_INVENTORY_SINGLE_SLOT_UPDATE, e.g.: INVENTORY_UPDATE_REASON_ITEM_CONFISCATION.

PS: Please share if you have better workaround.

Regards,

[circonian]

Originally Posted by thifi You pay: thankfully EVENT_CHATTER_END fires after all the inventory updates happen, so we're good here.

I didn't check the chatter, since the inventory is done updating before the chatter ends you could set a flag to prevent your code from running when the chatter starts & turn it off when the chatter ends:

local dontRunCodeFlag = false
local function OnChatterBegin( eventCode, optionCount) 
    local _, optionType = GetChatterOption(1) 
    if optionType == CHATTER_TALK_CHOICE_PAY_BOUNTY then
        -- do whatever
        dontRunCodeFlag = true
    end
end
local function OnChatterEnd()
    dontRunCodeFlag = false
end

Originally Posted by thifi It took me hours to figure out a solution to the problem and it's very hacky but until there is a proper solution from ZOS i think i'll leave it this way. I subscribed to EVENT_CHATTER_BEGIN and disabled my inventory update function I subscribed to EVENT_CHATTER_END and reenabled it (and triggered a force refresh to make sure quest item receives are counted)

Notice if you check the optionType, you wont have to worry about forcing a refresh for quest items because the flag will only be on (that prevents your code from running) if its chatter for paying the bounty.

Originally Posted by thifi Entering combat -> disable Leaving combat -> enable

I don't know what your doing this for, but what if they loot items while in combat? I do it all of the time, will that cause you problems?

[merlight]

Originally Posted by thifi The proper solution would be to implement a new updateReason in EVENT_INVENTORY_SINGLE_SLOT_UPDATE, e.g.: INVENTORY_UPDATE_REASON_ITEM_CONFISCATION.

May I ask what you're doing on update, and how that would help?

[thifi]

Originally Posted by merlight May I ask what you're doing on update, and how that would help?

I could either ignore the inventory refresh or simply throttle my refresh to be done only once in let's say 500 ms.

[merlight]

Originally Posted by thifi I could either ignore the inventory refresh or simply throttle my refresh to be done only once in let's say 500 ms.

I asked because I was curious what was happening in your handler. I peeked into RB2 and have a few suggestions.

You're scanning the whole inventory (and bank, too?) on every slot update, right? I'd say don't, but from what I understood it'd be really hard. You gather some info about items in inventory, and to do a true single slot update, you'd need to remember what was where during the last scan, so that you can remove it from the appropriate tables when it disappears from the slot. Right?

How about building one more table in InventoryContainer:refresh() to remember what you saw, SeenLinks = {[slotIndex] = itemLink}

Then you could add a function InventoryContainer:refreshSlot(slotIndex), in which you'd first compare the new itemLink with oldLink = SeenLinks[slotIndex] -- if they're equal, you're good, return -- otherwise you can get oldKey = ItemLinks[oldLink] and delete oldLink from ResearchKeys[oldKey]. If I undestand it correctly, you can't remove ItemLinks[oldLink] until ResearchKeys[oldKey] is empty. Then add the new itemLink in the same manner it is done now. It will probably be more difficult to make this work than I'm picturing it, but I think it's not unreal.

By the way, inventory slots are indexed from 0 to bagSize-1, you're 1 off

[thifi]

Originally Posted by merlight I asked because I was curious what was happening in your handler. I peeked into RB2 and have a few suggestions. You're scanning the whole inventory (and bank, too?) on every slot update, right? I'd say don't, but from what I understood it'd be really hard. You gather some info about items in inventory, and to do a true single slot update, you'd need to remember what was where during the last scan, so that you can remove it from the appropriate tables when it disappears from the slot. Right? How about building one more table in InventoryContainer:refresh() to remember what you saw, SeenLinks = {[slotIndex] = itemLink} Then you could add a function InventoryContainer:refreshSlot(slotIndex), in which you'd first compare the new itemLink with oldLink = SeenLinks[slotIndex] -- if they're equal, you're good, return -- otherwise you can get oldKey = ItemLinks[oldLink] and delete oldLink from ResearchKeys[oldKey]. If I undestand it correctly, you can't remove ItemLinks[oldLink] until ResearchKeys[oldKey] is empty. Then add the new itemLink in the same manner it is done now. It will probably be more difficult to make this work than I'm picturing it, but I think it's not unreal.

Yup, correct. I'm not particularly happy with the way it currently works. An item instance ID based solution would much more optimal but i was young i needed the money.

Originally Posted by merlight By the way, inventory slots are indexed from 0 to bagSize-1, you're 1 off

Darn, it was that way in the old one but forgot about it during the rewrite.

Thanks for the feedback.

Regards,