[LE] GetItemCount() returning 1 despite an empty container

[foamyesque]

I have some stuff that relies on being able to tell when there's 0 of a specific item in a specific container, which will usually be put there by levelled lists.

The trouble is that if those items are put there by levelled lists, GetItemCount() will never return zero. It reports correctly on every amount above that (e: this is true regardless of how many levelled lists add the item), and also reports correctly if the container has had the items added directly instead of by levelled lists. I assume this is related to the bug vaguely referred to on the wiki page for the function.

 

My current workaround is to use SKSE's GetContainerForms() function to dump the forms of the container into an array, run a find on that to see if it contains the form I'm interested in, and if it does, then call GetItemCount() to find out how many it has.

    Form[] myInventory = GetRef().GetContainerForms()
    int iItemCount = 0
    if myInventory.Find(akBaseItem) >= 0
        iItemCount = GetRef().GetItemCount(akBaseItem)
    endif

(I used an alias for the script, hence the GetRefs())

 

Does anyone know of a better way?

Edited September 5, 2017 by foamyesque

[mrpwn]

Have you tried checking what happens if you move all of the container's contents to another container with RemoveAllItems? Does GetItemCount still return an unexpected value when called on that other container?

 

EDIT: Are you always checking for the same item? If so, then you might be able to use the condition functions that are available in e.g. quests and magic effects. I'm not sure if that system is also affected by the same bug that GetItemCount appears to be suffering from.

Edited September 5, 2017 by mrpwn

[Evangela]

I remember a guy named Inki back on the old beth forums was testing this function tirelessly. To sum up his tests, GetItemCount really don't like searching through leveledlists that are from properties filled by the CK. I believe the situation the OP is encountering, might be this:

 

Calling this function on an objectreference from the outside of its cell will return 1 in the case of the passed in form being in a leveled list. Needs more testing.. but works fine if the player is in the same cell.

[foamyesque]

To answer some of the questions:

 

1. No, I'm not searching for the same item every time. The base form being looked for is generated by an OnItemRemoved() event, and I require a count of how many items of that kind are left in the container, for purposes of further scripting. That also means I can't make use of the CK's conditional functions without a bunch of extra horsing around.

 

2. No, I have not tried a RemoveAllItems command and tested whether GetItemCount returns successfully on the other container, as such. Based on what I have found while searching, GIC should work correctly on the second container. However, that solution has some issues w.r.t. my specific needs: I have active OnItemRemoved events on the original container, the original containers I wish to apply this script to are without exception merchant chests and therefore usually have large numbers of forms within them, this is a function that needs to process quickly, and I have a (fairly complex) set of inventory filters I want to apply in order to reduce the number of OnItemRemoved() events to the minimum possible. Any solution I have come up with involving container inventory transfer causes problems with one or more of those points.

 

3. I am calling GIC while in the same cell as the container in all of my test cases. The container is there and loaded, and if it has say, five copies of something and they are removed in sequence, logging gets me "itemName: 4 left", "itemName: 3 left", "itemName: 2 left", "itemName: 1 left", "itemName: 1 left". I have not as yet tested the behaviour when the container is in an unloaded cell, which I need to do as it is a usecase that appears a few times in what I'm working on.

 

EDIT:

Works with the container being in an unloaded cell, but it was persistent on account of being in a quest alias. That covers my usecases though.

Edited September 7, 2017 by foamyesque