Oh yes they both start with a and I just freaking got home when I posted that after sitting through an hour worth of traffic =p

Figured as much. Also, if anyone else is willing and able to help with getting augments working, here is a good packet from EQLive that we can probably use as an example of an item with an augment in it. It also has Herioc Stats, so we can use that to make sure those stats are in the right place of the struct and to find exactly where augments should start:

This is from an itemlink I saw on Live the other day.

Here is a link to the item on 13th floor for reference of what stats are what:
http://eqitems.13th-floor.org/item.php?id=79862

And here is a link to the raw item info for it there:
http://eqitems.13th-floor.org/itemraw.php?id=79862

I actually had heroic stats working in my initial release of the item structure. I think they may of gotten messed up as you fixed the rest of it.

Oh, LOL! I will have to check into how you had it structured. I don't think I really adjusted anything down there, but I did move a few fields around which would definitely cause issues with that part of the structure if they aren't right.

I was mostly concerned with getting the stats that Titanium uses working. For the new stuff like Heroic Stats, I didn't think any of it was linked to the database yet. If you already set that up, then it shouldn't take me long to align that part again.

I think if I can figure out how to check if an item has an aug in it during the encode, I can probably get the augs in the right place. I think it would basically work like the if you have set to check if a bag has items in it. But, I just don't know how to check if an item has augs in it. I will look around a bit through the source and see if anything stands out that might work.

Well, after some quick testing by forcing the encode to send certain values, it seems that the way the structure is set now is perfect or very close to it.

I added these values to the encode:

itbs.backstab = 16;
itbs.dsmitigation = 17;
itbs.heroic_str = 1;
itbs.heroic_int = 2;
itbs.heroic_wis = 3;
itbs.heroic_agi = 4;
itbs.heroic_dex = 5;
itbs.heroic_sta = 6;
itbs.heroic_cha = 7;
itbs.heroic_mr = 8;
itbs.heroic_fr = 9;
itbs.heroic_cr = 10;
itbs.heroic_dr = 11;
itbs.heroic_pr = 12;
itbs.heroic_corr = 13;
itbs.heal_amt = 14;
itbs.spell_dmg = 15;

And here is an example of an item after forcing those values:

http://stormhavenserver.com/download...rioc_stats.jpg

Notice that they all match up perfectly :D

Anyway, I think that means that everything should be correct. The only thing we should need to do is figure out how the augs fit into the last 8 padded bytes in the structure.

I would think that the last of those 8 bytes is almost certainly the null terminator for the whole item or at the very least it is the null terminator for the last aug slot. Since there are only 5 aug slots, 5 of the 8 bytes should definitely be null terminators for those. That leaves 3 that I am unsure about. They are probably either 3 unknowns at the beginning of the 8 or at the end of the 8. One of them may also be clairvoyance, but I have no clue what that even is. Hopefully it wouldn't be too hard to figure that part out.

There's a null term for evolving data too I believe, so 6/8 should be accounted for.

I've broken down that item packet with the data structures that have been added to the SVN as of late night 2009-03-25.

About the only real difference between the structs and the packet, that I'm seeing, is that there are 6 EffectSlot entries on both items. The structure only lists 5. Plus, the int8 seems to be a 0 terminated string. (Code may already handle that, I just looked at the structures.)

Unk131, from struct ItemTiertaryBodyStruct, if that one is named after the Unk131 from the EQ13thfloor item dump, then it should be a flag to indicate that Endless Quiver doesn't work on the item. (I've found exactly one item that has it set in the DB, Shadowspike Arrow Digging through the ranger board seemed to indicate the endless quiver relationship.)

The actual item structure is preceeded by a 68 byte header. Format looks to be 17 DWORDs.

The actual aug encoding seems to be fairly straight forward, trailing after the main data for the item is an int32, it seems to indicate the slot the aug is slotted into. Following that slot number is just a repeat of the item format, this time for the aug.

Below the break down of the packet, in case it is actually helpful. This is pretty much just a copy of my work notes, I hope it doesn't end up being too confusing.

