|
|
|
 |
|
|
 |
|
 |
 |
|
 |
 |
|
 |
|
| Development::Development Forum for development topics and for those interested in EQEMu development. (Not a support forum) |
01-12-2009, 05:55 AM
|
|
Administrator
|
|
Join Date: Sep 2006
Posts: 1,348
|
|
Well I wouldn't say we could come to that conclusion... =p
|
 |
|
 |
01-12-2009, 09:00 AM
|
 |
Developer
|
|
Join Date: Aug 2006
Location: USA
Posts: 5,946
|
|
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:
Code:
[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:
Code:
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.
|
 |
|
 |
01-12-2009, 09:27 AM
|
|
Developer
|
|
Join Date: Feb 2004
Location: UK
Posts: 1,540
|
|
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.
|
|
|
|
01-12-2009, 10:04 AM
|
|
Developer
|
|
Join Date: Aug 2006
Location: USA
Posts: 5,946
|
|
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:
Code:
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:
Code:
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:
Code:
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:
Code:
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 
Last edited by trevius; 01-13-2009 at 01:53 AM..
|
|
|
|
01-12-2009, 11:04 AM
|
|
Developer
|
|
Join Date: Feb 2004
Location: UK
Posts: 1,540
|
|
My guess is that in those packets, the inventory slot is 8 bytes into the struct.
The first item:
Code:
01 00 00 00 00 00 00 00 00 00 00 00
Would be slot 0, charm slot.
Second item:
Code:
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.
Last edited by Derision; 01-12-2009 at 07:09 PM..
|
|
|
|
01-13-2009, 02:15 AM
|
|
Developer
|
|
Join Date: Aug 2006
Location: USA
Posts: 5,946
|
|
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:
Code:
#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.
Code:
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
|
|
|
|
|
|
|
01-13-2009, 09:21 AM
|
|
Developer
|
|
Join Date: Aug 2006
Location: USA
Posts: 5,946
|
|
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.
Code:
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. |
|
|
|
| Thread Tools |
|
|
| Display Modes |
 Hybrid Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -4. The time now is 05:33 AM.
|
|
 |
|
 |
|
|
|
 |
|
 |
|
 |
