I found a bug in the way the server processes a /zone command. (This doesn't apply to emu's #zone, just the /zone command you can use when your GM flag is on.)
In my example, /zone Natimbi would take me to Erudin instead.
Packetcollect output for both a /zone Erudnext and /zone Natimbi:
*** This packet was generated by /zone erudnext
OPCode 0x0185 (OP_GMZoneRequest) [Raw OPCode: 0x0185] [Size: 88]
[192.168.0.5:1312 -> 192.168.0.1:7999]
[CPU Tick Count: 5603453]
0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 | ................
16: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 | ................
32: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 | ................
48: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 | ................
64: 18 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 | ................
80: 00 00 00 00 00 00 00 00 | ........
*** This packet was generated by /zone Natimbi
OPCode 0x0185 (OP_GMZoneRequest) [Raw OPCode: 0x0185] [Size: 88]
[192.168.0.5:1317 -> 192.168.0.1:7995]
[CPU Tick Count: 5616125]
0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 | ................
16: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 | ................
32: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 | ................
48: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 | ................
64: 18 01 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 | ................
80: 00 00 00 00 00 00 00 00 | ........
The cause of the problem pretty much jumps out at ya: the server's only looking at one byte (the 0x1
when it should be looking at 2 bytes. Evidently with the GoD zones, they started needing to use 2 bytes, and Natimbi happens to have its first byte as 0x18 too.
Bug in server processing of OP_GMZoneRequest
Threaded Mode
