Starting Work on SoF Opcodes/Structs

[KLS]

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

[Derision]

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:

23/12/2008  10:06         1,015,808 eqmain.dll
23/12/2008  10:05         4,874,240 eqgame.exe

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

[klamath]

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.

[KLS]

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.

[trevius]

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.

[KLS]

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. =(

[trevius]

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.

[KLS]

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

[trevius]

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:

[Mon Jan 12 06:06:09 2009]00129:Initializing character select UI.
[Mon Jan 12 06:06:09 2009]00130:Resetting game UI.
[Mon Jan 12 06:06:31 2009]00131:Zone Connect -- 0 -- Received MSG_ZONE_ADDRESS
[Mon Jan 12 06:06:31 2009]00132:Zone addr [192.168.1.102:19741] received...
[Mon Jan 12 06:06:31 2009]00133:ZONING
[Mon Jan 12 06:06:32 2009]00134:Networking: Connection Closed [0] with 0 pending bytes.
[Mon Jan 12 06:06:32 2009]00135:Networking: using port [3764].
[Mon Jan 12 06:06:32 2009]00136:Networking: Connection Established [1]
[Mon Jan 12 06:06:32 2009]00137:Connected to 192.168.1.102:19741...

[Mon Jan 12 06:06:32 2009]00138:Zone Connect -- 2 -- Sending MSG_EQ_ADDPLAYER
[Mon Jan 12 06:06:34 2009]00139:Zone Connect -- 3 -- Received MSG_SEND_PC
[Mon Jan 12 06:06:34 2009]00140:Zone Connect -- 4 -- Received MSG_EQ_ADDPLAYER
[Mon Jan 12 06:06:34 2009]00141:Received our Player from zone. MSG_EQ_NETPLAYERBUFF is next.
[Mon Jan 12 06:06:34 2009]00142:Player = Zshadow, zone = The Nexus
[Mon Jan 12 06:06:34 2009]00143:MSG_EQ_NETPLAYERBUFF received started.
[Mon Jan 12 06:06:34 2009]00144:MSG_EQ_NETPLAYERBUFF finished.
[Mon Jan 12 06:06:34 2009]00145:MSG_TIME_STAMP received.

[Mon Jan 12 06:06:34 2009]00146:MSG_TIME_STAMP received. (Items inc).

[Mon Jan 12 06:06:35 2009]00147:Received an item via EQI_STARTING_ITEM at loc 2083552304

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:

2009-01-12 03:16:32	Zone Connect -- 0 -- Received MSG_ZONE_ADDRESS
2009-01-12 03:16:32	Zone addr [192.168.1.102:19741] received...
2009-01-12 03:16:32	ZONING
2009-01-12 03:16:32	Networking: Connection Closed [0] with 0 pending bytes.
2009-01-12 03:16:33	Networking: using port [3155].
2009-01-12 03:16:33	Networking: Connection Established [1]
2009-01-12 03:16:33	Connected to 192.168.1.102:19741...
2009-01-12 03:16:33	
2009-01-12 03:16:33	Zone Connect -- 2 -- Sending MSG_EQ_ADDPLAYER
2009-01-12 03:16:35	Zone Connect -- 3 -- Received MSG_SEND_PC
2009-01-12 03:16:35	Zone Connect -- 4 -- Received MSG_EQ_ADDPLAYER
2009-01-12 03:16:35	Received our EQPlayer from zone. MSG_EQ_NETPLAYERBUFF is next.
2009-01-12 03:16:35	Player = Trevazar, zone = Solusek Ro's Tower
2009-01-12 03:16:38	MSG_EQ_NETPLAYERBUFF received started.
2009-01-12 03:16:39	MSG_EQ_NETPLAYERBUFF finished.
2009-01-12 03:16:42	MSG_EQ_NETPLAYERBUFF received started.
2009-01-12 03:16:42	MSG_EQ_NETPLAYERBUFF finished.
2009-01-12 03:16:43	MSG_EQ_NETPLAYERBUFF received started.
2009-01-12 03:16:43	MSG_EQ_NETPLAYERBUFF finished.
2009-01-12 03:16:44	MSG_EQ_NETPLAYERBUFF received started.
2009-01-12 03:16:44	MSG_EQ_NETPLAYERBUFF finished.
2009-01-12 03:16:44	MSG_EQ_NETPLAYERBUFF received started.
2009-01-12 03:16:44	MSG_EQ_NETPLAYERBUFF finished.
2009-01-12 03:16:44	MSG_TIME_STAMP received.
2009-01-12 03:16:44	
2009-01-12 03:16:44	MSG_TIME_STAMP received. (Items inc).
2009-01-12 03:16:44	
2009-01-12 03:16:46	Received an item via EQI_STARTING_ITEM at loc 0
2009-01-12 03:16:46	Received an item via EQI_STARTING_ITEM at loc 1
2009-01-12 03:16:46	Received an item via EQI_STARTING_ITEM at loc 2
2009-01-12 03:16:46	Received an item via EQI_STARTING_ITEM at loc 3
2009-01-12 03:16:46	Received an item via EQI_STARTING_ITEM at loc 4
2009-01-12 03:16:46	Received an item via EQI_STARTING_ITEM at loc 5
2009-01-12 03:16:46	Received an item via EQI_STARTING_ITEM at loc 6
2009-01-12 03:16:46	Received an item via EQI_STARTING_ITEM at loc 7
2009-01-12 03:16:46	Received an item via EQI_STARTING_ITEM at loc 8
2009-01-12 03:16:46	Received an item via EQI_STARTING_ITEM at loc 9
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 10
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 11
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 12
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 13
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 14
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 15
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 16
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 17
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 18
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 19
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 20
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 21
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 22
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 23
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 24
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 25
2009-01-12 03:16:47	Received an item via EQI_STARTING_ITEM at loc 26
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 27
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 28
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 29
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2000
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2001
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2002
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2003
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2004
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2005
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2006
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2007
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2008
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2010
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2011
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2012
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2014
2009-01-12 03:16:48	Received an item via EQI_STARTING_ITEM at loc 2015
2009-01-12 03:16:49	Item done, MSG_WEATHER_EVENT received.
2009-01-12 03:16:49	
2009-01-12 03:16:49	Initializing zone.
2009-01-12 03:16:49	Initializing world.

[Derision]

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.

[trevius]

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:

30032 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30048 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01  | ................ 
30064 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01  | ................ 
30080 | 00 00 00 00 00 00 00 25 53 4c 01 00 00 00 00 00  | .......%SL...... 
30096 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30112 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 49  | ...............I 
30128 | 6e 74 72 69 63 61 74 65 20 57 6f 6f 64 65 6e 20  | ntricate Wooden  
30144 | 46 69 67 75 72 69 6e 65 00 49 6d 62 75 65 64 20  | Figurine.Imbued  
30160 | 77 69 74 68 20 61 6e 20 61 64 76 65 6e 74 75 72  | with an adventur 
30176 | 65 72 27 73 20 73 70 69 72 69 74 00 49 54 36 33  | er's spirit.IT63 
30192 | 00 bb 88 00 00 01 01 00 00 00 01 00 00 00 00 00  | ................ 
30208 | 00 00 7f 03 00 00 01 00 00 00 00 00 00 0a 0a 0a  | ................ 
30224 | 0a 0a 00 0f 0f 00 0a 00 00 0a 5a 00 00 00 50 00  | ..........Z...P. 
30240 | 00 00 00 00 00 00 14 00 00 00 00 00 00 00 00 00  | ................ 
30256 | 00 00 00 00 00 00 04 00 00 00 ff ff 00 00 00 00  | ................ 
30272 | 00 00 00 00 00 00 00 00 00 00 ff ff ff ff 00 00  | ................ 
30288 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00  | ................ 
30304 | 00 00 00 33 00 00 00 00 00 00 00 00 00 00 00 00  | ...3............ 
30320 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30336 | 00 00 00 ff 0a 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30352 | 00 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 00  | ....?........... 
30368 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30384 | 00 00 00 00 00 00 00 00 00 b9 88 00 00 00 00 00  | ................ 
30400 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30416 | 00 00 00 00 00 00 00 00 00 00 00 00 00 43 48 52  | .............CHR 
30432 | 4d 50 6f 50 41 63 63 65 73 73 00 00 00 00 00 00  | MPoPAccess...... 
30448 | 00 00 00 07 00 00 00 01 00 00 00 00 00 01 00 00  | ................ 
30464 | 00 00 00 01 00 00 00 00 00 01 00 00 00 00 00 01  | ................ 
30480 | 00 00 00 00 00 00 00 00 00 00 00 00 00 46 00 00  | .............F.. 
30496 | 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff  | ................ 
30512 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30528 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff  | ................ 
30544 | ff ff ff 00 00 00 00 00 00 00 00 00 00 00 01 00  | ................ 
30560 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30576 | 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00  | ................ 
30592 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30608 | 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff 00  | ................ 
30624 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30640 | 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff  | ................ 
30656 | ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30672 | 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff  | ................ 
30688 | ff ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30704 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30720 | ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00  | ................ 
30736 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30752 | 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 00  | ................ 
30768 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30784 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30800 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30816 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30832 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30848 | 00 00 00 00 00 01 00 00 00 00 00 00 00 d0 07 00  | ................ 
30864 | 00 00 00 00 00 01 00 00 00 00 00 00 00 4e 53 4c  | .............NSL 
30880 | 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30896 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 
30912 | 00 00 00 00 01 54 72 61 64 65 72 27 73 20 53 61  | .....Trader's Sa 
30928 | 74 63 68 65 6c 00 54 72 61 64 65 72 27 73 20 53  | tchel.Trader's S 
30944 | 61 74 63 68 65 6c 00 49 54 36 33 00 eb 45 00 00  | atchel.IT63..E..

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:

1|0|0|0|1|0|21779237|0|0|0|0|0|0|0|0|0|<----Item Instance
Intricate Wooden Figurine|Imbued with an Adventurer's Spirit|IT63|1|1|0|0|0|1|0|0|0|0|0|0|0|127|3|0|0|1|0|0|0|0|0|0
|10|10|10|10|10|0|15|15|0|10|0|0|10|90|0|0|0|80|0x7|20|0x15|4|0|0|0|255|255|0x14
|255|255|255|255|0x16|1|0|0|0|0|51|0x31|128|63|0x36|185|136|0x34|CHRMPoPAccess|0x9|7|0|0|0|1

Item Instance Info:

01 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 
01 00 00 00 
00 00 00 00 
25 53 4c 01 
00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00

Item Fields breakdown:

S(Name) 49 6e 74 72 69 63 61 74 65 20 57 6f 6f 64 65 6e 20 46 69 67 75 72 69 6e 65
00
S(Lore) 49 6d 62 75 65 64 20 77 69 74 68 20 61 6e 20 61 64 76 65 6e 74 75 72 65 72 27 73 20 73 70 69 72 69 74
00
S(IDFile) 49 54 36 33
00
I(ID) bb 88 00 00 - 35003
I(Weight) 01
I(NoRent) 01
I(NoDrop) 00
I(Size) 00
I(Slots) 00 
I(Price) 01 00 00 00 00 00 00 00
I(Icon) 7f 03 00 00 - 895 (idol)
C("0")//UNK013 01
C("0")//UNK014 00
I(BenefitFlag) 00
I(Tradeskills) 00 00 00 00
I(CR) 0a - 10
I(DR) 0a - 10
I(PR) 0a - 10
I(MR) 0a - 10
I(FR) 0a - 10
I(SVCORR) 00
I(AStr) 0f - 15
I(ASta) 0f - 15
I(AAgi) 00
I(ADex) 0a - 10
I(ACha) 00
I(AInt) 00
I(AWis) 0a - 10
I(HP) 5a 00 00 00 - 90
I(Mana) 50 00 00 00 - 80
I(Endur) 00 00 00 00 - 0
I(AC) 14 00 00 00 - 20
? 00 00 00 00
? 00 00 00 00
? 00 00 00 00
I(Classes) 04 00 00 00 - 4 (paladin only)
I(Races) ff ff 00 00
I(Deity) 00 00 00 00
I(SkillModValue) 00 00 00 00
C("0")//UNK038 00 00 00 00
I(SkillModType) ff ff ff ff
I(BaneDmgRace) 00 00 00 00
I(BaneDmgBody) 00 00 00 00
I(BaneDmgRaceAmt) 00 00 00 00
I(BaneDmgAmt) 00 00 00 00
I(Magic) 01
I(CastTime_) 00 00 00 00
I(ReqLevel) 33 00 00 00 - 51
I(RecLevel) 00 00 00 00
I(RecSkill) 00 00 00 00
I(BardType) 00 00 00 00

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

[Derision]

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

The first item:

01 00 00 00 00 00 00 00 00 00 00 00

Would be slot 0, charm slot.

Second item:

01 00 00 00 00 00 00 00 d0 07 00 00

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.

[trevius]

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:

#ifdef NEW_TRY
/* 000 */	//I(ItemClass) Leave this one off on purpose
/* 001 */	S(Name)
/* 002 */	S(Lore)
/* 003 */	MISSINGCS("")	//LoreFile? missing from binary
/* 003 */	S(IDFile)
/* 004 */	I4(ID)
/* 005 */	I1(Weight)
/* 006 */	I1(NoRent)
/* 007 */	I2(NoDrop)
/* 008 */	I4(Size)
/* 009 */	I1(Slots)
/* 010 */	I4(Price)
/* 011 */	I4(Icon)
/* 013 */	C4(0)
/* 014 */	C1(0)
/* 014 */	I1(BenefitFlag)
/* 015 */	I1(Tradeskills)
/* 016 */	I1(CR)
/* 017 */	I1(DR)
/* 018 */	I1(PR)
/* 019 */	I1(MR)
/* 020 */	I1(FR)

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.

char *SerializeItem(const ItemInst *inst, sint16 slot_id, uint32 *length, uint8 depth) {
	char *serialization = NULL;
	char *instance = NULL;
	const char *protection=(const char *)"\\\\\\\\\\";
	char *sub_items[10] = { NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL };
	bool stackable=inst->IsStackable();
	uint32 merchant_slot=inst->GetMerchantSlot();
	sint16 charges=inst->GetCharges();
	const Item_Struct *item=inst->GetItem();
	int i;
	uint32 sub_length;

	//not sure how these truely shifted, as this dosent seem right.
	MakeAnyLenString(&instance,
		"%i|%i|%i|%i|%i|%i|%i|%i|%i|%i|%i|%i|%i|",
		stackable ? charges : 0,
		0,
		(merchant_slot==0) ? slot_id : merchant_slot,
		inst->GetPrice(),
		(merchant_slot==0) ? 1 : inst->GetMerchantCount(),
		0,
		merchant_slot + item->ID,	//instance ID, bullshit for now
		inst->IsInstNoDrop() ? 1 : 0,		//not sure where this field is
		(stackable ? ((inst->GetItem()->ItemType == ItemTypePotion) ? 1 : 0) : charges),
		0,
		0,
		0,
		0
	);

	for(i=0;i<10;i++) {
		ItemInst *sub=inst->GetItem(i);
		if (sub) {
			sub_items[i]=SerializeItem(sub,0,&sub_length,depth+1);
		}
	}

	
	*length=MakeAnyLenString(&serialization,
		"%.*s%s"	// For leading quotes (and protection) if a subitem;
		"%s"		// Instance data
		"%.*s\""	// Quotes (and protection, if needed) around static data
		"%i"		// item->ItemClass so we can do |%s instead of %s|
#define I(field) "|%i"
#define C(field) "|%s"
#define S(field) "|%s"
#define F(field) "|%f"
#include "Anniversary_itemfields.h"
		"%.*s\""	// Quotes (and protection, if needed) around static data
		"|%s|%s|%s|%s|%s|%s|%s|%s|%s|%s"	// Sub items
		"%.*s%s"	// For trailing quotes (and protection) if a subitem;
		,depth ? depth-1 : 0,protection,(depth) ? "\"" : ""
		,instance
		,depth,protection
		,item->ItemClass
#define I(field) ,item->field
#define C(field) ,field
#define S(field) ,item->field
#define F(field) ,item->field
#include "Anniversary_itemfields.h"
		,depth,protection
		,sub_items[0] ? sub_items[0] : ""
		,sub_items[1] ? sub_items[1] : ""
		,sub_items[2] ? sub_items[2] : ""
		,sub_items[3] ? sub_items[3] : ""
		,sub_items[4] ? sub_items[4] : ""
		,sub_items[5] ? sub_items[5] : ""
		,sub_items[6] ? sub_items[6] : ""
		,sub_items[7] ? sub_items[7] : ""
		,sub_items[8] ? sub_items[8] : ""
		,sub_items[9] ? sub_items[9] : ""
		,(depth) ? depth-1 : 0,protection,(depth) ? "\"" : ""
	);

	for(i=0;i<10;i++) {
		if (sub_items[i])
			safe_delete_array(sub_items[i]);
	}

	safe_delete_array(instance);

printf("ITEM: \n%s\n", serialization);
	
	return serialization;
}

} //end namespace Anniversary

