My EQLive folder is 5.63GB, eqgame.exe modified on jan 9th, eqmain.dll modified on jan 9th.

The acct I patched with has only a few expansions I think whatever titanium had with it. =p

To add another data point, I can't connect to the LS with the live client either. I ran the patcher today, but it looks like eqgame/eqmain haven't changed since December:

I bought the Anniversary digital download a year or two back, so that's all the expansions I have.

Titanium EQmain.dll is 2005 Live patch is 2008 thats why you are not connecting, So swap your live one with the titanium one then you will connect.

They did change the netcode for the live LS recently but it shouldn't of broken anything. They added the ability to force boot your account offline. The basic code is the same, or should be, very odd that it works for both live and emu for me.

Maybe there's something settings dependent, or as mentioned you can just use the older netcode with the titanium eqmain.

Edit: My patch brings me an eqgame and eqmain.dll that don't match those sizes. Puzzling.

KLS, do you currently own an active (paid) EQLive account? As I said earlier, you can patch only up to a certain point if you don't own a currently active EQLive account. You have to log in to patch all of the file, and the only 2 options are having a paid account, or one of the free trial accounts. If you tried with a trial account, then you aren't running the same version as EQLive.

I will see what happens if I try swapping out an older eqmain.dll with the EQLive one. I would think it would have some errors if I do, but no harm in trying.

I have a live eq and eq2 acct. I know right? I'm thinking maybe it didn't fully patch for some reason (I didn't actually try to log into live after patching). It changed my eqhosts.txt so I'm guessing it patched the right directory.

Well there were patch files waiting so I'm guessing that's what happened. =(

Ahh yeah, I think if you haven't patched before, it usually needs to exit and restart the patching again to get everything fully up-to-date. Thanks for the info though. At least I know I am not crazy now lol.

Well I wouldn't say we could come to that conclusion... =p

Well, it isn't much, but I did make a little progress on getting into SoF tonight. I found that I had the wrong opcode for zonespawns that I thought was correct, but wasn't.

Here is the new stuff in the SoF EQ Debug output:

Since I was looking into Item Serialization more again today after seeing a post from Derision in another thread, I started working on it a bit more again. I think I have the serialization stuff mostly worked out. If only I had a single log from someone logging in during SoF (preferable 9/7/07 to 11/13/07), I could get everything working pretty easily at this point I think.

The thing I can't figure out with item serialization is that it seems to be sending the wrong structure for OP_CharacterInventory. I don't even see a structure for it in the structs file. I assume it is all being handled in the anniversary.cpp encode stuff. In the log above, this is the only 1 of my characters that will even log 1 item before it crashes. The others all just fail before getting to the first one. So, I assume it is something about that particular item that is letting it get that far. I don't know what the number 2083552304 means, but that number is supposed to be the inventory slot the item is in according to normal log files. Here is an example from titanium:

2083552304 is 7C307C30 in Hex. Ascii code 7C is the pipe symbol, |, and 30 is the number 0, so 7C307C30 is |0|0 which looks like serialised item data.

I should add that when I was working on the Bazaar, I was looking at some Live traces and *think* that I wasn't seeing item data being sent in a serialised format (didn't see any of those long strings of numbers separated by | symbols that are easy to spot in a packet trace). Maybe they stopped using that format for sending item data at some point.

If SEQ is showing the full packet, then you might be right. It seems more like they have each field broken down into int8,int16,int32,char,str, etc. Here is an example from SEQ from live:

The section highlighted in green is what I believe to be a single complete item. I was able to break down some of the serialization of the item and it is pretty similar to the order I already have set for SoF. As far as I could tell, it matched perfectly, at least for EQLive.

I was thinking the same thing about the number being the serialization. I'm not sure where equip slot is sent, because I don't see it in the serialization.

Here is some of the serialization breakdown I was doing, which was some guesswork and some simple hex converting and comparing to the itemfields list as well as looking at the 13th floor info for this item:

Item Instance Info:

Item Fields breakdown:
So, it looks like strings are separated by 0s and the rest is just defined sizes.

Note: If you scroll up and down on the code box with the green hex code in it above, it looks kinda like the Matrix screen, LOL :D

My guess is that in those packets, the inventory slot is 8 bytes into the struct.

The first item:

Would be slot 0, charm slot.

Second item:

The least significant byte is to the left, so this is 0x000007d0 which is 2000, which is the first bank slot. You'd have to know which slots those items were actually in on the character to confirm.

This ties in with the field order in the Serialized item data in Titanium. If you look in common/patches/Titanium.cpp at SerializeItem, the third field is the slot_id or merchant_slot.

Since strings seem to be separated by a single 0 bit, those should be easy to change over to the new format of removing the pipes | from the serialization. But, for chars and ints, I need to find a way that I can define a certain number of bits to use. It seems like most of them are set to work like int8, int16, int32 or so using 1, 2, 4 or so hex bits for each field. So, I need the serialization to be able to figure out how many bits to send for each field.

For example; If I want to send the Item ID, the example I gave in the last post would be to send "bb 88 00 00". That would be item ID 35003, but it is important to send the last to 0 bits there to make sure the item structure aligns properly. Maybe I could make an actual structure in the structs file to do it, but I don't really know how to pull database fields for structures.

From looking at the anniversary_itemfields.h "TRY NEW" section, it looks like they tried to assign lengths to each field. But I can't figure out how the serialization would work for that. Here is an excerpt from the file:

I replaced that section on my test server a while back and had almost forgotten about it. I didn't understand what the numbers next to the defines were, but it makes sense now, lol. I guess the serialization was changed back when Anniversary actually came out or before it.

Any suggestions on how to change the SerializeItem below to work with the "TRY NEW" itemfields the way it needs to for clients later than Titanium? I don't think it would require much of a change, but I just don't know how to set it to know that "I4" means to use 4 bit even if only 1 of them gets filled with data.

Well, I am trying to work out how to make the serialization match up with how it works now for Live (and apparently since Anniversary or so), but I can't seem to get it to send the integers followed by null (00 in hex) bits.

I copied the function (GetNextItemInstSerialNumber()) to make Item Instanced Serial Numbers similar to how live does it to use in the Item Instancing part of the Serialization. That part seems to be working properly and I will definitely keep that in the final Serialization code. It may not really be required, but it doesn't hurt to copy the way Live does it as close as possible.

I then tried making the changes noted in green below, to force it to send the integers as int32, hoping that it would send them each as 4 bits. It still seems to just be sending the integers, without the 00s after them as it needs to be doing.

I also found the item_struct.h file which I hadn't seen before and it helped me understand how the serialization is working a little better. Basically, the item_struct is just handled in it's own separate file for some reason instead of being included in the eq_packet_structs.h file. So, if I understand correctly, it seems that the patch_itemfields.h files are just separate files to do basically the same thing as the encodes in the patch.cpp files.

I even noticed that the item_struct already has sizes defined for each field like int8, int32 etc just like normal structs. So, I think that I could just use that struct, and edit the field sizes where needed and add them to the anniversary_structs.h file and then do an encode of them like normal. But, I will still need to figure out how to make it send the structure as the size that it is supposed to be. The structure will vary in length slightly, because a couple fields are strings and don't have a set size limit on them. But, other than that, the rest should always be the same size.

O..M..G! I finally got in game! @#$@% WOOT!

Turns out the whole time, the thing that was stopping me was sending the incorrect structure for AA tables. I simply commented out the opcodes for AA stuff in the .conf file and got in game first try! Of course, nothing really works yet, but now that I am at this point, I think things will start progressing very quickly!!! As soon as I can iron a few things out, I will get this stuff on the SVN ASAP. I will try to add new files for it so I don't just overwrite the current anniversary files. I just need to figure out how to create new patch files and I will get them up. I will knock out a few more opcodes and clean up packet structures more too though, so it is less messy than what I currently have for it.

I am VERY excited!!! I have been stuck at the same point for over a month now! I will have more updates here shortly! Things are looking bright :D