Logs related to my #zone PoK book issues

[Andrew80k]

Ok, I'm getting some errors in the logs that may (or may not) be related to my zone crash issues with books and the #zone command. I thought I'd post this to see if someone had some ideas.

[02.25. - 20:50:57] [ZONE__INIT] Starting EQ Network server on port 7005
[02.25. - 20:52:46] The next weather check for zone: qeynos2 will be in 5254 seconds.
[02.25. - 20:52:51] Zone: qeynos2 has weather of type 1.
[02.25. - 20:52:51] Zone: qeynos2(2) has weather type = 1. The weather timer has been enabled.
[02.25. - 20:52:51] [WORLD__CLIENT] New connection from 192.168.1.101:2169
[02.25. - 20:52:52] [NET__IDENT_TRACE] 192.168.1.101:2169: First opcode 0x7752 did not match expected 0x2792
[02.25. - 20:52:52] [NET__IDENT_TRACE] 192.168.1.101:2169: Tried patch 6.2_world, and it did not match.
[02.25. - 20:52:52] [NET__IDENT_TRACE] 192.168.1.101:2169: First opcode 0x7213 did not match expected 0x2ec9
[02.25. - 20:52:52] [NET__IDENT_TRACE] 192.168.1.101:2169: Tried patch 6.2_zone, and it did not match.
[02.25. - 20:52:52] [NET__IDENT_TRACE] 192.168.1.101:2169: First opcode 0x7752 did not match expected 0x4dd0
[02.25. - 20:52:52] [NET__IDENT_TRACE] 192.168.1.101:2169: Tried patch Titanium_world, and it did not match.
[02.25. - 20:52:52] [NET__IDENT_TRACE] 192.168.1.101:2169: First opcode matched 0x7213 and length matched 68
[02.25. - 20:52:52] [NET__IDENTIFY] Identified stream 192.168.1.101:2169 with signature Titanium_zone
[02.25. - 20:52:52] [WORLD__CLIENT] New client from 192.168.1.101:2169
[02.25. - 20:53:14] [CLIENT__NET_ERR] Vallorean: Unhandled incoming opcode: [OpCode OP_WeaponEquip2 (0x63da) Size=8]
[02.25. - 20:53:14] [CLIENT__NET_ERR] Vallorean: Unhandled incoming opcode: [OpCode OP_WeaponEquip2 (0x63da) Size=8]
[02.25. - 20:53:14] [CLIENT__NET_ERR] Vallorean: Unhandled incoming opcode: [OpCode OP_WeaponEquip1 (0x6c5e) Size=12]

Any ideas?

[Andrew80k]

So the logs above have nothing to do with my issue. I'm working my way through the code and here is my research thus far:

I hooked a debugger up to the zone.exe process, logged in and clicked on the book in North Qeynos. The debugger output then pointed me to the Client::ZonePC method. To this section:

	pShortZoneName = database.GetZoneName(zoneID);
	database.GetZoneLongName(pShortZoneName, &pZoneName);
	iZoneNameLength = strlen(pZoneName);  <--- Access violation here.

I thought that was kind of odd, so I put it some debug out put to get the values of things as I'm going along. And it turns out that Database::GetZoneLongName is actually not putting anything into the reference of pZoneName, so it remains null. So when you call the strlen function on a null value, you get the access violation. What I haven't figured out yet is why GetZoneLongName doesn't actually put a value into the reference. I'm not getting any errors back from the call I'm at a loss at this point. I'm going to keep pushing debug into it until I figure it out.

Interestingly, I've noticed when I was playing that when I'd zone, the message in the chat window that came up after you zoned, the one after "Loading please wait...", was always "You have entered Long name missing..", but it didn't seem to affect anything so I ignored it. I looked in the DB and the long names are certainly there. Since everyone is not having this problem, I'm wondering why I am. But now it seems related to the PoK books and #zone command. Anyway, if anyone has ideas, let me know. Thanks.

[AndMetal]

I wonder if it has anything to do with the books basically being a door (listed in the doors table?

Then again, I'm running 1091 of the emu (on Linux), and as far as I know, I'm not seeing any of those issues.

[Andrew80k]

Maybe, but I kinda don't think so. When I click on the book the zone short name actually comes back correctly and is passed correctly to the Database::GetZoneLongName method, so I think the door functionality part of it works fine. The problem comes in not getting a Long zone name back from the method call. I don't actually think there is something wrong with the code so much as it may actually be in the query due to my version of mysql, maybe. I'm using the latest I think, or very close. I'm hoping to do some debugging of the query call tonight to see exactly what it's getting. I have a work around in the code that actually makes it stop crashing the zone, but I'd like to figure out why I'm not getting the long names back.

I find it interesting that the call to Database::GetZoneLongName returns a boolean, but it's only related to the database query not the fact that there is a long name or not and that boolean value isn't checked for. It seems to me it should return false if there is no long name and then that value should be checked for before it proceeds to do anything with the value that may or may not have been returned. Or it could just simply return the value of the Long Name or some default. That way you always have at least "something" to use in further processing. Maybe if no Long Name is found just default to the short name? I don't know. I've only been looking at it a couple of days.

[Andrew80k]

Well, don't I just feel like a dumbass. Problem the whole time was no graveyard_id column in the zone table though I could have sworn I added it. Chalk one up to RTFM... or lack thereof.

[AndMetal]

Well, at least if it happens again, we'll know how to fix it

[Andrew80k]

The fact that I wasn't getting the error in the logs threw me off. As soon as I stuck the log write statement into the failure condition of the query it showed up and I knew. /shrug.