Thanks Leere. I have basically been doing the same thing. I also broke down a single item without an aug for comparison. Seems like live has an extra 5 bytes somewhere at the end. I would assume that it is from new fields that are just unknown atm. I have been trying to split it all up to make sense, but haven't came up with a good solution yet. I had thought that augs were actually contained within other items, but judging by these packets, it seems like they are completely separate from each other. Though, I agree that the 01 near the bottom is almost definitely signifying that the item has an aug. Seems like the EQLive packet isn't the same as the SoF ones, but at least they are very very close. I am sure we can get it working, just need to experiment.

Here are my current notes just for reference:

Have you tried being primitive about the ending, and just assigned it as two int32s? The first being clairvoyance and the second being a combo list-terminator/aug slot number?

Using the structure already found for SOF, taking the 0x00000001 to mean slot 1, since the item has aug slot #1 set, could work nicely. Wasteful, sure, but they might not have cared for a packet that is only sent rarely. (Support for that idea should be found in the fact that they are sending the majority of data as 32 bit ints, when they could just go for 16 bits as well. Live items have only started in on 4 digits for HP/Mana/End, lots of room left until a short isn't enough.)

The list terminator would work on the principle of a non-zero value meaning that there is item data following, which is mounted in the aug slot indicated. A zero would be the end of the list.

The clairvoyance at least should be easy to test, given that you've been able to inject the heroics above. (Side note, I never knew that they made heroic resists, those aren't actually used on live, as far as I know.)

If you're playing around with the fields, some ideas for what some of the header unknowns could be: power source charge, copy item (found on test, they just set a flag to disqualify items from being tradded, sold, used in quests, ...), inst_attuned, evo level (both max and current perhaps).

I'd play with them myself, but I don't have access to a set of SOF discs currently. I've been meaning to work on adapting a legacy version, but the additional format changes are a pain....


As a handy reference, an item ID for an item that actually uses the string field in the effect structure to override the name.

34158 - Fabled Ring of Flamewarding - Changes the name of the focus effect from Sothgar's Rancor to Focus of Flames, thus retaining the focus name of the non-fabled version but boosting the actual effect.
fabled item version
non-fabled item version

My apologies if this particular feature is already well handled, the structures just seem to hint at it not being the case.

Ahh, that override for the effect names is really cool. That could let us adjust items using any spells we want and then name the effect anything we want without requiring a custom spell file download. I figured it did something like that, but had never seen an actual example. There are still alot of things about items that need to get coded, but it is always good to know what options we have to possibly add in the future.

BTW, if you are going to look at items for comparing to the structures or packets, you are better-off using 13th floor instead of Alla's. The raw data from 13th floor is ordered in almost the exact order as our structure is, so it is much easier to reference and it helped alot to make sure our structure was as aligned as possible.

Other than augments, the only other thing I would really like to figure out about items is the cooldown stuff. I haven't seen anything that shows me what tells the client how to show the greyed out items ticking down until they aren't greyed out anymore. Recast delays do work properly, but all items with cooldowns in SoF currently always show as grey and never tick down to normal like on live. The weird thing is that I swear Titanium has the same greyed out cooldowns, but something disables them permanently after the first time you build the server, and I don't know what it is. I have heard a few reports and witnessed it myself as well. The first time after building a server from scratch, I saw the cooldown timers grey out items after use and actually tick down until the timer was up and it was ready to be used again. However, the next time restarting the server after that, the items never grey out or tick down ever again. No items do. And others have seen this same thing. I would love to figure out how that is handled for SoF and get it working properly as I think being able to see the cooldown is important, or at least nice to have :) I also figure that if we can figure it out for SoF, we can fix it in Titanium with the same change really easily.

I will keep messing with those last 8 bytes and see what I can figure out tonight.

Also, in case you didn't know, you can get SoF for $4.99 with free shipping from newegg while they last. Since you said you don't have SoF yet, this is a hard deal to pass up. Sounds like you have enough experience to definitely help out on finishing stuff up. I know your name from somewhere, but I can't recall where. Maybe you submitted code in the past or something? Keep in mind that I am not a coder really, so some technical terms will go over my head. I just look at the stuff and figure it out without knowing what things are actually called lol. I really should start actually reading and training on it, but learning it from examples has worked out fairly well for me so far :P

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.

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:

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.

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

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:

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:

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

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