I am starting work on getting EQEmu to work with Secrets of Faydwer, since it appears that it will be the last retail pack that includes all previous expansions that SoE is going to offer. Currently, I am just trying to be able to log in with it, but no luck just yet. I pulled a bunch of opcodes from SEQs nearest release to when SoF came out, and put them into the anniversary opcodes file (since I can't seem to get it to compile when I create SoF patch files). I think I can still pull more opcodes and see if that helps, but at the point it is failing, I think I will need to start trying to find the structures from SEQ and edit them into the EQEmu code.

Just wanted to mention that I am starting on this, in case anyone else is interested :) I figure that if I can get it to at least log into the world, I can start working out the rest of the opcodes and structs from that point on. Once we have enough for basic play, I think it will be ready to update the SVN with it and all can work on it together. I figure that the way Derision used to pull opcodes from 6.2 and find the opcodes in Titanium should work for finding SoF opcodes as well.

Not getting very far yet, but I am determined lol. I figured that with a bit of research and learning a few things, I can make at least some progress. ATM, I think I still need the proper Opcodes to use for SoF. Once I have those, I think I will have to start on Packet Structures. I have found some decent info from the source in SEQ, but it is hard to tell which to trust, EQEmu source, or SEQ source lol.

From my EQ Debug Logs:

So Far, I have the following Opcodes correct for sure:

And, now I need the following to make further progress:

I found OP_SendLoginInfo by watching the opcodes coming in by using a tail on the server logs. I am starting to get the hang of reading through the disassembled code and that is how I found the OP_PostEnterWorld opcode. I haven't been able to find any using Derision's method yet, but right now, I am just feeding through the ones that have text in the code that I can reference. I found "WorldAuthenticate. Access granted" in plain text of the disassembled code and by referencing the code from Titanium and the known opcodes, it wasn't hard to find the correct one for SoF. Hopefully, as I become more familiar with the disassembled code, I will get better at finding this stuff.

There's a lot of different things we'll have to deal with with the SoF client too. Death and out of combat regen are a bit different and probably a billion different structures. Good luck, you're braver than I. =p

Ya, I figure if worse comes to worse, at least I am learning something along the way, which is always a good thing :)

My current plan is to find as many opcodes as I can. I think once I get the hang of it, it won't be too bad to find many of them. As long as I can get the important ones going, then I can move onto the next step. The next step will be to see if I can figure out how to collect packet structures from EQLive, and then compare the Titanium structures to the Live structures and see if I can figure out what might work for SoF. I imagine that the structures from SoF are still fairly close to Live in alot of ways. By looking at the added features from each expansion, it might not be too hard to figure out what to add/remove and where. I think then the main issue will be making sure that everything takes up the correct space in the structs, since that will be hard to guess. Once the old and new structures are compared, we can probably narrow it down to a few questionable pieces and try to resolve those. I also think that SEQ source might be of some help. Though, I am not sure how exact their structures are for their releases.

Nothing ever gets done by lack of trying. Gotta start somewhere I guess, lol. I figure that if I can get a good start on this, maybe some people will see the progress and jump on board to help and finish it off quicker.

Also might be worth seeing if showEQ has a patch that matches with SoF client, not sure if you have or not. They usually figure out most of the really big structures and opcodes.

Ya, SoF was released on November 13, 2007 according to it's wiki page, and SEQ has patches for Nov 21, 28, and Dec 17. The Opcode update wasn't until Dec 17.

Here is the list of SEQ releases:
http://sourceforge.net/project/showf...ckage_id=13256

Here is a post about some changes after the expansion:
http://www.showeq.net/forums/showthr...3&page=5&pp=15

And more changes discussion after the patch here:
http://www.showeq.net/forums/showthr...?t=5943&page=4

The Opcodes I could find from the SEQ code don't seem to work. At least the ones I have tried so far. Though, I don't think they change them all with each patch, so maybe some of them will still work.

At least it looks like they have some good struct info, or at least something to work with. It is too bad our 2 projects don't really work together, because we could both share the load in working on stuff like this and EQEmu would have been updated long ago :P

