Looking for ShowEQ update for Project 1999 after v33 6/25 patch

[amiraldayuk]

I also suspected that the removal of con color may have been a contributing factor but it isn’t something that is easily fixed by manually updating the character level in seq. Not only are the NPC and other player attributes showing up as random garbage, the coordinates are showing up as random locations, some way beyond the constraints of the map, which ruins map rendering. Leaving seq running for a while eventually results in segfault.

For troubleshooting, the console window doesn’t give much that is likely to help in identifying opcodes and structs that are off. The following is one reoccurring series of warnings that is given every time a zone change occurs:

Warning: L Line 14 in map '/usr/local/share/showeq/maps/oggok.map' has 44 points as opposed to the 45 points it specified!
Warning: L Line 42 in map '/usr/local/share/showeq/maps/oggok.map' has 11 points as opposed to the 7 points it specified!
Warning: L Line 44 in map '/usr/local/share/showeq/maps/oggok.map' has 11 points as opposed to the 7 points it specified!
Warning: L Line 59 in map '/usr/local/share/showeq/maps/oggok.map' has 17 points as opposed to the 16 points it specified!
Warning: L Line 62 in map '/usr/local/share/showeq/maps/oggok.map' has 17 points as opposed to the 16 points it specified!

I also turned on all logging and debug dump options but I’m not quite sure what to do with the data that it generates in ~/.showeq. There is quite a bit of this but I am not sure whether it is significant to the problem:

Jul 04 2014 13:49:47:343 [66.55.145.2:7042->client:57631] [Size: 77]
[OPCode: 0x300] [Flags: 5a] [CRC ok]
000 | 00 03 5a 78 5e 93 38 2d 22 c0 c5 60 c3 c9 d8 f1 | ..Zx^.8-"..`....
016 | d9 fc e1 ff ff cf 19 72 ee 1f ff c7 f0 e0 c9 6e | .......r.......n
032 | 01 06 4e 96 5f e7 ad 9d 99 18 18 40 58 9e 49 e2 | [email protected].
048 | b4 c8 3c 6e 06 17 4f f9 07 5f 96 3f d0 62 30 f8 | ..<n..O.._.?.b0.
064 | bf d5 7e 13 58 25 00 6e 15 1b 4e 09 26 | ..~.X%.n..N.&
Jul 04 2014 13:49:47:443 [66.55.145.2:7042->client:57631] [Size: 27]
[OPCode: 0x14cb] [Flags: a5] [CRC ok]
000 | cb a5 14 9c 08 00 00 18 00 a3 05 a0 e0 80 ff df | ................
016 | 00 b5 3f ce fe 00 e0 e4 bb a0 84 | ..?........

In reading the HOWTOs on addressing patch day problems, the reoccurring methods involved finding the opcodes and structs in memory and making sure that the corresponding values in everquest.h were consistent. That may have been an oversimplification of the solution but the forum discussions unfortunately assumed a significant level of familiarity with the code.

So in the spirit of giving a man a fishing pole instead of a fish, my questions would be:

1. Where would be the best source of log/dump/console data for identifying opcodes/structs that need to be fixed? From the development forum, it isn’t clear whether it is too late to use any of that information because seq isn’t working, as opposed to pulling logs to establish a baseline when seq IS working.
2. How much of the problem involves pulling opcodes from memory? I can decompile .exe’s and hex dump memory but the forum discussion isn’t clear about the relevancy. Some of the forum solutions discussed don’t involve using a hex editor at all.

Please advise?

Thanks - A

[amiraldayuk]

I'm not sure if I am barking up the wrong tree but I applied some of the techniques that others have been discussing and found a couple of inconsistencies that I'm not sure are relevant. I generated a zone log and then compared the data with structs that are currently in the 5.2.2.0 everquest.h. All but two of the structs that I have found so far are consistent as far as size but there were two exceptions:

