ESOUI - ZOS mail attachement bug

ESOUI (https://www.esoui.com/forums/index.php)

- General Authoring Discussion (https://www.esoui.com/forums/forumdisplay.php?f=174)

- - ZOS mail attachement bug (https://www.esoui.com/forums/showthread.php?t=6158)

ZOS mail attachement bug

video without addons

i meet it many times and still cannot find a reason - everytime its different items, with different quality
just sometimes whel i put item in 6th slot its placed to 5th instead

and it cannot be fixed by reloadui, you need just change the order
no matter how i do it - by mouse or by E

www.youtube.com/watch?v=OXJ4Q-t0qOM

guys how to fix with addons?

I have it also few times, and need to guess hwich are the correct ones to "fix" them...

I'll wait a bit, for myself, game is so buggy right now.

The problem is caused by the method GetQueuedItemAttachmentSlotIndex in inventoryslot.lua.
According to the comments on the function, it should return nil if it is called on an inventory slot that is not attached, but instead it will return slotIndex in that case.
This becomes a problem when the slotIndex is between 1 and 6.

For example when we have two items A and B with a slotIndex of 1 and 42 respectively, the following happens:

Code:

No attachments:

ItemA: GetQueuedItemAttachmentSlotIndex returns itemA.slotIndex (=1)

ItemB: GetQueuedItemAttachmentSlotIndex returns itemB.slotIndex (=42)



ItemA is attached:

ItemA: GetQueuedItemAttachmentSlotIndex returns i (=1)

ItemB: GetQueuedItemAttachmentSlotIndex returns itemB.slotIndex (=42)



ItemB is attached:

ItemA: GetQueuedItemAttachmentSlotIndex returns itemA.slotIndex (=1)

ItemB: GetQueuedItemAttachmentSlotIndex returns i (=1)

It should actually return this:

Code:

No attachments:

ItemA: GetQueuedItemAttachmentSlotIndex returns nil

ItemB: GetQueuedItemAttachmentSlotIndex returns nil



ItemA is attached:

ItemA: GetQueuedItemAttachmentSlotIndex returns i (=1)

ItemB: GetQueuedItemAttachmentSlotIndex returns nil



ItemB is attached:

ItemA: GetQueuedItemAttachmentSlotIndex returns nil

ItemB: GetQueuedItemAttachmentSlotIndex returns i (=1)

The original code:

Lua Code:

local function GetQueuedItemAttachmentSlotIndex(inventorySlot)
    local bag, attachmentIndex = ZO_Inventory_GetBagAndIndex(inventorySlot)
    if (bag) then
        for i = 1, MAIL_MAX_ATTACHED_ITEMS do
            local bagId, slotIndex = GetQueuedItemAttachmentInfo(i)
            if bagId == bag and attachmentIndex == slotIndex then
                attachmentIndex = i
                break
            end
        end
    end
    return attachmentIndex
end

What it should be:

Lua Code:

local function GetQueuedItemAttachmentSlotIndex(inventorySlot)
    local bag, attachmentIndex = ZO_Inventory_GetBagAndIndex(inventorySlot)
    if (bag) then
        for i = 1, MAIL_MAX_ATTACHED_ITEMS do
            local bagId, slotIndex = GetQueuedItemAttachmentInfo(i)
            if bagId == bag and attachmentIndex == slotIndex then
                return i
            end
        end
    end
    return nil
end

RemoveQueuedAttachment also needs to be adjusted, otherwise it would remove the item in the first attachment slot when nil is returned.

Thanks for the info. We'll get it fixed.

thsnks!
UPD. sometimes not only 5th and 6th slots messed, but 4th and 5th for example

I found another bug related to mail attachments.
When I have attachements added and close the menu, they get reattached when I open it again.
This works fine as long as there are no empty attachment slots.
For example if I have items added in slot 1,2 and 4, the item in slot 4 won't get reattached.

This is because ZO_MailSendShared_SavePendingMail in mailsend_shared.lua does not add an object to g_pendingAttachments for empty slots, but ZO_MailSendShared_RestorePendingMail uses ipairs to iterate over g_pendingAttachments, which does not work if there is a hole in the array.
Instead it should use for i = 1, MAIL_MAX_ATTACHED_ITEMS do and check if the element is nil plus some other changes that may be required.

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 26456)

Thanks for the info. We'll get it fixed.

You shoud hire this guy! :D