Here are some of their change logs to give a timeframe idea of what they did and when:

So, it looks like we should be able to get at least some needed struct stuff from them, and maybe some opcodes, if they didn't all change by the time of the Dec 17th update.

Wow! I found some more good opcodes from the SEQ code that was just mislabelled on the date it was last updated. I finally made it to character select :)

Here are the correct Opcodes so far:
I found them in a file attached to this post:
http://www.showeq.net/forums/showthread.php?t=5975

Here is where it is failing now, from my EQ Log File:
Not much info from there, but from the tail I am running on my server logs, I found this:

I pulled some more opcodes from the SEQ source. I didn't get them all yet, but from what I can tell, most (or maybe all) of these seem good so far:

At this point, it looks like I need to resolve a struct issue with ClientZoneEntry to progress further forward. I have tried variations of structures, but none seem to work yet. I am starting to think that the error I am getting is from the player profile structure being wrong and not the structure for getting the player's first name from ClientZoneEntry. I will go through the player profile structure next and compare them. But, if my logs are correct, it looks like alot of the structs we currently have are already correct. Here are my most recent logs (I marked in RED where I think the current issue is):

Hmm, I guess the section in red in the logs above aren't the issue. That seems to be normal when I compare it to these logs from a Titanium login that works:

The previous logs are all grepping on "0x" to catch all opcodes. Here are some more detailed logs of exactly when the failure happens with the SoF client:
It looks like it happens right after the OP_WorldComplete comes in, so maybe that has something to do with it.

Wow, nice work trevius. I can't help in the slightest, but I make a decent cheerleader. :)

Go Go T!

I have been working alot on this over the past couple of days, but I am still not able to get in world yet. I am not exactly sure what is killing it yet, but it appears to be related to the structs for the playerprofile not being perfect. Here is the log from my EQ Debug Logs:


And here are the complete unfiltered logs from the emulator with all logging turned on:
The log above comes after this happens, which almost makes me think it is an issue with the spawns struct:

I have been able to get most of the opcodes I need from the SEQ source and some from looking through the IDA assembly code. I am still missing some (like the task stuff and a few others up to the point that I need), but I think the current issue is with the structs. Though, maybe the correct opcodes are needed for the playerprofile to build properly, I don't know for sure. If I can get it working to the point that I can get in game, I will update what I have onto the SVN and just use the files setup for anniversary, since I don't think we ever plan to use that expansion now anyway. And if someone knows what it would take to rename all of those files to SoF, they can do that at any time. I tried, but couldn't get it all working properly when I did.

Also, I am getting what appears to be 2 more CRC checks that don't exist in Titanium as far as I can tell. They come in right after the CRC1 and CRC2 check, and before the Ackpacket and WorldClientReady packets. They are the same size (2056) as the CRC checks, so I assume they are 2 additional CRC checks. These occur when I am connecting to character select, but I am guessing that since the server isn't actually handling them, that it shouldn't really matter anyway. My guess is that they are sent so that the server can disconnect you if they don't match (when playing on live). Since the emu doesn't care if they match or not, it probably isn't coded to disconnect them if they don't match. So, I am guessing that not having the opcodes for them shouldn't really make a difference. But, here are the logs from them anyway:

The new Opcodes for them are 0x22CF and 0x43BA.

And right after the AckPacket and WorldClientReady, I get this new opcode 0x58FB, which I am not sure about either:

Judging by what I see from Titanium clients, this doesn't exist. At least not in the order I have seen them in. It could be that it is an error from not getting anything back from the CRC checks though. Either way, these are all coming in while getting to the char select screen, which loads fine. I don't think they are related to the reason I can't get in game, but worth noting at least.

EDIT: After looking into it a bit more, this 3rd unknown opcode does show up when connecting with Titanium as well, only it uses 0x6A5F, which from what I can tell is the auto-AFK opcode. It is "unknown" in Titanium as well and doesn't cause problems, so it shouldn't be an issue at all for SoF. I am pretty sure we can at least ignore this particular one (0x58FB), since it appears to be AFK related.

