Quick question guys,
for the most part is this already enabled? I was going to check this out when I have time, Just was wondering if this is set to go with normal server compile or is something else needed to be defined before compile?

It is disabled on the SVN revisions for now by default. Mainly because we don't want everyone to try using it on public servers and causing zone crashes due to any unknown bugs. Once it is fairly bug free and complete, it will probably be enabled by default.

For now, you just have to edit the /common/patches/patches.cpp and uncomment the #define line at the top to enable SoF. Then compile and it should be enabled.

Thanks trevius,
I hope i get time to mess with this coming up here, Your work on this has been amazing :)

I'm going to remove the define next time I commit fyi, it's pretty pointless to have it in there. Any server op that finds a patch causes a problem or doesn't want a certain client to be able to connect can just remove the patch register line.

And in the same sense if you want it off by default just comment out the code that registers it.

btw I'm very lost on items atm (I really wish I had a packet log from this client).

What do you need for a dump? I got my client today so could provide you with something in the next day or so.

LOL, tell me about it! One single packet log from 9/7/07 that had a person loging in a single time would have made this project 100X easier lol.

The only thing that has gotten me this far is help from the ShowEQ source and EQLive logs from ShowEQ and the rest has been just "best guess" work. The good thing is that even if something is wrong in the packet, most structures will still let you get in game. Then, once in game, I just check what is wrong and mess with the structure until it looks correct.

For items, if you can get one single item to load at all, I think getting the rest of it working won't be too bad. I am more than happy to tweak the items serialization. I just need something to go by whether there is just an encode being done in the SoF.cpp, or a whole new way of handling those packets. Once I see how you are doing it, I think I should be able to figure it out from there.

Here is what I would do:
1. Start with a character with just 1 simple items (cloth cap maybe) on them.
2. Try logging into the game with the serialization you have setup for it (shouldn't need to be perfect just yet).
3. If the client hangs, crashes or disconnects on logging in, then check the EQ dbg.txt file in the everquest/logs directory.
4. It should say something about loading the item and then have a number next to it. That number should be the slot it thinks the item is in.
5. If that slot is wrong, then slot_id is in the wrong spot in the serialization. Try moving it until it picks up the correct slot ID that the item is in on the character.
6. If it reports the correct slot, then we know we should be good up to that point. I imagine once it does that, it may actually load all of the way in game.
7. I don't think there were any new fields added or changed since SoF was released, so the total packet size should be the same.
8. Try inspecting the item if you get this far, and if the name doesn't show up, then name probably needs to be moved a bit.
9. The item might not show up at all if the icon field is in the wrong place. The position of this field is probably one of the most important for starting work on this. Really, I can't imagine that the position of the icon field could vary more than 20 bytes from where it currently is in the structure I provided. If anything, it may be sooner. I doubt it would be later than where it is on EQLive.
10. Once Icon and Name are showing up properly, it should just be a matter of checking item stats and verifying that they all line up properly. Maybe some super item with a little of each stat could be set just to show what fields are what.

I am very willing to help with the guess work of lining up the structure. I only need a working system to use to send binary instead of a string. Once that system is in, feel free to update it on the SVN and just leave the code in that sends the inventory as a 0 sized packet until we get the inventory stuff worked out. The 0 sized inventory packet is forced in the SoF.cpp for now in the clientinventory encode I think. Otherwise it tries to send the string and crashes horribly.

She needs the item packets from the server to the client. Unfortunately, that is something we have to make and cannot collect with the emulator/SoF client together. I have provided an example from EQLive (and can send more examples if needed), and I imagine that SoF should be the same or very similar to EQLive considering no new fields have been added as far as I know. The only things I can think of that might have been added may be herioc resist stats, but I can't really verify that. I am just going by what I see on 13th floor and other info I find here and there.

So far I've gotten: Client crash (but I figured it out), then created an empty item then moved some fields around and the item disappeared completely!

Ahh, sweet! At least it sounds like you are making some progress. If you can get an empty item, the rest shouldn't be too bad to work out. I think the only other hard part might be getting augs/bags working properly. But, then again, an aug/bag should just be items within items. Once the other fields are correct, it should just be figuring out where the item within an item should be placed.

Any way you could update the SVN with the version you had with an empty item in it? I am guessing that means you actually saw an icon for the item? If you made it that far, I am pretty sure I could get most of the rest of it worked out in a night or 2. As long as you leave the encode on the clientinventory to send a 0 size packet, then it shouldn't effect anyone who is just trying to log into SoF normally without items. I can just comment that part out so it actually tries to load items while I work on it.

Ahhh, I see. That's tough sledding uphill both ways.

I've got this now:
http://i8.photobucket.com/albums/a2/...e/EQ000001.jpg

I've purposely filled it with strings lacking null terminators to try to find the name area, and succeeded... sorta I still gotta nail down which one it is but it's a start.

Anyone wants to inform me what that green background means I'd greatly appreciate it. I've obviously got slot correct, but the rest of the header seems to be hit and miss. I have a feeling it's very different from the live packet you linked.

If i remember correctly it has something to do with evolving items.

Well, I would look at how the Titanium items headers are and compare that with the live one I posted. I imagine it is somewhere in between. If you have the slot ID right, then it should just mean that you have to add an int 32 or int16 extra into the header, so it doesn't pick up part of the header where it thinks name should begin. I don't know where that * is coming from, maybe you are sending the number 42 as an int8 which as a string gets converted to a *?

Oh yeah, and before someone tries it and can't figure out what happened, I wanted to mention that right now, you need to keep your character level at level 75 or less when using SoF. Anything over 75 (via #level) will result in setting your character's hps to 5 for some reason, even though everything else like skills and others seem to be ok. Then, if you try zoning at any level over 75, it seems to crash the client every time right after the zone loads. I think it is actually crashing when the spawns are sent, so it is probably an issue with the spawn struct that is causing it. I really hope that there isn't a restriction on the client that is causing the level 75+ issue. The actual eqgame.exe was created before SoF was released and was ran on Live when the max level was still 75. But since one of the key features of SoF was a max level of 80, I am betting that it isn't a restriction of the client, and instead, an issue with a struct that can be fixed. Maybe there is just a new field that needs to be set to allow a player to exceed level 75. Though, I would think at least with GM mode on, it should work ok, but it doesn't. I am sure we can figure it out at some point.

I have some live packet traces from July 2008 when I was working on the Pet Buff window. Maybe they will have some Item packets that are closer to the SoF structs than the current live packets. I'll upload them when I get home tonight in case they are of any use.

EDIT: Here: http://www.rama.demon.co.uk/EQLive-Jul24-2008.rar

Inventory begins at:

The green background was used for 2 things in EQ(at least) that I can think of. The first and the one you are interested in, is to indicate an evolving item. Matters not if it was fully evolved only that it does evolve. The second was in the bazaar in trader mode. Once an item was set with a price and added to the "selling" list the background turned green.

The "*" in the name indicated that is was a starting item given to you or something like that. The initial weapon, and backpack in the tutorial were like that and the burlap shirt given by the Guildmaster when you turned in your note all had the asterisk. There might be more, I think it had to do with making them not sellable to merchants, but I'm not 100% sure of that.

Yeah the * was just part of the string I was brute forcing. I'm pretty sure something in the header just wasn't getting set right. As I didn't actually change anything but the values in the header to get the name to show up... and no matter what I change icon seems to stay the same so I don't think I'm close to it yet.

And incidentally I found a packet log from a little after sof, but not same client version. It's pretty similar to derisions and both match up with my expectations of where things will be so we'll see.