Bug 74: (zippyzee) Critical Item Issue

[zippyzee]

aIndex in the .list 799123 command for the belt also has it as -1. Something not loading correctly from the db...

Actually I mis-spoke. The belt does have -1 as its attachment index. The boots have 225007 which is presented in-game correctly. It should not be -1 in the packet. Are you sure that is the packet for the belt? Do you get the same packet if you do only the boots, without switching the other item in and out first?

In any case it looks like some programming slippage. They were supposed to mark non-visual items with item->type = -1, and marked the attachment index as -1 instead. I will add a check for that and see how things behave.

[Xinux]

That is right since the value is a int which is -1

Attachment index

Code: Select all

799123 = 4294967295
800730 = 225007

[Xinux]

What worries me is that they all have the same invSlot: 10

[zippyzee]

There is something definitely weird going on there. It is pulling the slot from item->default_slot. None of those items should say '10'. Can you pull some more packets and find an item that sends anything but 10? Or anything on any of those fields different from the 3 you listed?

I have updated worldcharacter.cpp to add checks to the attachment index to prevent these items from going nuts. I tested on those problem items and they seem fine.

At another time you or I can investigate why the packet information is incorrect but this is a short-term solution.

I also noticed that some items on the broker are not showing their full statistics. They do in the inventory, but not on the broker hover-over. Also, some items are correctly shown as not equippable on the broker but are not red-shaded in inventory. I'll just add those to the list of things to figure out.

[Xinux]

Did a little test here are the results.

Item 1412372 (waist) added

Code: Select all

ATTACHMENT_GROUP[21] = pIndex: 19, aIndex: 114024, invSlot: 21

Item 1412372 (waist) removed

Code: Select all

ATTACHMENT_GROUP[21] = pIndex: 0, aIndex: 114024, invSlot: 21

Item 1412372 (waist) added

Code: Select all

ATTACHMENT_GROUP[21] = pIndex: 19, aIndex: 114024, invSlot: 21

Item 1412372 (waist) removed

Code: Select all

ATTACHMENT_GROUP[21] = pIndex: 0, aIndex: 114024, invSlot: 21

Item 799123 (waist) added

Code: Select all

ATTACHMENT_GROUP[21] = pIndex: 19, aIndex: -1, invSlot: 10 (bad slot)

Item 799123 (waist) removed

Code: Select all

ATTACHMENT_GROUP[21] = pIndex: 0, aIndex: -1, invSlot: 10 (bad slot)

Item 799123 (waist) added

Code: Select all

ATTACHMENT_GROUP[21] = pIndex: 19, aIndex: -1, invSlot: 10 (bad slot)

Item 799123 (waist) removed

Code: Select all

ATTACHMENT_GROUP[21] = pIndex: 0, aIndex: -1, invSlot: 10 (bad slot)

Item 800730 (feet) added

Code: Select all

ATTACHMENT_GROUP[21] = pIndex: 0, aIndex: -1, invSlot: 10 (bad slot, attachment index and type)
UNLIT = True
UNK DT: 6

Item 800730 (feet) removed

Code: Select all

ATTACHMENT_GROUP[21] = pIndex: 0, aIndex: -1, invSlot: 10 (bad slot, attachment index and type)
UNLIT = True
UNK DT: 6

[Xinux]

Issue is with the attachment index value if i change the value to 1+ everything is fine.

[Kandra]

[quote="zippyzee"]I also noticed that some items on the broker are not showing their full statistics. They do in the inventory, but not on the broker hover-over. Also, some items are correctly shown as not equippable on the broker but are not red-shaded in inventory. I'll just add those to the list of things to figure out.[/quote]
There were actually an issue with this even on the live server, that some items would not be red-shaded. Moving the item in the inventory would sometimes fix it.

[Glaxono]

I was able to duplicate this problem and /bugged it. Reference Bug ID 77 for more information.

More Data:
- The location of the immediate porting when item is equipped is -2 -2 -2
- When rifting, the location of the targeted chunk is also -2 -2 -2
- When the item is removed from inventory, the rifting to -2 -2 -2 still persists!
- To clear the -2 -2 -2 location when rifting, you must equip another non-affected item in the same slot (not sure of the same slot... though but that is how I tested and confirmed it)
- I was able to duplicate this issue

Glaxono
(Zarlore, Earful)

[Xinux]

Ok figured out some more with unknown57 i would send them default 0 and then change them as they are equipped/unequipped/moved. I'll let you name it if you want to change the name.

0 = not equippped
1 = Equipped
2 = ?
3 = ?
4 = ?
5 = ?
6 = ?
7 = In Bank
8 = In Graft
9 = ?
10 = In Buyback

[Lokked]

Perfect, I bet this explains the issue in the other thread as well, with I equipping an item not reverting the attack animation to bare fisted. Likely, this unknown needs to be set to 0 for unequipping.