I finally made a little more progress. I am 1 step closer to being able to get in game now lol. I have been trying to figure out the size of the playerprofile struct so that I could at least get the EQ Debug log to show me reaching the next step. After trying many other ways, I finally figured it out by looking at the IDA Assembly code and finding the error I was getting and then checking the HEX for that was causing the error to happen. I checked the HEX and it came out to be 5C18, which is 23576. I checked IDA for Titanium and the same code matched the PlayerProfile size for Titanium (19592). I did another compile with the new structure size and now I am getting this:

So, there is definitely some issues past that point, but it is a step in the right direction lol. Now to figure out what caused the crash... My first guess is that the problem is related to the items structure, since I know at least the following fields were added at the time of SoF release that weren't in Titanium:
heroic_agi
heroic_cha
heroic_dex
heroic_int
heroic_sta
heroic_str
heroic_wis
I also see these that aren't listed in my Items Table currently, but they may just be newly discovered Uknowns that already exist, but aren't labeled properly:
spelldmg
backstabdmg
clairvoyance
dsmitigation
healamt

I am not sure if that would cause a crash or not, but I guess I will try adding those and see what happens.

Not that it really means much to me, but this seems to be the part where those errors get generated if it isn't equal to whatever check is being done here:

According to the script from 13th floor that dumps items, here:

http://eqitems.13th-floor.org/svn/sc...ump/fields.txt

It looks like the current list of item fields is in this order:

So, I guess all of the extra fields I posted in the previous post were actually new. I know the herioc stuff went in with the SoF release, so I just need to see if I can find in the patch notes when the others after healamt were added. Then, I should just be able to fill in the anniversary (using anniversary files for SoF still) items file either with these new fields, or maybe just set them all to 0 so that the correct number of fields are at least being sent. The heroic stats do sound cool and should add more variety for possible upgraded gear in the emulator. For anyone that doesn't know already, apparently they add more stats that can increase the cap of the particular stat it is adding to, so you can exceed the caps with the stats from them. That shouldn't be hard at all to code if we can get to that point.

I spent most of the day working on this, but this should be the item field list order that is currently used on live according to 13th floor collects:

I will try this as soon as I get home tonight. I am guessing that the following fields were added after SoF, so I will comment them out for now and try adding them 1 at a time until it works (hopefully):
Note that the item field numbers are not correct, but once I have the list working, I will renumber it all manually.

Also, the only thing I am not quite sure about here is the use of quotes on ints and nulls. Does anyone know if I(0) is the same as I("0"), and if S("") is the same as NULL, or if there is a better way to put NULL there? Maybe something like S(NULL)?

Have you checked Macroquest sources from around that time? I would assume most of the structs are in there.

I already looked into it a little, but Macroquest reads directly from memory and doesn't do any kind of packet sniffing as far as I can tell. So, it uses offsets and such, which might possibly be useful for figuring out something, but I don't really know what to do with them personally.

Just thinking that by comparing MQ Titanium/Emus structs to MQs SoF structs would make it far easier to figure out what new fields need to be added to Emus structs that need to be send to the SoF client.

Im thinking that say a items struct is sent to the client in the same formate its readable from memory. I dont know if this is true, but if it is, looking at MQs SoFs structs should help a lot.

Wow, way above my skill level so all I can do is cheer you on.

Just one thought though, perhaps the correct fields could be found by looking at stats on items that were released with SoF.

I think clairvoyance and healamt were on those items but they could have been added later.

