About addons and accidents

[sirinsidiator]

I had an extremely frustrating experience this week where I effectively lost 40k gold because items got bound to my character when they should not have been.

The first case happened when I wanted to attach an item to a mail in order to free some space in my inventory. I opened the mail menu, moved the mouse over the item I wanted to send and pressed E like usual. But for some reason the option to "Add to Mail" was missing and instead it equipped the item. I checked the context menu on a different item and the entry was also missing. Only after closing and reopening the menu it reappeared.
I didn't care much about it then, because it was just one worthless item that I wanted to deconstruct anyways.

The second and for me extremely frustrating case happened a few days later when I wanted to sell a valuable ring (~40k) to a guild store.
I previously bought it on a guild store and still had it inside the purchase mail. As I didn't have a need for it anymore I wanted to resell it and thus took it from the mail, opened the guild store at the banker in Mournhold, switched to the sell tab, moved the mouse over the ring and pressed E. Instead of showing the sell interface, the ring got equipped and bound.
I immediately contacted customer support and they told me they cannot help me in this case because they are not able to unbind items (9 month after launch they still don't have proper tools!).

Why am I writing this in this forum you ask? Well, it's because this all happened because of addons.
One might argue now that it might be caused by something I wrote myself, but I am pretty sure that I do not change the interface in any way that might cause this behavior.
I also never had this problem until I installed a few additional addons recently (FCO ItemSaver, JunkIt, Shopkeeper).

I suspect that the bug might be caused by ItemSaver because it changes the context menu, but I haven't looked into its code and also was not able to reproduce the issue since then.
One thing that I noticed, was that in both cases I was experiencing lag when I opened the menu (I always have the fps and latency meter on).

What I hope for the future by writing this, is that other addon authors see this as a warning and take extra care when they do things that might change how the default interface behaves.

I also hope that we can add a feature to ItemSaver (or make a dedicated addon) to prevent items from being equipped involuntarily, because this is something where customer support can't and won't help at all.

TL;DR: Items got bound when they shouldn't have been. Now I am extremely frustrated and want to prevent it from happening again.

[circonian]

That would be frustrating, sorry to hear about that.

JunkIt does not modify the keybindStrip in any way. It does nothing with mail and only sets a rowCallback in the trading house for research icons.

I did a quick search in all of the shopkeeper addons & FCO ItemSaver, but I didn't see any references to the keybindStrip or anything that looked like it had been modified. (I only did a few quick keyword searches though)

[Baertram]

Sorry to read this sirinsidiator.
I hope it wasn't FCOItemSaver. I never experienced this "buggy behaviour" before and noone has reported an issue so far.

@Circonian
FCOItemSaver is not changing the keybinds directly but using the game's context menu methods to do so, as this will help gamepad players and mouse players.

Short explanation:

OnMouseEnter the item:
-Is the anti-destroy/anti-sell/anti-deconstruct etc. settings enabled?
->Is the item marked with any icon?
-->Remove the context menu entry to destroy/add to mail/add to shop/add to deconstruction/...

By removing the context menu entry the standard behaviour of the game is: Remove the keybind for the same function (e.g. destroy) as well.

@sirinsidiator
Do you remember if the item you wanted to sell was marked with any icon from FCOItemSaver?
You said you took it from a mail.
Did you mark it manually afterwards, like with the "sell" icon?
If it was not researchable for one of your characters or it was an ornate icon (assumed you had enabled the automatic marking of these items in the settings and you are using ResearchAssistant) there shouldn't be any change done to the context menu and the keybindings.

I'l have a look if I can rebuild this. Maybe I can implement a security question for equippable items that are not bound too. I always wanted to add this after I have equipped a set part accidently that was crafted for another char o0

[Baertram]

I've updated FCOItemSaver with a dialog asking you if you want to bind an itemto your acocunt if the item is bindable and not already bound.

You are able to enable/disable it in the settings.

Hope this helps to prevent those erros in the future, even if the error did not come from my addon.

I'll release it soon after some more tests.

Edit:
Release now as version 0.5.1a

[sirinsidiator]

Originally Posted by Baertram Sorry to read this sirinsidiator. I hope it wasn't FCOItemSaver. I never experienced this "buggy behaviour" before and noone has reported an issue so far.

Figured it would be something rare.
Maybe it's even unique to my combination of addons + lag.
I haven't been able to reproduce it, but I will continue and try to find the reason.

Originally Posted by Baertram Do you remember if the item you wanted to sell was marked with any icon from FCOItemSaver? You said you took it from a mail. Did you mark it manually afterwards, like with the "sell" icon? If it was not researchable for one of your characters or it was an ornate icon (assumed you had enabled the automatic marking of these items in the settings and you are using ResearchAssistant) there shouldn't be any change done to the context menu and the keybindings.

The first item was marked as sell, but when I tried I could not add it to the mail. I disabled the marking on all items that I planned to send and went back to the mail screen and then it got bound.
I don't use automatic marking or ResearchAssistant.

In the second case I did nothing else between taking it from the mail and opening the guild store.
I logged in and was in Cyrodiil, went to Mournhold via Wayshrine and entered the bank without doing anything else before.

Originally Posted by Baertram I've updated FCOItemSaver with a dialog asking you if you want to bind an itemto your acocunt if the item is bindable and not already bound. You are able to enable/disable it in the settings. Hope this helps to prevent those erros in the future, even if the error did not come from my addon. I'll release it soon after some more tests. Edit: Release now as version 0.5.1a

Thank you very much for adding it so fast. I will certainly use it in the future.
Once I am able to reproduce what happened that day I'll let you know.

[Baertram]

If the first item was marked for selling the context menu maybe stripped the primary keybinding (something like add to mail or add to deconstruct window etc.) and the second entry got the primary one.
If the second one was "Equip" this could have been the reason then.

The second item, if there was no marked from FCOItemSaver, should still have the normal "Add to ..." primary keybinding. It updates on mouse-over the element and will then remove the context menu entries. If you mouse-over an item that is not marked with any marker from FCOItemSaver the context menu will not be changed, and so the keybindings wont be changed.
Maybe it was really a lag or some false positive from SavedVariables (item was marked in the past and was still in the SavedVariables). But you'd probably have seen an marker icon then.
I hope this won't happen again and was not happening because of my addon.

If the new feature "Anti-Equip" works well this should be fixed then.

Originally Posted by sirinsidiator Figured it would be something rare. Maybe it's even unique to my combination of addons + lag. I haven't been able to reproduce it, but I will continue and try to find the reason. The first item was marked as sell, but when I tried I could not add it to the mail. I disabled the marking on all items that I planned to send and went back to the mail screen and then it got bound. I don't use automatic marking or ResearchAssistant. In the second case I did nothing else between taking it from the mail and opening the guild store. I logged in and was in Cyrodiil, went to Mournhold via Wayshrine and entered the bank without doing anything else before. Thank you very much for adding it so fast. I will certainly use it in the future. Once I am able to reproduce what happened that day I'll let you know.

[sirinsidiator]

Originally Posted by Baertram Maybe it was really a lag or some false positive from SavedVariables (item was marked in the past and was still in the SavedVariables). But you'd probably have seen an marker icon then. I hope this won't happen again and was not happening because of my addon.

Did I mention that I have two identical rings? One of them is marked and equipped. Maybe that caused the problem?

[Baertram]

Maybe the item was not marked correctly in your inventory (symbol not shown) and as you wanted to add it to the "sell" list the check recognized the item ID and said from the SavedVariables: Ah this item is marked -> Remove the "Add to sell list" context-menu entry.
So the context-menu was showing "Equip" as primary action then.

This could be the reason then, but I don't know any solution so far as the item ID will be the same for identical items (this is why e.g. the potions will all be marked even if you don't stack them, which is needed imo).

