3 hours to track down the CTD

[merlight]

I got a bit lost. Could someone please explain the whole guard interaction to me? They don't break your skull like they say they would, if you broke the law?

So the problem is with add-ons doing stuff on inventory slot/full update? Some ideas:

* Use SHARED_INVENTORY

-- these are called upon SINGLE slot and FULL update
("SlotRemoved", bagId, slotIndex, existingSlotData)
("SlotAdded", bagId, slotIndex, slotData)
("SlotUpdated", bagId, slotIndex, slotData)
 
-- this is called upon SINGLE slot update
("SingleSlotInventoryUpdate", bagId, slotIndex)
-- the callback doesn't include slotData, you can get it like this:
local slotData = SHARED_INVENTORY:GenerateSingleSlotData(bagId, slotIndex)
 
-- this is called upon FULL update with BAG_BACKPACK and BAG_WORN,
-- and also upon guild bank events with BAG_GUILDBANK (twice?! must test)
("FullInventoryUpdate", bagId)
-- you can scan the whole bag like this:
local bagCache = SHARED_INVENTORY:GenerateFullSlotData(nil, bagId)
for slotIndex, slotData in pairs(bagCache) do ...

* Add-ons tinkering with items, e.g. junkers, should IMO never, ever, do that in response to full update. This includes SHARED_INVENTORY's SlotAdded/Updated callbacks. If you want to implement forced re-scan feature, add a button, or a keybind, or a slash command.

* If you need to do something upon full backpack update, maybe you could delay that until out of certain scenes:

local blacklist = { interact = true }
local needUpdate = false
 
local function doUpdate()
  needUpdate = false
  ...
end
 
local function canUpdate()
  local scene = SCENE_MANAGER:GetCurrentScene()
  return not scene or not blacklist[scene:GetName()]
end
 
EVENT_MANAGER:RegisterForEvent("junker", EVENT_INVENTORY_FULL_UPDATE,
function()
  if canUpdate() then
    doUpdate()
  else
    needUpdate = true
  end
end)
 
SCENE_MANAGER:RegisterCallback("SceneStateChanged",
function(scene, oldState, newState)
  if needUpdate and canUpdate() then
    doUpdate()
  end
end)

[circonian]

Originally Posted by merlight I got a bit lost. Could someone please explain the whole guard interaction to me? They don't break your skull like they say they would, if you broke the law?

If you commit a crime you gain infamy. If you then walk up to a guard, while you have infamy, they will run up to you and start a conversation. It will give you two options: (1) to pay your bounty and clear your infamy, (2) To attempt to run off and get away from the guards. If you choose this option they will chase & attack you.

If you keep committing crimes and get enough infamy the guards will KOS, Kill you On Sight. They will not give you any chance to pay a bounty.

Originally Posted by merlight So the problem is with add-ons doing stuff on inventory slot/full update?

Yes, when you pay the bounty (IF you have any stolen items on you) it does a full update and firing singlSlotUpdate event for all of your inv slots where lots of addons run code. So everyone ends up running a lot of code on every slot in all of the inventories.

Originally Posted by merlight If you need to do something upon full backpack update, maybe you could delay that until out of certain scenes:

I can't double check it right now, but I'm pretty sure I tried this. I don't think there was any special scene for it. It was just the normal HUD_SCENE. So that wouldn't help them know when they get caught or when the updating ends.

[sirinsidiator]

I updated AGS just now. Maybe you can try if the crash still persists.

[merlight]

Originally Posted by circonian There is no event & no "specific" InteractionType for it, and we don't have access to any of that code.

Found these, are they actually used?
INTERACTION_PAY_BOUNTY
CHATTER_START_PAY_BOUNTY
CHATTER_TALK_CHOICE_PAY_BOUNTY
CHATTER_END_PAY_BOUNTY

(not saying checking this in order to skip updates is not crazy, just spilling findings )

[circonian]

Originally Posted by merlight Found these, are they actually used? INTERACTION_PAY_BOUNTY CHATTER_START_PAY_BOUNTY CHATTER_TALK_CHOICE_PAY_BOUNTY CHATTER_END_PAY_BOUNTY

I looked for INTERACTION_BOUNTY, didn't think to look for PAY_BOUNTY. But no the interaction type doesn't look like its used. When paying a bounty it does not show up.
INTERACTION_PAY_BOUNTY = 30

and GetInteractionType() returns only 14 INTERACTION_CONVERSATION

I didn't think of looking at the chatter types, they look like they are in use, doing something like pre-hooking

function ZO_SharedInteraction:HandleChatterOptionClicked(label)
-- and checking if  label.optionType == CHATTER_TALK_CHOICE_PAY_BOUNTY

Originally Posted by merlight (not saying checking this in order to skip updates is not crazy, just spilling findings )

Agreed, I don't need it. Someone asked if there was a way to know when you get caught or pay a bounty I was just trying to throw out some ideas.

[thifi]

I found a very-very-very temporary solution to the problem. I'm not too proud of it, but at least seems to be working: http://www.esoui.com/forums/showpost...76&postcount=3

[ZOS_ChipHilseberg]

I've been following this thread and trying to get a clear picture of the problem but I have a few questions. What kind of crash are we talking about? Is it an actual client crash (the kind that generates a bug report) or is it a client lockup? Also, am I right in saying that the leading theory is that there are a bunch of spurious inventory updates that are causing "too much" addon processing when you are killed by a guard?

[thifi]

Originally Posted by ZOS_ChipHilseberg I've been following this thread and trying to get a clear picture of the problem but I have a few questions. What kind of crash are we talking about? Is it an actual client crash (the kind that generates a bug report) or is it a client lockup? Also, am I right in saying that the leading theory is that there are a bunch of spurious inventory updates that are causing "too much" addon processing when you are killed by a guard?

So far what I've learnt is below.

Issue: Whenever you pay a bounty or get killed by a guard and you have stolen items in your inventory, then the client triggers an EVENT_INVENTORY_FULL_UPDATE followed by an EVENT_INVENTORY_SINGLE_SLOT_UPDATE for all items in your inventory. This cause several addons to start extremely intensive processing which may lead to a client lockup for 5-30 seconds, on several occasions a complete client crash.

Several ideas how can this be solved:

1. Do not fire an inventory update for all items, only for the confiscated items
2. Use a separate updateReason on the inventory update events (FULL/SINGLE_SLOT) to allow addons to distinguish between item sells and confiscation.
3. Make sure the game API uses the below constants in a way their name suggests:

INTERACTION_PAY_BOUNTY
CHATTER_START_PAY_BOUNTY
CHATTER_TALK_CHOICE_PAY_BOUNTY
CHATTER_END_PAY_BOUNTY

Currently when the guard approaches you GetInteractionType returns 14 instead of 30 so we cannot tell whether it's a normal NPC conversation or a pay bounty dialog.

I believe the combination of all the above would be the best.

