So let me get this straight.. because maybe I'm lost and
jadeling made it clear to me. You're saying that your issue is that if you move an item from your Cash Storage to your Character Inventory that it works fine, but moving it from your Character Inventory right back to your Cash Inventory afterwards won't work? If this is so, what happens if you were to exit the CS and re-enter it, only to add the item back to your Cash Inventory from your Character Inventory? Does it work properly, or you can not add back items period once it's been transferred to your Character Inventory from the Cash Inventory?
If it can't be moved back to your Cash Inventory only after it is moved to your Character Inventory, but works if you re-enter, then it is an issue with your packet moving it from LtoS (LockerToStorage). However, if you can't add items back period, then you're right -- it's your addInventoryInfo. BUT, it's not the addInventoryInfo that's messing up, it's the addItemInfo portion inside of it like
jadeling had pointed out earlier. Looking at your addItemInfo it's a bit weird, I guess that's just Odin's layout of it though.. I don't really see how the masking and ring bools work out because those bytes are written out as ints and shorts and bytes everywhere when it's really just a FileTime long, geez.. Well, let me try and guide you through it in comparison to Nexon. This will probably be long, so if you don't want to understand why it doesn't work and how to reference IDA then just skip to the tldr at the bottom I guess lol.
Compare your addItemInfo to what Nexon does (IDA) and ignore the position part, since the position part is correct:
PHP:
void __thiscall GW_ItemSlotBase::RawEncode(GW_ItemSlotBase *this, COutPacket *oPacket)
{
signed int v2; // [sp+0h] [bp-10h]@2
GW_ItemSlotBase *thisa; // [sp+8h] [bp-8h]@1
thisa = this;
COutPacket::Encode4(oPacket, this->nItemID);
if ( *(_QWORD *)&thisa->liCashItemSN._s0.LowPart )
v2 = 1;
else
v2 = 0;
COutPacket::Encode1(oPacket, v2);
if ( v2 )
COutPacket::EncodeBuffer(oPacket, &thisa->liCashItemSN, 8u);
COutPacket::EncodeBuffer(oPacket, &thisa->dateExpire, 8u);
}
So as you can see you start out encoding the base of the item. int ItemID as you have, then a boolean for if the liCashItemSN > 0 or not. What you SHOULD do at least is add a check for
ii.isCash(item.getItemId()) and write a long for it, otherwise just do nothing. Then you have another long which is written for all items, this is the expiration date long. You don't use expirations since I can see hard-coded longs there, but you could always just write a hard-coded long for infinite time so it looks better imo.
Moving on to the actual equip data, we then have this sub:
PHP:
void __thiscall GW_ItemSlotEquip::RawEncode(GW_ItemSlotEquip *this, COutPacket *oPacket)
{
char *v2; // ecx@1
ZXString<char> v3; // [sp-4h] [bp-10h]@1
int v4; // [sp+0h] [bp-Ch]@1
GW_ItemSlotEquip *thisa; // [sp+4h] [bp-8h]@1
ZXString<char> *v6; // [sp+8h] [bp-4h]@1
thisa = this;
GW_ItemSlotBase::RawEncode(&this->baseclass_0, oPacket);
COutPacket::Encode1(oPacket, thisa->nRUC);
COutPacket::Encode1(oPacket, thisa->nCUC);
COutPacket::Encode2(oPacket, thisa->niSTR);
COutPacket::Encode2(oPacket, thisa->niDEX);
COutPacket::Encode2(oPacket, thisa->niINT);
COutPacket::Encode2(oPacket, thisa->niLUK);
COutPacket::Encode2(oPacket, thisa->niMaxHP);
COutPacket::Encode2(oPacket, thisa->niMaxMP);
COutPacket::Encode2(oPacket, thisa->niPAD);
COutPacket::Encode2(oPacket, thisa->niMAD);
COutPacket::Encode2(oPacket, thisa->niPDD);
COutPacket::Encode2(oPacket, thisa->niMDD);
COutPacket::Encode2(oPacket, thisa->niACC);
COutPacket::Encode2(oPacket, thisa->niEVA);
COutPacket::Encode2(oPacket, thisa->niCraft);
COutPacket::Encode2(oPacket, thisa->niSpeed);
COutPacket::Encode2(oPacket, thisa->niJump);
v3._m_pStr = v2;
v6 = &v3;
v4 = ZXString<char>::ZXString<char>(thisa->sTitle, -1);
COutPacket::EncodeStr(oPacket, v3);
COutPacket::Encode2(oPacket, thisa->nAttribute);
if ( !GW_ItemSlotBase::IsCashItem(&thisa->baseclass_0) )
COutPacket::EncodeBuffer(oPacket, &thisa->liSN, 8u);
}
Which following this does not match your packet because of the ring and "masked" booleans. So why won't "masked" always work the way it should? Well, simply put, you're assuming that the item is a "Cash Item" (NX)
only if the slot position > 100. While this is true, it is ONLY true when you EQUIP that NX item. If it is otherwise being moved in your inventory or within the Cash Shop etc, masked will result to false because it is being moved to the slot of the inventory which would be 1~96. The issue with this is that cash items hold their own structure, different to a non-NX item. They should be handled regardless of position pretty much.
Moving on.. so the whole reason it isn't working is because of this part here:
PHP:
// 0 normal; 1 locked
mplew.write(equip.getLocked());
if (ring && !equipped) {
mplew.write(0); //This byte is irrelevant.
}
if (!masking && !ring) {
mplew.write(0); //This byte is irrelevant.
mplew.writeLong(0);
}
For starters, reference BMS's RawEncode. Notice a difference? The byte for locked items (even though it isn't actually for locked items lol it's the item flag/attribute mask for multiple things) is a single byte here, but in reality it is actually a short. Instead of having two random conditionals adding the same byte, just change that into a short and remove the irrelevant byte. Now we are back to the masking issue. What I suggest is that where you declare masking as false, you change it to what I suggested earlier:
Code:
boolean masking = ii.isCash(item.getItemId());
If you can transition into determining real cash items, then you can utilize the checks properly and have no issue. Now let's go back to BMS's RawEncode. Notice how that long is written ONLY if it is NON-NX? Well, because "masking" returns false here even if it is NX, it will always write that long. In that sense, your packet is actually writing NX and telling the client it is non-NX. In the actual game that is fine because SN's are generally useless there, it's mainly for tracking/logging purposes for Nexon. However, if you're making an item Non-NX when slot position isn't 100, and you're placing this "Non-NX" (which is actually NX) into the Cash Shop, then it won't do anything because you can't move NX into the Cash Storage. The only reason it isn't grayed out and un-clickable like the regular Non-NX is because the client knows in the WZ files itself that the item is "cash".
TL;DR, your "masking" boolean needs to determine real NX through something like ii.isCash rather than the position, and you need to remove the two irrelevant bytes and make the getLock() byte into a short (aka nAttribute). If you do want to truly update that packet then yeah a lot more could be done, but now you hopefully know why that addItemInfo won't work in its current state and that referencing BMS is fairly easy once you get the hang of it. If your cash item handling is otherwise working and the changes to addItemInfo are done correctly, then moving them should work perfectly fine.
ecode in IDA. Mine may have more than what's directly in 62, but here's mine if you need any reference: