|
|
|
 |
 |
 |
 |
|
 |
 |
|
 |
 |
|
 |
|
| Development::Development Forum for development topics and for those interested in EQEMu development. (Not a support forum) |
 |
|
 |

02-15-2009, 05:34 AM
|
|
Administrator
|
|
Join Date: Sep 2006
Posts: 1,348
|
|
Nah I've had good loads with the client thinking it has a bad item slot. It finishes loading the item from the slot but then allocates way too much memory for the next item or something. Bad item slot just fails to load unless it's negative then you'll get an immediate crash... im not sure why some item slots get way off tho. I'll have to look at my output logs and make sure everything it looking right.
Code:
[Sun Feb 15 00:02:28 2009]00140:Received our Player from zone. MSG_EQ_NETPLAYERBUFF is next.
[Sun Feb 15 00:02:28 2009]00141:Player = Krissy, zone = The Mines of Gloomingdeep
[Sun Feb 15 00:02:35 2009]00142:MSG_EQ_NETPLAYERBUFF received started.
[Sun Feb 15 00:02:35 2009]00143:MSG_EQ_NETPLAYERBUFF finished.
[Sun Feb 15 00:02:36 2009]00144:MSG_EQ_NETPLAYERBUFF received started.
[Sun Feb 15 00:02:36 2009]00145:MSG_EQ_NETPLAYERBUFF finished.
[Sun Feb 15 00:02:36 2009]00146:MSG_TIME_STAMP received.
[Sun Feb 15 00:02:36 2009]00147:MSG_TIME_STAMP received. (Items inc).
[Sun Feb 15 00:02:36 2009]00148:Received an item via EQI_STARTING_ITEM at loc 2
[Sun Feb 15 00:02:36 2009]00149:Received an item via EQI_STARTING_ITEM at loc 7
[Sun Feb 15 00:02:36 2009]00150:Received an item via EQI_STARTING_ITEM at loc 8
[Sun Feb 15 00:02:36 2009]00151:Received an item via EQI_STARTING_ITEM at loc 9
[Sun Feb 15 00:02:36 2009]00152:Received an item via EQI_STARTING_ITEM at loc 10
[Sun Feb 15 00:02:36 2009]00153:Received an item via EQI_STARTING_ITEM at loc 13
[Sun Feb 15 00:02:36 2009]00154:Received an item via EQI_STARTING_ITEM at loc 14
[Sun Feb 15 00:02:36 2009]00155:Received an item via EQI_STARTING_ITEM at loc 17
[Sun Feb 15 00:02:36 2009]00156:Received an item via EQI_STARTING_ITEM at loc 18
[Sun Feb 15 00:02:36 2009]00157:Received an item via EQI_STARTING_ITEM at loc 19
[Sun Feb 15 00:02:36 2009]00158:Received an item via EQI_STARTING_ITEM at loc 23
[Sun Feb 15 00:02:36 2009]00159:Received an item via EQI_STARTING_ITEM at loc 24
[Sun Feb 15 00:02:36 2009]00160:Received an item via EQI_STARTING_ITEM at loc 25
[Sun Feb 15 00:02:36 2009]00161:Received an item via EQI_STARTING_ITEM at loc 282
[Sun Feb 15 00:02:36 2009]00162:Received an item via EQI_STARTING_ITEM at loc 16777216
[Sun Feb 15 00:02:36 2009]00163:Received an item via EQI_STARTING_ITEM at loc 27
[Sun Feb 15 00:02:36 2009]00164:Received an item via EQI_STARTING_ITEM at loc 28
[Sun Feb 15 00:02:36 2009]00165:Received an item via EQI_STARTING_ITEM at loc 29
[Sun Feb 15 00:02:36 2009]00166:Received an item via EQI_STARTING_ITEM at loc 30
[Sun Feb 15 00:02:36 2009]00167:Item done, MSG_WEATHER_EVENT received.
[Sun Feb 15 00:02:36 2009]00168:Initializing zone.
[Sun Feb 15 00:02:36 2009]00169:Initializing world.
[Sun Feb 15 00:02:36 2009]00170:Verifying world files.
[Sun Feb 15 00:02:36 2009]00171:Attempting to load tutorialb.EQG.
[Sun Feb 15 00:02:41 2009]00172:Loaded tutorialb.EQG.
[Sun Feb 15 00:02:41 2009]00173:Loading zone specific files.
I've noticed items in bags tend to be particularly big offenders for some reason it's almost always an item in a bag...
Last edited by KLS; 02-15-2009 at 01:42 PM..
|
 |
|
 |
 |
|
 |

