View Single Post
  #7  
Old 09-03-2012, 03:48 PM
Uleat's Avatar
Uleat
Developer
 
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
Default

Just a little note on item loss with overloaded inventory...


I do have a working theory on this one, but I HAVE to ensure that I can test every call to the affected code. (I'm assuming that I won't get any script calls
unless there is something defined to handle it. Otherwise, another function calls it.)

The problem likely lies in multiple areas, but the code in item.cpp::Inventory::FindFreeSlot() is most culprit. (Kinda the reverse issue that was in the Bandolier code.)

In the case of a corpse [Loot All]... When you have a full inventory (with an empty cursor), but still have occupied bags on your corpse:

- The next bag is pushed to SLOT_CURSOR and the contents are pushed to 331 - 340
- ALL subsequent bags are also pushed to SLOT_CURSOR, via the queue, and each bag's contents overwrite any previous bag's data in 331 - 340
- The bags themselves will end up in the cursor queue
- The contents of the first cursored bag will be:
-- The contents of the last corpse bag if it was full -or-
-- A mix of contents of both previous and last corpse bag items if it was not full
-- (I'll need to double-check, but I believe _putitem is used instead of _swapitem..which means existing items go bye-bye..changing it would create more problems)
- Any queued cursored bags will be empty

I'm not sure exactly what behavior would occur if a non-container item was first on the cursor since bag slots aren't moved in that case. A bag 'popping' into the
cursor slot 'may' avail any lost and un-deleted items in the 331 to 340 range. These items would now be assigned to that bag and any remaining bags would
still be empty.


This problem will probably arise with overloaded trades as well. I've seen posts regarding both loot all and trading with this issue.


Anyways... I can't seem to find an OP_Code that handles the 'Loot All' action. Does the client actually send a loot request op for each item in the corpse
window?

If it does, and the client DOES NOT move the items, we could cancel the transaction and leave the bags on the corpse. If the client DOES move the items
regardless, all we can do is minimize the damage..maybe by 'unpacking' the bags to the cursor queue, but we might have to bump up the active queue array
size. Dropping them to the ground would most likely lead to them being lost if the player can't clear their inventory to make room. (I guess we could unpack
the bags when the corpse is created as well... Wouldn't that be a mess...)

(What I've seen with the cursor queue size on the server and a SoF client: {client: 37; profile: 102; database: 1000})


(This conversation sounds familiar..sorry if I duped it from somewhere else...)
__________________
Uleat of Bertoxxulous

Compilin' Dirty
Reply With Quote