First exception: In everquest.h, ServerZoneEntryStruct has a length of 383 octets but the struct was logged as size 385:
(from everquest.h)
/*
** Server Zone Entry struct
** Length: 383 Octets
** OpCode: ZoneEntryCode (when direction == server)
*
* This is just a spawnStruct for the player
*/
struct ServerZoneEntryStruct : public spawnStruct
{
};

(from zone.log)
Jul 04 2014 15:13:20:033 [Decoded] [Server->Client] [Size: 385]
[OPCode: 0x7213]
[Name: OP_ZoneEntry][Updated: 10/27/05][Type: ServerZoneEntryStruct (385) ==]
000 | 00 00 00 00 00 00 00 4d 53 3c 20 22 45 59 39 5a | .......MS< "EY9Z
016 | 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | <...............
032 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
048 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
064 | 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 00 | ................
080 | 00 00 00 00 00 00 4e 29 00 00 00 00 00 00 00 00 | ......N)........
096 | bb 52 ce bb 46 00 2f 00 00 00 00 cd 34 00 00 00 | .R..F./.....4...
112 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
128 | 00 00 00 00 00 00 00 00 00 00 00 49 00 00 00 00 | ...........I....
144 | 00 00 00 00 00 00 00 4b 00 00 00 00 00 00 00 00 | .......K........
160 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
176 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
192 | 00 00 00 00 00 4f 00 00 00 53 00 00 00 31 00 00 | .....O...S...1..
208 | 00 4a 00 00 00 39 00 00 00 4f 00 00 00 53 00 00 | .J...9...O...S..
224 | 00 23 00 00 00 9e 00 00 00 0b 79 33 70 00 da 49 | .#........y3p..I
240 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
256 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
272 | 00 00 00 00 b0 b2 c9 b7 00 00 00 00 40 00 00 00 | ............@...
288 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
304 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
320 | 00 00 00 00 d0 aa d6 73 00 00 00 5b 00 00 4b 32 | .......s...[..K2
336 | 00 00 00 b7 37 55 00 00 00 00 00 00 00 00 00 ae | ....7U..........
352 | 00 00 00 cc 00 00 00 b7 00 00 00 c7 00 00 00 b2 | ................
368 | 00 00 00 ae 00 00 00 cc 00 00 00 b7 00 00 00 c7 | ................
384 | 00

Second exception: In everquest.h, zonePointsStruct has length of 24 octets but is logged with 52:
(from everquest.h)
/*
** ZonePoint
** Length: 24 Octets
** Sent as part of zonePointsStruct
*/

struct zonePointStruct
{
/*0000*/ uint32_t zoneTrigger;
/*0004*/ float y;
/*0008*/ float x;
/*0012*/ float z;
/*0016*/ float heading;
/*0020*/ uint16_t zoneId;
/*0022*/ uint16_t zoneInstance;
/*0024*/
};

(from zone.log)
Jul 04 2014 15:13:31:448 [Decoded] [Server->Client] [Size: 52]
[OPCode: 0x3eba]
[Name: OP_SendZonePoints][Updated: 10/27/05][Type: zonePointsStruct (28) nc]
000 | 01 00 00 00 01 00 00 00 33 f3 cd 44 cd ac 4a 44 | ........3..D..JD
016 | 00 00 74 42 00 00 02 43 2f 00 00 00 00 00 00 00 | ..tB...C/.......
032 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
048 | 00 00 00 00

Is this worth pursuing? It seems on track with the forum guidance regarding inconsistencies in struct sizes. I should also note that the console window didn't produce any useful error messages about inconsistent opcodes or struct sizes during these captures.

Also, there are many entries in the log file of which I'm not sure of the significance. What do these mean?
Examples:
(opcode but zero size)
Jul 04 2014 15:13:15:244 [Decoded] [Server->Client] [Size: 0]
[OPCode: 0x3cdc]

(opcode and size but no label)
Jul 04 2014 15:13:18:256 [Decoded] [Server->Client] [Size: 768]
[OPCode: 0x1234]
000 | bf 00 00 00 03 00 03 00 09 00 09 00 12 00 12 00 | ................
016 | 13 00 13 00 21 00 77 21 39 00 5e 21 3d 00 3d 00 | ....!.w!9.^!=.=.
032 | 3f 00 3f 00 40 00 40 00 48 00 48 00 50 00 50 00 | ?.?.@[email protected].
.... to 768

(opcode and name but no size)
Jul 04 2014 15:13:20:268 [Decoded] [Client->Server] [Size: 0]
[OPCode: 0x7ac5]
[Name: OP_ReqNewZone][Updated: 10/27/05]

(a gigantic one that I'm not sure what to make of - seems to contain opcode information later on)
Jul 04 2014 15:13:31:448 [Decoded] [Server->Client] [Size: 4294967295]
[OPCode: 0000]
000 | 00 00 fe d5 00 00 00 00 00 00 ff ff ff ff 00 00 | ................
016 | 00 00 62 00 09 00 e6 47 0f 00 00 00 00 00 00 00 | ..b....G........
032 | 00 00 00 00 00 fd 01 00 00 31 00 00 00 00 00 00 | .........1......
048 | 00 94 11 00 7f 00 00 00 00 66 66 6c 42 00 80 c1 | .........fflB...
064 | 43 00 00 58 43 49 54 36 33 5f 41 43 54 4f 52 44 | C..XCIT63_ACTORD
080 | 45 46 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | EF..............
096 | 00 00 00 00 00 fe d5 00 00 00 00 00 00 ff ff ff | ................
....

Thoughts?

// A

[Someone]

They are encrypting spawn info, dont think this is something they ever did on live, so you're going to have to get much deeper, I have my doubts its easily fixable.

[ohhello]

I'm not sure if I am barking up the wrong tree but I applied some of the techniques that others have been discussing and found a couple of inconsistencies that I'm not sure are relevant. I generated a zone log and then compared the data with structs that are currently in the 5.2.2.0 everquest.h. All but two of the structs that I have found so far are consistent as far as size but there were two exceptions:

First exception: In everquest.h, ServerZoneEntryStruct has a length of 383 octets but the struct was logged as size 385:
(from everquest.h)
/*
** Server Zone Entry struct
** Length: 383 Octets
** OpCode: ZoneEntryCode (when direction == server)
*
* This is just a spawnStruct for the player
*/
struct ServerZoneEntryStruct : public spawnStruct
{
};

(from zone.log)
Jul 04 2014 15:13:20:033 [Decoded] [Server->Client] [Size: 385]
[OPCode: 0x7213]
[Name: OP_ZoneEntry][Updated: 10/27/05][Type: ServerZoneEntryStruct (385) ==]
000 | 00 00 00 00 00 00 00 4d 53 3c 20 22 45 59 39 5a | .......MS< "EY9Z
016 | 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | <...............
032 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
048 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
064 | 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 00 | ................
080 | 00 00 00 00 00 00 4e 29 00 00 00 00 00 00 00 00 | ......N)........
096 | bb 52 ce bb 46 00 2f 00 00 00 00 cd 34 00 00 00 | .R..F./.....4...
112 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
128 | 00 00 00 00 00 00 00 00 00 00 00 49 00 00 00 00 | ...........I....
144 | 00 00 00 00 00 00 00 4b 00 00 00 00 00 00 00 00 | .......K........
160 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
176 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
192 | 00 00 00 00 00 4f 00 00 00 53 00 00 00 31 00 00 | .....O...S...1..
208 | 00 4a 00 00 00 39 00 00 00 4f 00 00 00 53 00 00 | .J...9...O...S..
224 | 00 23 00 00 00 9e 00 00 00 0b 79 33 70 00 da 49 | .#........y3p..I
240 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
256 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
272 | 00 00 00 00 b0 b2 c9 b7 00 00 00 00 40 00 00 00 | ............@...
288 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
304 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
320 | 00 00 00 00 d0 aa d6 73 00 00 00 5b 00 00 4b 32 | .......s...[..K2
336 | 00 00 00 b7 37 55 00 00 00 00 00 00 00 00 00 ae | ....7U..........
352 | 00 00 00 cc 00 00 00 b7 00 00 00 c7 00 00 00 b2 | ................
368 | 00 00 00 ae 00 00 00 cc 00 00 00 b7 00 00 00 c7 | ................
384 | 00

Second exception: In everquest.h, zonePointsStruct has length of 24 octets but is logged with 52:
(from everquest.h)
/*
** ZonePoint
** Length: 24 Octets
** Sent as part of zonePointsStruct
*/

struct zonePointStruct
{
/*0000*/ uint32_t zoneTrigger;
/*0004*/ float y;
/*0008*/ float x;
/*0012*/ float z;
/*0016*/ float heading;
/*0020*/ uint16_t zoneId;
/*0022*/ uint16_t zoneInstance;
/*0024*/
};

(from zone.log)
Jul 04 2014 15:13:31:448 [Decoded] [Server->Client] [Size: 52]
[OPCode: 0x3eba]
[Name: OP_SendZonePoints][Updated: 10/27/05][Type: zonePointsStruct (28) nc]
000 | 01 00 00 00 01 00 00 00 33 f3 cd 44 cd ac 4a 44 | ........3..D..JD
016 | 00 00 74 42 00 00 02 43 2f 00 00 00 00 00 00 00 | ..tB...C/.......
032 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
048 | 00 00 00 00

Is this worth pursuing? It seems on track with the forum guidance regarding inconsistencies in struct sizes. I should also note that the console window didn't produce any useful error messages about inconsistent opcodes or struct sizes during these captures.

Also, there are many entries in the log file of which I'm not sure of the significance. What do these mean?
Examples:
(opcode but zero size)
Jul 04 2014 15:13:15:244 [Decoded] [Server->Client] [Size: 0]
[OPCode: 0x3cdc]

(opcode and size but no label)
Jul 04 2014 15:13:18:256 [Decoded] [Server->Client] [Size: 768]
[OPCode: 0x1234]
000 | bf 00 00 00 03 00 03 00 09 00 09 00 12 00 12 00 | ................
016 | 13 00 13 00 21 00 77 21 39 00 5e 21 3d 00 3d 00 | ....!.w!9.^!=.=.
032 | 3f 00 3f 00 40 00 40 00 48 00 48 00 50 00 50 00 | ?.?.@[email protected].
.... to 768

(opcode and name but no size)
Jul 04 2014 15:13:20:268 [Decoded] [Client->Server] [Size: 0]
[OPCode: 0x7ac5]
[Name: OP_ReqNewZone][Updated: 10/27/05]

(a gigantic one that I'm not sure what to make of - seems to contain opcode information later on)
Jul 04 2014 15:13:31:448 [Decoded] [Server->Client] [Size: 4294967295]
[OPCode: 0000]
000 | 00 00 fe d5 00 00 00 00 00 00 ff ff ff ff 00 00 | ................
016 | 00 00 62 00 09 00 e6 47 0f 00 00 00 00 00 00 00 | ..b....G........
032 | 00 00 00 00 00 fd 01 00 00 31 00 00 00 00 00 00 | .........1......
048 | 00 94 11 00 7f 00 00 00 00 66 66 6c 42 00 80 c1 | .........fflB...
064 | 43 00 00 58 43 49 54 36 33 5f 41 43 54 4f 52 44 | C..XCIT63_ACTORD
080 | 45 46 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | EF..............
096 | 00 00 00 00 00 fe d5 00 00 00 00 00 00 ff ff ff | ................
....

Thoughts?

// A

Looking at the two opcodes you mentioned it doesn't look like either of them are the wrong size. The first struct is a spawnStruct which is 385 bytes (the comment in the header must be off because spawnStruct does appear to be 385.) The second opcode is actually zonePointsStruct (not zonePointStruct) which looks to be a wrapper around zonePointStruct for the 52 byte packet.

Something is causing a memory leak which makes the client crash eventually, i'd wager it's struct changes from the con color updates.