02-15-2009, 06:35 AM
|
|
Developer
|
|
Join Date: Mar 2007
Location: Ohio
Posts: 648
|
|
Quote:
Originally Posted by KLS
Code:
[Sun Feb 15 00:02:36 2009]00162:Received an item via EQI_STARTING_ITEM at loc 16777216
|
Not sure if it's been noticed, but 16777216 is 1000000 in hex, so it looks like we're getting 3 extra bytes in there. In the log, it doesn't look like slot 1 was sent, so that's probably it. I've also seen 436207616 (1A000000 so 1A -> 26) while messing around myself.
I've also seen some in-game errors from the server about issues with slots:
Code:
[Debug] Error: Server found no item in slot 13245 (->12274), Deleting Item!
[Debug] DeleteItemInInventory(12274, 0, true)
[Debug] Error: Server found no item in slot 14192 (->12274), Deleting Item!
[Debug] DeleteItemInInventory(12274, 0, true)
[Debug] Error: Server found no item in slot 15118 (->12274), Deleting Item!
[Debug] DeleteItemInInventory(12274, 0, true)
[Debug] Error: Server found no item in slot 16054 (->12274), Deleting Item!
[Debug] DeleteItemInInventory(12274, 0, true)
[Debug] Error: Server found no item in slot 16990 (->12274), Deleting Item!
[Debug] DeleteItemInInventory(12274, 0, true)
[Debug] Error: Server found no item in slot 17900 (->12274), Deleting Item!
[Debug] DeleteItemInInventory(12274, 0, true)
[Debug] Error: Server found no item in slot 9796 (->8841), Deleting Item!
[Debug] DeleteItemInInventory(8841, 0, true)
[Debug] Error: Server found no item in slot 8476 (->7542), Deleting Item!
[Debug] DeleteItemInInventory(7542, 0, true)
[Debug] Error: Server found no item in slot 9400 (->7542), Deleting Item!
[Debug] DeleteItemInInventory(7542, 0, true)
I'm not sure if it's directly related, but I think Attack might be also suffering a similar issue.
|
 |
|
 |
 |
|
 |

02-15-2009, 09:56 AM
|
 |
Developer
|
|
Join Date: Aug 2006
Location: USA
Posts: 5,946
|
|
Yeah, after looking and the error I posted earlier from the EQ debug, I just noticed that slot 1792 would be 700 in hex, so it was probably off a byte since it had just loaded slot 6 and slot 7 would have been next. So, it sounds like we are just adding an extra byte somewhere that isn't needed.
I made some corrections to the item structure and am going to commit them to the SVN in a minute. It still isn't perfect, but seems to be loading at least the starter items I have tried very well now. Using the 13th floor info that AndMetal posted has helped alot I think, though it doesn't seem to be 100% accurate for SoF. At least it is a better guide.
One important one is that it seems like the filename field is just like any other string field. It should load a null byte if there is nothing in that field. The booktype field being set to int16 should have actually been int8, and the other byte there would be the filename field. The FF FF FF FF or 00 00 00 00 after that is actually an sint32 for loregroup. So, I think that makes a bit more sense now.
I am sure we can definitely get most of this structure sorted out without too many issues. Especially once we figure out where it is getting that extra byte from. I am thinking maybe one of the strings isn't supposed to have a null terminator after it or something. From what I can tell, I don't see any major difference between the items it was able to load and the item that threw off the struct by 1 byte. Maybe there is supposed to be an extra byte every few items or something...
Last edited by trevius; 02-15-2009 at 06:50 PM..
|
 |
|
 |

02-15-2009, 04:17 PM
|
|
Administrator
|
|
Join Date: Sep 2006
Posts: 1,348
|
|
I'm thinking maybe I'm not supposed to send bag content on initial serialization. When you open a bag this client sends a small packet to the server that includes the item slot opened...
|

02-15-2009, 05:08 PM
|
|
Administrator
|
|
Join Date: Sep 2006
Posts: 1,348
|
|
Bah my packets were too long!
I had two nifty packets to show the diff between an item loading correct slot and an item not loading in correct slot but the forums ate them D=
Long and short of it: the headers are almost exactly the same they just differ by what I've labeled as potion type.. I've gotta look more into it tho.
|

02-16-2009, 01:12 AM
|
|
Administrator
|
|
Join Date: Sep 2006
Posts: 1,348
|
|
I devised a workaround for the crashing and failure to load of items... well for the crashing at least
I'd still like to figure out why it sometimes doesn't work when put into an EQI packet, but this should let us move onto more important things for now.
Last edited by KLS; 02-16-2009 at 09:16 AM..
|

02-16-2009, 04:10 AM
|
|
Administrator
|
|
Join Date: Sep 2006
Posts: 1,348
|
|
Work around for items seems to work fine, tho they still need a lot of work. I checked out AAs quickly but I'm kinda at a loss. Using the log I got from derision the data doesn't seem to of changed at all other than how they do string ids. I updated that to match and still nothing.
I notice that the window tabs don't even appear, which isn't entirely unusual. One thing I notice is the AA table is sent directly after the client requests the zone, right before the player profile. And for titanium and below we send it... considerably later, maybe the client is getting picky with how it's sent, or maybe there's some other packet that needs to be sent to get AAs to work.
|
| 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 07:24 AM.
|
|
 |
|
 |
|
|
|
 |
|
 |
|
 |