Like I said, MQ reads from memory and is written in a completely different way than our packet structures. They use offsets that line up directly with the assembly code from the eqgame.exe, and so their format is completely different. Possibly if I was very familiar with the MQ source, I might have an idea of how it could be useful. Unfortunately I might as well be trying to read in German (which I don't know how to do), because that is about how different the code is from the emu source.

I figured out last night that all of the fields I had listed in my last post were actually in with the SoF release. The only one I am still not 100% certain about is the evolving items part. According to 13th floor, I saw it mentioned that evolving items need their own separate table and have a separate opcode (I think) if the item is able to evolve. Hopefully setting that field to 0 will just disable evolving so we don't need to write anything for it until we are at a point where we can do it at leisure. As far as the item field list for SoF, I think that I now have it 100% (or very close to it) complete. This is good, because it is 1 more step closer to being done, but the bad part is that it didn't fix my current issue.

I looked into it further last night and checked the debug where I am crashing in SoF vs a debug of a successful Titanium connection. I then compared a few things in the Titanium assembly code to the SoF assembly code. I am pretty sure that I have narrowed the current issue down to the Spawn_Structure. Unfortunately, I think that structure is by far the worst and hardest part left of getting SoF to work with the emulator. Out of all structures, the spawn struct gets completely moved around with almost every patch. I was able to find the packet size of 385 (HEX is 181) for the Titanium spawn struct by using the hex calculator here http://www.squarebox.co.uk/hcalc.html (very useful when messing with the assembly code), and then searching for 0x0181 in the assembly code. I found the same section of code in the SoF assembly code, but I was unable to figure out what the struct size was. Since this technique worked perfectly for finding the struct size for the player profile, I think that means that the new spawn struct for SoF is now a variable length struct. I checked the current SEQ source code and it lists it as variable length, even though the SEQ version from when SoF came out shows it as a fixed size.

I don't know anything about variable structure sizes or what to do with them. The spawn struct also seems to use unions, packet padding, signed and unsigned ints, all of which I know absolutely nothing about... All of the other structures are pretty straight forward and I think most of them should already be ready to start working once I get the spawn struct correct. This is probably going to be the biggest hurdle to getting SoF working.

I am still going to do some further testing on Titanium to see if I can duplicate the exact crash I am having on SoF, which should help narrow down the exact cause of the problem. That technique has already helped me multiple times in figuring out what is causing a problem.

I figured this stuff was over my skill level too, but so far, I have learned alot just reading the structures and forums here and SEQ forums. I have been able to do alot of things that I didn't expect to be able to do. So, even though it might sound above your skill level doesn't mean that you wouldn't be able to figure it out if you put some thought into it :)

Here is a link to the post from right before when SoF was released stating that he was able to get the spawn struct from the eqgame.exe and that it should be fully accurate:

http://www.showeq.net/forums/showpos...4&postcount=21

Since that struct didn't change in the update following the SoF release and they said everything in SEQ was still functional, I am wondering if it is safe to assume that it is correct. Ultimately, I wish I knew exactly what he did to pull all of that info from the .exe and if I knew that, this would be simple.

Here is the Spawn_Struct according to SEQ at the time of SoF (and a few patches later as well):

Part of the problem may be that I had to change this considerably to fit in all of the stuff that EQEmu currently uses for settings on spawns within the same number of bytes. Also, I don't know how to count the signed and padding stuff, so my structure size may be off.

It is still possible that something else could be the cause of my crashes, but at least by fixing everything as much as possible now, it will mean less work later. I am glad that the itemlist stuff is all done now, so it should hopefully work as soon as it is ready to get to that point :D

Well, I guess I was looking too hard for the spawn struct size lol. I simply converted the 897 to HEX, which is 381, and then searched the SoF eqgame.exe code for 381 and found this:

And, when I changed the Titanium spawn structure size and logged in, it didn't crash, but it did time out and put out this debug log from the normal EQ debug file:
So, it sounds like those guys at SEQ might be correct with that spawn file after-all. Now, I just need to figure out what is being done on SoF that is causing a crash. Anyone know of a debug program that could be run on Everquest?

Anyone know of a debug program
 

Anyone know of a debug program that could be run on Everquest?

Yes i use w32dsm89
will allow you to read it in asm lang plus debug the program all in one.
send email addy and i'll be happy to link ya to them don't want to post
anything againts the rules.
What i'm doing is looking at the code with
w32dsm89
etu-dasm-32/16 bit disassembler v 2.22 alpha
i really think etu-dasm would help you out
more as it will allow you read more info
in english so you'll understnad it better.

i been following up on what your doing.
what i'm intrested in is getting the expanshions
to read 15-15 etc. i noticed your not letting
us know what ver of peqserverpack.. 80) as well i
change the opcode OP_EnterWorld=0x7cba
put in patch_Anniversary.conf and opened
fos got into char slect screen.
i was using the newest ver
ActivePerl-5.10.0.1004-MSWin32-x86-287188
PEQUpdatePack-4.0-1129Rev233
mysql-5.0.51a-win32