[trevius]

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.

sint32 NextItemInstSerialNumber = 1;
int32 MaxInstances = 2000000000;

static inline sint32 GetNextItemInstSerialNumber() {

	if(NextItemInstSerialNumber >= MaxInstances)
		NextItemInstSerialNumber = 1;
	else
		NextItemInstSerialNumber++;

	return NextItemInstSerialNumber;
}


char *SerializeItem(const ItemInst *inst, sint16 slot_id, uint32 *length, uint8 depth) {
	char *serialization = NULL;
	char *instance = NULL;
	const char *protection=(const char *)"\\\\\\\\\\";
	char *sub_items[10] = { NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL };
	bool stackable=inst->IsStackable();
	uint32 merchant_slot=inst->GetMerchantSlot();
	sint16 charges=inst->GetCharges();
	const Item_Struct *item=inst->GetItem();
	int i;
	uint32 sub_length;
	uint32 stack = stackable ? charges : 1;
	uint32 zero = 0;
	uint32 price = inst->GetPrice();
	uint32 slot = (merchant_slot==0) ? slot_id : merchant_slot;
	uint32 merchcount = (merchant_slot==0) ? 1 : inst->GetMerchantCount();
	uint32 serialnumber = GetNextItemInstSerialNumber();
	uint32 instnodrop = inst->IsInstNoDrop() ? 1 : 0;
	uint32 typepotion = (stackable ? ((inst->GetItem()->ItemType == ItemTypePotion) ? 1 : 0) : charges);

   MakeAnyLenString(&instance,
      "%i%i%i%i%i%i%i%i%i%i%i%i%i%i%i",
      stack,
      zero,
      price,
	  slot,
      merchcount,
      zero,
      serialnumber,
      instnodrop,
      typepotion,
      zero,
      zero,
      zero,
      zero,
      zero,
      zero

   );

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.

[trevius]

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

[Wed Jan 21 02:14:36 2009]00420:DoMainLoop: just before first while(!EverQuest.ReceievedWorldObjects).
[Wed Jan 21 02:14:36 2009]00421:Zone Connect -- Received MSG_SND_WOBJECTS_RESPONSE
[Wed Jan 21 02:14:36 2009]00422:DoMainLoop: complete after first while(!EverQuest.ReceievedWorldObjects).
[Wed Jan 21 02:14:36 2009]00423:DoMainLoop: just before second while(!ReadyEnterWorld).
[Wed Jan 21 02:14:36 2009]00424:Zone Connect -- Sending out a MSG_READY_ENTER_WORLD.
[Wed Jan 21 02:14:36 2009]00425:Zone Connect -- Received MSG_READY_ENTER_WORLD
[Wed Jan 21 02:14:36 2009]00426:DoMainLoop: completed second while(!ReadyEnterWorld).
[Wed Jan 21 02:14:36 2009]00427:Setting up models.
[Wed Jan 21 02:14:36 2009]00428:Setting up character.
[Wed Jan 21 02:14:36 2009]00429:Activating music.
[Wed Jan 21 02:14:36 2009]00430:Initialization complete.
Entering main loop.
[Wed Jan 21 02:14:36 2009]00431:Item done, MSG_WEATHER_EVENT received.