But with the new confirmation dialog this shouldn't hoepfully not happen anymore.

[circonian]

Originally Posted by Baertram This could be the reason then, but I don't know any solution so far as the item ID will be the same for identical items (this is why e.g. the potions will all be marked even if you don't stack them, which is needed imo).

I only scanned the code, but if your refering to using this in FCO ItemSaver:

itemId = SignItemId(GetItemInstanceId(bagId, slotIndex))

There is a uniqueID for items (convert it to a string before saving), this is what I used in FilterIt to uniquely identify items:

local sUniqueId = Id64ToString(GetItemUniqueId(_iBagId, _iSlotId))

I convert it to a string to save in a saved variable table, then when I want to check it against an item, do the same thing. Get the unique id, convert it to a string, & check it against the saved unqueID strings.

[Garkin]

I really wonder why ZOS in source code uses tostring instead of Id64ToString.

PTS v1.6.0, EsoUI\Libraries\Globals\globalapi.lua, lines 223-227:

-- id64s are stored as lua Number type, and sometimes generate the same hash key for very similar numbers. 
-- Use this function to get unique hash key for a given id64. 
function zo_getSafeId64Key(id)
    return tostring(id)
end

[sirinsidiator]

Originally Posted by Baertram Maybe the item was not marked correctly in your inventory (symbol not shown) and as you wanted to add it to the "sell" list the check recognized the item ID and said from the SavedVariables: Ah this item is marked -> Remove the "Add to sell list" context-menu entry. So the context-menu was showing "Equip" as primary action then. This could be the reason then, but I don't know any solution so far as the item ID will be the same for identical items (this is why e.g. the potions will all be marked even if you don't stack them, which is needed imo). But with the new confirmation dialog this shouldn't hoepfully not happen anymore.