When you say you want expansions to display 15 out of 15, do you mean at the server select? I don't think there is anything we can do about that. I am pretty sure we would have to adjust the login server source code to fix that. That isn't an option, because no one has access to it that is active around here these days. Titanium shows the wrong number of expansions, and SoF shows 0 of 0 expansions. Luckily, that has no effect on how the actual server handles your connection, it is just a display thing.

The version of code or database I am running doesn't really matter, but I am using one of the latest revisions from the SVN, R238. My database is about a year old PEQ one that has been updated by me for my custom server. The changes I am making should be able to work on any version once they are all done. If I can get it working, I will submit any needed changes for database tables once we get to that point, but for now, I am doing everything without relying on database changes.

My current status is that I worked all night last night trying to duplicate the same crash on Titanium by throwing off the structure format by increasing or decreasing the size of certain pieces of the playerprofile structure. I couldn't once get it to crash the way that SoF is, and it actually made it in game almost no matter what I changed, but it did make things wrong like plat, levels, etc, because the structure info wasn't aligned properly. I also tried to remove all of the opcodes in Titanium that I don't have correct for SoF yet, and that didn't cause a crash either.

The spawn struct seems like it should be ok, and the player profile looks like it should be very close to correct, so I am still trying to figure out what is causing the crash. I am wondering if something else was added to the playerprofile struct that we don't know anything about. There were 1032 packets added to the end of the structure sometime between the Titanium to Anniversary time period. I have no idea what that 1032 is supposed to be for, but maybe that is the cause of the crash, since we aren't sending anything at all for it.

After spending hours working to get to the next step towards getting in game, I finally made some progress.

It turns out that it was the spawn struct causing that after-all. The EQ debug info isn't very helpful (but much better than nothing!), because it appeared to be crashing at the point of getting the player profile. After messing with the player profile, no matter what I did to it, I couldn't duplicate the crash on Titanium.

I think I am probably only a couple smaller structs away from getting in game now. All of the big ones should be ok enough to get in at least, I think. On to solving the next crash point problem :P

Just to test, I made a new level 1 character (on a Titanium Client) and deleted all of his items and attempted to log him in with SoF. So far, I got further than ever :)
I think I just need to track down a few more opcodes and I should be able to at least get a naked level 1 in game. Then, I will have to work out if it is AAs or Items or something else causing the crash when I try to log in my GM character that I have done most of the testing with. Still making progress, and getting much better at finding opcodes in the assembly code. I still can't find every one of them using the comparing method, but I can probably find about 50% that way :)

Trevius is our hero.

While it is good to know some people are following this post, I think it would be best to keep the clutter down if possible. I am hoping that I can get it working enough that others might be able to start assisting me at some point and it is easier to read if there is less clutter. I do appreciate the cheering on (it is alot of work so far), but this thread isn't really the place for it. Besides, until it is at least somewhat usable, there isn't much to cheer about. There is a good chance that we may never have enough info to get SoF fully functional. I am trying to stay positive about it though lol.

I have already learned a ton over the past couple of weeks just playing with the different sources I have available to me to get them all frankenstiened into something that will at least let us log all of the way in. If I could read the assembly code better, it may eventually be possible to pull everything we need straight from there, but I am still a good ways from being able to understand it enough to do that.

