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: