Starting Work on SoF Opcodes/Structs

[trevius]

Been working towards getting augments able to load in SoF over the past few days. I think for that to happen, I have to get the correct way to send the client inventory working first. KLS coded the proper way to send the inventory, which is to send all items in a single huge packet, but that is causing crashes due to alignment issues. SoF is currently set to send items 1 at a time in individual packets so it doesn't have to rely on sending a perfect inventory packet. If the single packet structure gets mis-aligned at any time, it throws off the whole rest of the inventory and will cause a crash if too many items are loaded after the packet alignment is off.

After trying to use the original code that KLS wrote to handle the inventory, it looks like extra bytes are being added between items at the point that breaks the structure. I am unsure where these bytes are coming from atm, but it does seem really odd. I think that if we can figure out what is sending those extra 25 or so bytes, we can get the inventory to load fully and properly without crashing. Once that happens, we can start working towards adding in code to handle loading augments into items in this list.

While just playing around, I messed up the structure many times, and a few times it showed info on some of the things we don't know much about yet. I saw an item with an augment at one point and I also saw items that shows evolving levels and even power source percentage. It seems like once the inventory is loading properly, it shouldn't be too hard to figure out where evolving item info and power source stuff is set.

[trevius]

Good news! I got items loading the correct way as far as I can tell so far. The code KLS had written for it was actually very close to being perfect, but had 1 minor mistake in it. The subitem code was adding "length" instead of "sub_length", and since length was defined and not being cleared out before doing subitems, it was forcing all subitems to load as the same length. Since the lengths need to vary depending on the string fields like name and lore, it was causing the structure to break as soon as the second subitem in the list tried to get loaded.

Here is the code change I made:

for(int x = 0; x < 10; ++x)
{
serialized = NULL;
uint32 sub_length = 0;
const ItemInst* subitem = ((const ItemInst*)eq->inst)->GetItem(x);
if(subitem)
{
serialized = SerializeItem(subitem, (((eq->slot_id+3)*10)+x+1), &sub_length, 0);
//serialized = SerializeItem(subitem, 0, &sub_length, 0);
if(serialized)
{
tempdata = data;
data = NULL;
data = new uchar[total_length+sub_length];
memcpy(data, tempdata, total_length);
memcpy(data+total_length, serialized, sub_length);
total_length += sub_length; // This was set to length before
delete[] tempdata;
tempdata = NULL;
delete[] serialized;
serialized = NULL;
}
}
}

That loaded a full inventory without a crash and it is almost flawlessly loaded. The only remaining issue with loading the inventory like this is that it seems the amount of slots to load at once are either limited by the client or by the server somehow. Basically, the char I logged in has almost a full inventory for most slots including bank slots. But, it seems that since bank slots are loaded last, the client isn't showing all of the items in my bank. I first noticed that only the shared bank and last row on the right in the normal bank (last 4 slots) were not showing up. I then summoned more items to fill all of the bags in my normal inventory and zoned. After zoning, I see even less slots showing up in my bank. So, it seems like some kind of cut-off on how many items can be sent in a single packet. Maybe we have to split the packet up if it gets too big or something and send a second packet. Though, 2 packets should be enough to send all possible items unless maybe if all slots were full of multiple augged items, then it might take 3 packets or something. I am not too sure about this issue yet, but at least it is getting closer to working perfectly.

[warhawk]

The progess being made on this is amazing!

Congrats to the team and your efforts are really appreciated. I just need my SOF discs to turn up now :D

War

[trevius]

Thanks, Warhawk :) I am really glad that this SoF project is almost done, or at least almost as final as Titanium currently is anyway.

I just figured out the issue with the limitation of how many items get loaded. Turns out that the first number sent in the packet was labeled as "item_opcode" in the code, but it is actually just supposed to be the total number of items that the client should be loading from that inventory packet. I tried setting it to use itemcount, but that total doesn't include subitems like augments or items in bags, so we would need a way to count the total items for it to be truly accurate. Here is the code that is related to this issue:

data = new uchar[4];
uint32 *item_opcode;
item_opcode = (uint32*)data;
*item_opcode = 0x69; //0x35;

By it being set to 69 in hex there, it means that it is telling the client to load a max of 105 items and stop loading any after that point. I made this change to verify that it would work:

*item_opcode = 200;

And that let all of my items load fully :D So, it seems that it doesn't matter much if the number of items we list is over the actual number we want the client to load, just as long as it isn't under that amount. I assume we could set it to something like 1000 and not have to ever worry about it. But, it would probably be best to get a total item count to put there that includes all sub items in bags and augments as well.

Now, just to figure out how to get augments actually working :P

[mplayer254]

SoF still 5$ on Newegg.com, with free shipping!