Currently, I am trying to understand the item serialization code. I have the full itemlist for SoF, and I think it should be very close to accurate. But, until I know how to set the serialization up so that it works with my new list, I can't load items. Other than that, I already have a large amount of the bare minimum opcodes needed to log in. There are only a few more I need to have a complete list. Here is what I have so far:

The V means it has been verified either from the client, or from IDA or both. This is about 95% sure to be accurate. The V? means I verified it from IDA, but the code isn't an exact match, so I am only 50-75% sure it is accurate. The ??? means I was either unable to find it at all in IDA, or that I found it and it doesn't look like a match to me, they are likely to be wrong.

I think if we can get all of those, I may have enough opcodes correct that we can at least log in a naked character all of the way. Once the item serialization is done for SoF, we should be able to login geared characters as well. I think the main opcode I need to be accurate now is the doorspawn opcode. I think that also sends objects in the zone and seems to be where the naked test character is getting hung up at.

Like I said, as soon as I can get any character logged in all of the way, I will submit my changes to the SVN so others can assist with it if they want. What I will probably do is set it so that the Anniversary files (that I am using for getting SoF to work currently), will not be used by default on new builds. It would be disabled by a simple define and could be easily enabled by anyone who wanted to mess with it. I will post how to enable it if I can get to that point. It will just mean a simple 1 line code change to enable it (uncommenting a #define). The reason to leave it disabled is so you don't have players trying to use SoF and crashing zones if there are issues with it that cause crashes.

Here is my new updated itemlist incase anyone knows how to write the item serialization code to use it properly:

Here is a piece of the log from the EQ Debug showing where it is currently failing:

If we're still looking for newer structs (after 2006), we can peek into the SEQ SVN. Specifically, SoF structs should be in Rev 686 (11/5/2007), Rev 688 (11/21/2007), or Rev 690 (11/27/2007). Since, according to Wikipedia, it was released on 11/13/2007, we'll probably want to look at Rev 688.

Ya, I have been using all of those to get as far as I have :P They have been very useful.

Even though SoF was released on 11/13/07, it was actually built on 9/7/07 (according to the EQ Debug Logs). So, anything from 9/7/07 to around the beginning of 2008 is probably useful. They may have patched in some of the SoF stuff to live before it actually came out, so the structures and stuff may have already been there for the most part. The main thing that would have changed alot are the opcodes. Unfortunately, most of the opcodes in SEQ weren't updated until after December, so many of them aren't correct.

I am thinking about trying a current version of SEQ and running a trial live account just to see if I can find 100% accurate structures that can be used to help getting SoF to work. I am betting that the current live structs are probably closer to SoF than the Titanium ones are.

If anyone has packet collects from right around the time that SoF was released (preferrably from SEQ if possible), I would love to get a copy of them. I think that would help alot once I knew what I was looking at. But, I am not holding my breath to get them, because I doubt anyone has still them.

I am not really sure what it is for, but a code obfuscater was added to SEQ around the time that SoF came out. From looking at the comments around the code for it, it appears to be used for pulling opcodes directly from the assembly code of the eqgame.exe. I have no idea how it is actually used though, or if I am just misunderstanding what it does. I have seen comments about it on the SEQ forums that seem to say something about opcodes changing from time to time when you zone or log on other characters/servers. I guess it is some kind of simple encryption or something. But, it seems that the new obfuscate can pull an opcode table from the exe file. If that is true, maybe we can use it on Titanium, and then on SoF and compare the 2 tables and compare the conf files for known opcodes and match them up. Here is a link to the obfuscate getting added to SEQ SVN:

http://seq.svn.sourceforge.net/viewv...85&pathrev=686

I moved this to the development section, because it seems more appropriate.

I figured out where it is currently breaking when it is trying to log in. It seems that the opcode OP_SendExpZonein=0x3703 is where the problem is. This is the last opcode that the client receives before it stops responding. I also verified that by removing this opcode from Titanium it will fail at the exact same point according to the EQ Debug Logs.

Actually, in Titanium, the log entry is slightly different, but it is the same thing just renamed:

My guess is that this opcode now needs to be encoded like many of the other important ones. And since it isn't being encoded, it isn't recognizing it, so it is failing. I am 99% sure that I have the correct opcode set for it.

Looking at the place where it is failing, here is the Assembly code for it:

And, from client_packet.cpp, here is the code that handles that opcode:
So, either the opcode needs to be encoded, or this handling code needs to be changed. I am guessing the opcode needs to be encoded, because the jump is looking for anything that isn't 0, so I would think that it is just making sure it got something for it. And, if it isn't encoded and is supposed to be, maybe it shows up as 0. But, if it doesn't need to be encoded, I don't know why it would be 0.

I will mess with it and see if I can figure out how to get that opcode encoded, but I don't really know how that will work, since the only opcodes I see currently getting encoded already have structures tied to them, but I don't see one for SendExpZonein. Unless maybe it is named differently.

At least I know where it is failing now, so I should be able to come up with something to move it to the next step. It should be getting pretty close now. I was able to find and verify more of the required opcodes for logging in over the past couple of days as well. Making some progress at least :)

