Here is the really weird thing that makes me think this is client and not server controlled.
I was debugging into zoneperl.exe and had a trap on CheckLoreConflict call. I made sure it worked when I picked up a batwing off the ground. All good. Then I reproduced this defect.
When I reproduced this defect, the CheckLoreConflict function was not called at all.
Recompiling with this hard coded to "return false;" - my bet is that the client will still delete it because it believes there is a lore conflict.
-- Update --
Yup, this is a pure client issue. Appears to be occurring in SoD for sure. Will test this out in a Titanium Client.
How to reproduce easily.
Hard code CheckLoreConflict to return false.
#summonitem 5407 multiple times (Executioners axe - lore).
Note you can have multiple on you.
Drop one on the ground.
Pick it up and note you will have "Duplicate lore items deleted!" and the items will disappear. Log and come back in and they will still be present.
Testing this out on Titanium.
-- Update --
Titanium has same issue.
This may have been already noted in source via the comment:
" // if there is a lore conflict, delete the offending item from the server inventory
// the client updates itself and takes care of sending "duplicate lore item" messages
"
Seems to imply that the client will remove it from its own inventory and the server just needs to remove it from ours.
Would explain why it is fine when the user zones / camps (as server still has the "duplicate lore items" but client has them removed).
I consider that this is still the proper fix for this issue from the tests above...
|