PS: Now that we have ZOS folks among us I will describe a fully reproducible client crash with GetTradingHouseSearchResultItemLink (if someone haven't done it already) . Maybe it will now get a proper attention, because my ingame bug report was just bouncing off customer support.

Regards,

[QuadroTony]

Originally Posted by ZOS_ChipHilseberg I've been following this thread and trying to get a clear picture of the problem but I have a few questions. What kind of crash are we talking about? Is it an actual client crash (the kind that generates a bug report)

this
with generating bug reprot window

[sirinsidiator]

Originally Posted by thifi Now that we have ZOS folks among us I will describe a fully reproducible client crash with GetTradingHouseSearchResultItemLink (if someone haven't done it already) . Maybe it will now get a proper attention, because my ingame bug report was just bouncing off customer support.

I already wrote about how to reproduce that amongst some other crashes in this thread month ago.

FormatAchievementLinkTimestamp crashes when called with a negative number GetTradingHouseSearchResultItemInfo, GetTradingHouseSearchResultItemLink and SelectTitle crash when called with an invalid index ZO_DeepTableCopy turns into an infinite loop when passed a table that contains a reference to itself Many functions that expect a control element crash when they get empty/invalid userdata instead.

[circonian]

Originally Posted by ZOS_ChipHilseberg I've been following this thread and trying to get a clear picture of the problem but I have a few questions. What kind of crash are we talking about? Is it an actual client crash (the kind that generates a bug report) or is it a client lockup? Also, am I right in saying that the leading theory is that there are a bunch of spurious inventory updates that are causing "too much" addon processing when you are killed by a guard?

Short Answers:

Originally Posted by ZOS_ChipHilseberg What kind of crash are we talking about?

I've not experienced it with paying a bounty or dying by a guard, I don't use many addons. But I did experience the horse swapping problem months back & it was a lock-up. I'm betting this is the same problem, it has the same cause stemming from everyone running code on all of the slots that get updated (in which all of them get updated at once) through the EVENT_INVENTORY_SINGLE_SLOT_UPDATE .

Originally Posted by ZOS_ChipHilseberg Also, am I right in saying that the leading theory is that there are a bunch of spurious inventory updates that are causing "too much" addon processing when you are killed by a guard?

When you pay a bounty (with stolen items on you) it fires a full Upate and updates all inventory slots (including your bank? But why you can't put stolen items in your bank). So yes, unless theres a reason for updating slots other than in your backpack, it is updating to much. Although, I think the main problem is that if your running several addons that run code during the EVENT_INVENTORY_SINGLE_SLOT_UPDATE it just compounds the problem. Every addon ends up running code on every slot at the same time.

More Details:
Some people said they were crashing when they "payed a bounty". I don't know what kind of crash, I've not experienced it. A few months back people had the same problem that I tracked down to swapping your horse to a different horse that has a different carrying capacity because it updates all of the backpack slots. I remembered this happening, which is what made me think to check the slot updates and when you pay a bounty with stolen items and it is updating even more than your backpack, so the problem is probably worse for them. With the horse problem I think I ended up recommending they put a scene check in their addons to check if we the user was at the stables & prevent their code from running at that time.

If you have stolen items on you when you pay a bounty a full update gets called and it updates all of the inventory slots (not just the backpack?? Why you cant put stolen items in the bank, but it updates those too). If an addon is running a lot of code on items during the EVENT_INVENTORY_SINGLE_SLOT_UPDATE, their code gets run on every slot that gets updated. If several addons are doing this it can cause a huge lag spike and a lock-up.

It happens when you pay a bounty WITH stolen items on you, for sure. It probably also happens when you are killed by a guard too (if you have stolen items on you), I didnt think to check that one. But I bet it does because its the updates that are fired when the game removes stolen items from your inventory, which would also happen when a guard kills you.

EDIT:
Ok since everyone else is throwing other bugs into the thread...and since no one else has had an answer for me.
Chip is there any chance I could get some feedback on this: IsPOIPublicDungeon(...): Is It a Bug?
The rest of the IsPOIxxxx functions do what their names suggest, but either this one is bugged or it just does not do what its name suggests...I'de really like to use it in my WaypointIt addon.

[ZOS_ChipHilseberg]

Originally Posted by thifi Issue: Whenever you pay a bounty or get killed by a guard and you have stolen items in your inventory, then the client triggers an EVENT_INVENTORY_FULL_UPDATE followed by an EVENT_INVENTORY_SINGLE_SLOT_UPDATE for all items in your inventory. This cause several addons to start extremely intensive processing which may lead to a client lockup for 5-30 seconds, on several occasions a complete client crash.

Originally Posted by circonian I did experience the horse swapping problem months back & it was a lock-up. I'm betting this is the same problem...

We’ve identified the issue that’s causing the UI to get spammed with a bunch of single-slot updates whenever the server wants to give you single full-inventory update. We’re testing a fix that will cause full-inventory updates (for example, the one that happens when items are confiscated by a guard) to only trigger one EVENT_INVENTORY_FULL_UPDATE, instead of spamming you with single-slot updates.

Originally Posted by thifi Currently when the guard approaches you GetInteractionType returns 14 instead of 30 so we cannot tell whether it's a normal NPC conversation or a pay bounty dialog.

The easiest way to do this is to use the IsUnderArrest() function, which will return true while the player is in the arrest conversation itself, and while stunned as the guard runs up to you.

[thifi]

Originally Posted by ZOS_ChipHilseberg We’ve identified the issue that’s causing the UI to get spammed with a bunch of single-slot updates whenever the server wants to give you single full-inventory update. We’re testing a fix that will cause full-inventory updates (for example, the one that happens when items are confiscated by a guard) to only trigger one EVENT_INVENTORY_FULL_UPDATE, instead of spamming you with single-slot updates.

That would be really helpful. Thank you.

Originally Posted by ZOS_ChipHilseberg The easiest way to do this is to use the IsUnderArrest() function, which will return true while the player is in the arrest conversation itself, and while stunned as the guard runs up to you.

Thanks, will check it out.

Regards,

[QuadroTony]

so we will w8 the patch, or some1 can make a workaround of this issue?

[circonian]

Originally Posted by QuadroTony so we will w8 the patch, or some1 can make a workaround of this issue?

Theres no way to get around it, you'll have to wait.