I am still stuck at this same point, but I am not giving up that easily :P Last night, I started trying to figure out why character creation wasn't working. I have the correct Opcode, but I see that the server is expecting a struct to come in and the client is sending just the opcode with a size of 0. The client just hangs probably waiting for something back that we aren't sending. I am going to try filling in the needed character select stuff on the server side and then have it send the character create opcode back to the client. So, it would be working in reverse of how Titanium does it. If that works, then it means they might have been adjusting the order of server/client communications, maybe to optimize some stuff.

If so, maybe that is the reason that sendexpzonein is failing. It could be waiting for something else that we aren't sending. I will try forcing a few of the packets that normally follow the sendexpzonein and see if that makes any difference. I definitely see it is doing something extra in the assembly code of SoF that wasn't in Titanium, but there is no way to really tell what it is. It could either be waiting for an extra opcode that got added to the sendexpzonein stuff, or it could be waiting for a new structure that we don't have in Titanium. I am hoping it is the former, not the latter.

Other than that, the other big difference I notice is that some of the subs being called in area where the problem is happening have about 1000 set as the variables where Titanium has about 800 set. That makes me think that it is checking the size of a certain packet structure, but I don't know which one. If I am right, I think that one of the structures needed at this point has changed and we need to figure out which one and what it was changed to so it can be adjusted.

My last resort will be to setup the current showeq for Live and setup a trial account to watch the logs from SEQ and see what the current structures really are. I am sure that some of the SEQ structures are correct, but there is alot of info they don't need for SEQ to function so it probably gets ignored. Maybe I can find more details and get them filled in to get it working. Also, it would help to see if anything new is being sent. Unfortunately, I don't have any SEQ logs from when Titanium was running on Live, so I don't have anything to compare with. That will probably make feeding through this stuff considerably harder.

From looking at the MQ2 source, I found a few more item fields that may be needed for SoF to load items properly:

HeroicSvPoison
HeroicSvMagic
HeroicSvFire
HeroicSvDisease
HeroicSvCold
HeroicSvCorruption

MaxPower
Power

I imagine that the Herioc Resists are almost certainly required fields. The Power and MaxPower fields may not be required though, I don't really know much about them.

Maybe the MQ2 source can be useful after-all. After looking at it again, some of the stuff in there is starting to make more sense to me now that I am getting more used to looking at the assembly code from eqgame.exe. I found that MQ2 even has a version for the SoF retail eqgame.exe by looking at the debug from SoF:

And then at the MQ2 build for that date, it wants this exact version (seen in the MQ2Main\eqgame.h file):

So, that tells me that everything we needed to build EQ for SoF was actually already in place at that time.

This should also mean that SEQ structs and maybe some opcodes from that time might be useful as well. Unfortunately, SEQ wasn't updated between 3/25/2007 and 11/05/2007. It was just not functioning at all for about 6 months in between there. They finally got it working again in November right before the actual retail release of SoF. But, at least this confirms that I should use certain older structures over some that were changed after that.

After being stumped on this a while, I finally decided to take a step that would hopefully help me alot. I paid for my old EQ account so it could play on EQLive again. Then, I got the current version of ShowEQ working and put a hub in my network so I can sniff the packets to/from EQ. This is letting me watch the logs directly from EQLive that show pretty much everything I would need to get EQEmu working with EQLive. I am hoping that EQLive runs pretty close to how SoF did, and it should since there haven't been nearly as many changes to Live since SoF as there was from Titanium to SoF.

Already, I have found that the order of packets when logging in is pretty different from Titanium. I think I found the place that is stopping me from logging in all of the way. I just need to work on it some more to get it past that point. From what I can tell so far, it looks like this will be more helpful than anything I have tried. I am hoping to make more progress tonight now that I have this new information.

Here is an example of the logs of zoning in. I cut out a bunch of the actual data and stuff. I also made notes next to some of the packets.

SEQ isn't converting network to host byte order on the raw soe opcodes but here:

Connect Request
int crc length 0x00000002 = 2
int session id 0x6b0bee8f
max packet size 0x00000200 = 512

Connect Accept Reply
int session id 0x6b0bee8f
int encode key 0x45d7b502
char crc length 0x02
crypt options bitfield 0x0201
max packet size 0x00000200

Network Status Update - not really important.

[code]Dec 31 2008 05:43:05:722 [Raw] [Client->Server] [Size: 86]
[OPCode: 0x0300]
000 | 0a 00 09 00 00 94 35 00 00 00 00 4a 00 09 00 01 | ......5....J.... [code]
Combined packet

contains:
The first packet isn't a soe ack you can tell by the opcode and the fact that it doesn't include a sequence number. Likely some kind of I am ready for this info packet.

This is an ack packet, tho it looks wrong, they're usually 4 bytes total including the opcode 2 without this one is 7 byte with the opcode 5 without. The opcode is SOE_ACK tho.

These are standalone packets, encoded and compressed with a 2 byte sequence on the top probably 0x0000 since this is the first and a crc on the end. It's also possible to combine packets within an 0x0009 packet but you can't combine a raw packet and an eq packet inside the 0x0009 they both have to be EQ packets.

This is a fragmented packet like 0x0009 they are encoded and compressed they have a sequence number for recombining and a length byte. These are used when the data chunk being sent is larger than the max frame size sent on init: 512.

I know this doesn't help at all for figuring out what you need for the SoF stuff but maybe if you understand how the raw protocol works you'll understand it a bit better.

Ya, at least that clears a few things up that I wasn't quite sure about. I was ignoring the 0300 and 0900 because I figured they were doing something like that. I think 0d00 is also something like that, I am guessing raw packets that need to be encrypted? Either way, I ignore those as well :P

Just familiarizing myself with the packet logs, I started breaking down the structure for player profile to see if I could verify what it should look like currently for EQLive. So far I am almost done with it and will post the finished version when it is completed. I think it will help to have an accurate player profile with SoF once it is working at all.

Right now, I think I am really close, but I am doing the same thing live does and the client just stops at that first main loop every time. Maybe I have something messed up earlier on and it isn't figuring that out until that point. Or, maybe I have to have the AA stats opcode for it to continue, and I don't. I have almost all of the ones I need, but that one is really elusive to me lol. I can run Titanium fine without it, so I think it should be ok to run SoF without it, but no way to know for sure.

Basically, this is the order things happen on Titanium in the emu for the part I am having a problem with:

And this the order I am seeing from live for that same part:
So, I think SoF is supposed to be set the way Live is now. But for some reason, it still isn't working yet for me. I have tried both ways and more and the client never responds with the SendExpZonein as it should, or anything else for that matter. It is like it is either waiting for something that hasn't come yet, or something came but was messed up in format.

Well, I will keep plugging away at it. I learn more each day and it will help alot once I actually get to the point where I can start cleaning stuff up so people can actually use SoF to play.

Here is the example right from the logs from Live:


Here is the full 0x5821 that I am gonna check and see if I can find what it is: