[Uleat]

Here are some known bugs and behaviors that I have observed.

Some of the behaviors I have seen are omitted since they are duplicate scenarios of the same issue. There are also some other
non-revelent issues here since I'm looking at the entire inventory.cpp module.


[Cursoring a partial arrow stack involved in bandolier swap, with no other partials in inventory, results in de-sync (Bug)]
- This is caused by MoveItemToInventory(). It does not check the cursor for a partial stack before trying to find an empty
slot. Client behavior checks the cursor before moving on to empty slots. {TESTED AND VERIFIED - Partial fix appears to work}


[Cursoring one of the weapons involved in bandolier swap that has arrows results in de-sync (Bug)]
- Known issue, but still researching the exact cause. Could be related to the above bug. {TESTED}


[Clicking an item stack and it is non-responsive (Behavior)]
- At this point, you are bugged. You need to camp or zone to fix this problem asap before item loss becomes permanent. Any
items that you click, trade, buy or receive after invoking this behavior become subject to item loss. I guess this could be
applied to any item, but if not, that would narrow down the cause list. {TESTED}


[Placing an arrow stack in the ammo slot results in an 'Insufficient Quantity' error message and item deletion (Behavior)]
- The part of the code that triggers this message is working correctly. Again, you have become bugged by this point. Other
stackables are probably affected the same way. {ARROWS - TESTED AND VERFIED}


[Moving an item results in an 'Item Not Found On Server' error message and item deletion (Behavior)]
- Bugged..you know what to do. {TESTED AND VERFIED}


[Zero-charge stackable item (Bug or Behavior - still in-work)]
- It's possible to have an arrow (or possibly any stackable item) with zero charges. This can turn into an exploit, so I will
not elaborate on it's cause. (I have triggered this, but do not have an exact procedure as yet. I was already suspecting this
as a problem, but I have found a way to provide evidence of it.) {TESTED}


[Backpack - the new ammo! (Behavior)]
- Overloading the inventory and then calling a swap will result in some REALLY odd behavior (And major item loss.) I managed
to get a backpack into my ammo slot..I did not try to use my bow, however... (I wonder if a bag would actually fly across the
screen..hmmm...) {TESTED}


[Probable issue with Client::PutItemInInventory 'CalcBonuses' call]
- If you look at this particular function, you will notice there are two (slot_id == SLOT_CURSOR) checks. The first one is
always processed on 'true,' but the second one is never processed on 'true,' however... The call to PushItemOnCursor in the
first check duplicates the entire segment of code that is missed. This is not the problem...

- Look at the second one again. The check ALWAYS handles a return and CalcBonuses() is never called. {NOT TESTED}


[Possible issue with Client::TryStacking]
- With stackable items, this method checks the eight personal slots first before going back through bags and misses the cursor
altogether. This does not match the client and other server scheme for parsing stackable items. Corpse looting will likely
become bugged due to the same de-sync issues described above. {NOT TESTED}


[Possible issue with Inventory::SwapItem (item.cpp)]
- One-way check... slot 'a' item is checked against slot 'b,' but not vica-versa. First attempt at a fix crashed zone.exe...
This needs to be researched more thoroughly. {CONSEQUENCE OF LACK OF CHECK - NOT TESTED}


[Not pertinent - possible message issue with summoning items with augmentations]
- This is not tested, but I have seen where a possible lore conflict message will kick back when no other lore item is owned
and also on non-lore flagged items. The lore checks are correct, but the reference to the lore item in the message is set to
the base item and not the augmentation itself - meaning that you are trying to create an additional lore augmentation, but not
lore item itself, and it is reporting the wrong lore conflict. Let me know if you have experienced this. {NOT TESTED}


[Not pertinent - #peekinv is not showing slot #30 in the listing when its value is null, or supposed to be]
- I haven't looked at the code to see if the 'GetItem()' command is just not reporting or is in a failed state. {OBSERVED}


After working these issues, and anything new that crops up with fixes, I'll take a look at consumption issues. I just need to
verify that they are not a part of these exisiting de-sync problems.


If you are posting symptoms, please include server revision, system and client information as well. I don't believe these
problems are unique to, or exclusive of, any particular setup, but we won't be able to determine that without the proper data.

These issues are long-lived and I'm sure that everyone would love to see them fixed. Please support this request if you have
pertinent information.

And to remind anyone wanting to fix these issues one at a time - Please do not do so with the item swapping issues. You will
introduce major exploits unless all of the issues are coordinated and fixed together.


Thanks!