Instead of removing the context menu entry, you could disable it. That way, the primary entry won't change and nothing unexpected will happen when you press E. Maybe even show an alert that the item cannot be added to sell because it is marked by ItemSaver.

Not sure about the details on how to achieve this. I remember trying to disable the keybind strip in AGS, but I think I recall that it was not as simple as I thought.

[BornDownUnder]

hmm, I recall a long time ago that I was having similar issues with early AlphaTools saved equip-set swapping, where I had identical items, one that was saved & assigned for equip, one was unbound as just picked up. Sometimes, though not often it would equip automatically the unbound item instead of the one that was marked for the saved equip set... At the time I was also saving items using the original item saver, which would save the unbound item as well as it was the same as the bound.

In saying that, there was never any key-bind associated usage, other than hitting the corresponding key-bind for the automatic set-swap, which I have bound to F-series keys. The item was just sitting in inventory waiting for the guild store listings as well.

Not having looked into your coding, etc. It most likely is completely erroneous as a factor, though in turn might provide some unknown to me insight or ideas for developers?

[Baertram]

If you want to prevent an unbound item, where you got a second item of the same type in your inventory, to be equipped by your tool, you could check my function "isBindable()" in teh FCOItemSaver source code to see how to check if the item is bindable or not bindable or already bound.

But if your addon, like mine, is using the item ID to determine the item, this item ID will be the same for the 2 items (as they are the same in the game).

There might be other IDs for items, like the 64bit uniqie IDs, but I have read there is some trouble if you save them to the SavedVariables and try to read them back to your addon.
This might get fixed with update 1.6 as there are new 64 uniqie ID functions.

[circonian]

Originally Posted by Baertram There might be other IDs for items, like the 64bit uniqie IDs, but I have read there is some trouble if you save them to the SavedVariables and try to read them back to your addon. This might get fixed with update 1.6 as there are new 64 uniqie ID functions.

This may or may not be what you are referring to, but I did run into problems if I tried to save the

GetItemUniqueId(_iBagId, _iSlotId)

to the saved variables. It was a while ago, I don't recall for sure what it was, I'm thinking it wiped out the (e-314) part?

But as long as its converted to a string before I save it I haven't had any problems:

local sUniqueId = Id64ToString(GetItemUniqueId(_iBagId, _iSlotId))

[Baertram]

Yep that function 1.GetItemUniqueId(_iBagId, _iSlotId) was the one I was referring to.

I read somewhere that the String conversion by function Id64ToString(GetItemUniqueId(_iBagId, _iSlotId)) was creating no unique strings anymore! So there could have been one string saved to the SavedVariables, for two different items. But maybe I got this wrong?
So you could not be sure to read the correct string ID from the SavedVariables again.

If this is fixed now BornDownUnder can use this method to distinguish the different armor/weapons for his equipment swapper and the unbound items that are not part of the equipment build shouldn't be touched anymore.

For ItemSaver and FCOItemSaver this could only work for items that don't stack. Otherwise you would have to mark every single potion etc....

[Baertram]

@sirinsidiator
I've found a way to prevent usable items being used as you start to trade/mail them, and if they are marked.
With the previous update of FCOItemSaver they will be secured now.

[sirinsidiator]

Good to hear!
I haven't had much time to sell items lately, but I'll give it a try once I find another pair of identical items.