EQ Patch 08-12-2009

[tarwyn]

Quite a few opcodes changed, but I haven't seen any struct changes (yet).

Here's some of the new opcodes I've found, but there'll be quite a few more.



<opcode id="6A86" name="OP_NpcMoveUpdate" updated="06/12/09">
<comment>Position updates</comment>
<payload dir="server" typename="uint8_t" sizechecktype="none"/>
</opcode>

<opcode id="6546" name="OP_DeleteSpawn" updated="06/12/09">
<comment>old DeleteSpawnCode</comment>
<payload dir="both" typename="deleteSpawnStruct" sizechecktype="match"/>
</opcode>

<opcode id="3AD9" name="OP_ZoneEntry" updated="06/12/09">
<comment>old ZoneEntryCode</comment>
<payload dir="client" typename="ClientZoneEntryStruct" sizechecktype="match"/>
<payload dir="server" typename="uint8_t" sizechecktype="none"/>
</opcode>

<opcode id="35B1" name="OP_GuildMOTD" updated="06/12/09">
<comment>GuildMOTD</comment>
<payload dir="server" typename="guildMOTDStruct" sizechecktype="none"/>
</opcode>


-T

[sammie]

On test the spam filter changes caused significant changes to channelMessageStruct (OP_CommonMessage OpCode). The most notable of which were changing from fixed length field for originator and recipient to variable length, null terminated name fields, and some changes in the order certain fields appear in the packet.

Were there no changes to channelMessageStruct on live today? I can't imagine the spam filters working properly without it.

[tarwyn]

Yes, I noticed the moment I zoned into PoK; the channelMessage struct got changed the way you say. Both name fields are now dynamic, and channelMessages will crash SEQ.

-T

[tarwyn]

Tried to come up with a fix to the channel message mess; here's a rather ugly solution to the issue.

everquest.h, line 1554:


/*
** Channel Message received or sent
** Length: variable
** OpCode: ChannelMessageCode
*/

struct channelMessageStruct
{
/*0000*/ char data[0]; // variable data
};
/*
** New channel message struct
*/
struct channelMessageDataStruct
{
/*0000*/ char * target;
/*0004*/ char * sender;
/*0008*/ uint32_t unknown0008;
/*0012*/ uint32_t language; // Language
/*0016*/ uint32_t chanNum; // Channel
/*0020*/ int8_t unknown0020[5]; // ***Placeholder
/*0025*/ uint32_t skillInLanguage; // senders skill in language
/*0029*/ char * message; // Variable length message
};
messageshell.cpp, line 39: see next post

-T

[tarwyn]

Did some more tweaks to the messageshell.cpp in order to get stuff to display correctly. Here's the entire channelMessage function:

messageshell.cpp, line 39:


void MessageShell::channelMessage(const uint8_t* data, size_t len, uint8_t dir)
{
channelMessageDataStruct cmds;
const channelMessageDataStruct * cmsg=&cmds;

cmds.target=(char *)data;
int len_target=0;
while(cmds.target[len_target]!=0 && len_target<32768)
len_target+=1;

cmds.sender=(char *)(data+len_target+1);
int len_sender=0;
while(cmds.sender[len_sender]!=0 && len_sender<32768)
len_sender+=1;

cmds.language = *(uint32_t *)(data+len_target+len_sender+6);
cmds.chanNum = *(uint32_t *)(data+len_target+len_sender+6+4);
cmds.skillInLanguage = *(uint32_t *)(data+len_target+len_sender+6+4+4+5);
cmds.message = (char *)(data+len_target+len_sender+6+4+4+5+4);

// Tells and Group by us happen twice *shrug*. Ignore the client->server one.
if (dir == DIR_Client &&
(cmsg->chanNum == MT_Tell || cmsg->chanNum == MT_Group || cmsg->chanNum == MT_OOC ||
cmsg->chanNum == MT_Shout || cmsg->chanNum == MT_Auction || cmsg->chanNum == MT_Guild))
{
return;
}

QString tempStr;

bool target = false;
if (cmsg->chanNum >= MT_Tell)
target = true;

if (cmsg->language)
{
if ((cmsg->target[0] != 0) && target)
{
tempStr.sprintf( "'%s' -> '%s' - %s {%s}",
cmsg->target,
cmsg->sender,
cmsg->message,
(const char*)language_name(cmsg->language)
);
}
else if(!target)
{
tempStr.sprintf( "'%s' - %s",
cmsg->target,
cmsg->message
);
}
else
{
tempStr.sprintf( "'%s' - %s",
cmsg->sender,
cmsg->message
);
}
}
else // Don't show common, its obvious
{
if ((cmsg->target[0] != 0) && target)
{
tempStr.sprintf( "'%s' -> '%s' - %s",
cmsg->target,
cmsg->sender,
cmsg->message
);
}
else if(!target)
{
tempStr.sprintf( "'%s' - %s",
cmsg->target,
cmsg->message
);
}
else
{
tempStr.sprintf( "'%s' - %s",
cmsg->sender,
cmsg->message
);
}
}

m_messages->addMessage((MessageType)cmsg->chanNum, tempStr);
}


Not pretty, but this at least gets it working again.

-T

[rogues]

Downloaded a fresh 5.13.5.0 and applied these changes. It could be that I've done something wrong - I get a segmentation fault just after it shows the zone:

Warning: OP_GuildMOTD (0x2042) (dataLen: 132) doesn't match.

This is after making the changes to messageshell.cpp and everquest.h. Very possible I'm doing something wrong if this is working for you.

[tarwyn]

Rogues, I haven't figured out what opcode that is. Comment out the opcode 2042 in zoneopcodes.xml until we've got more info. I am not very good at figuring out the new opcodes unfortunately.

-T

[rogues]

Ahhh ok, I'll try that when I get home and let you know.

Thanks!

[ieatacid]

<opcode id="35B1" name="OP_GuildMOTD" updated="08/12/09">
<comment>GuildMOTD</comment>
<payload dir="server" typename="guildMOTDStruct" sizechecktype="none"/>
</opcode>

[rogues]

Thanks!

Ok, it doesn't crash now, but I'm not seeing spawns, just myself.

[tarwyn]

Did you update the other opcodes I posted in the 1st post?

-T

[rogues]

Ok, that worked, feeling pretty moronic.

It works, gets spawns, and then after a few seconds it gives a segmentation fault. I've doublechecked things, it looks like I got it all this time, don't know how I missed those opcodes.

[ImNotDeadYet]

Mine is working with the changes above as long as my group members are not in the same zone. As soon as I and a group member (box) enter the same zone, it seg faults.

INDY

[fransick]

Not sure this is across the board for everyone but here's a backtrace of segfault when zoning:



#0 0x0040abcc in memcpy () from /lib/libc.so.6
#1 0x0816d87e in ZoneMgr::qt_invoke (this=0xbf856fff, _id=173741592,
_o=0xbf850edc) at zonemgr.cpp:274
#2 0x02ddbc4a in QObject::activate_signal ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#3 0x080902bf in EQPacketDispatch::signal (this=0xa20ba58,
t0=0xbf851203 "Wi", t1=10, t2=2 '\002') at packetinfo.moc:99
#4 0x0808d641 in EQPacketStream::dispatchPacket (this=0xa288268,
data=0xbf851203 "Wi", len=10, opCode=18744, opcodeEntry=0xa1d6f68)
at packetstream.cpp:435
#5 0x0808e04c in EQPacketStream::processPacket (this=0xa288268,
packet=@0xbf851038, isSubpacket=true) at packetstream.cpp:713
#6 0x0808e23a in EQPacketStream::processPacket (this=0xa288268,
packet=@0xbf851130, isSubpacket=false) at packetstream.cpp:801
#7 0x0808efca in EQPacketStream::handlePacket (this=0xa288268,
packet=@0xbf851130) at packetstream.cpp:566
#8 0x08098d4e in EQPacket::dispatchPacket (this=0xa34d458, packet=@0xbf851130)
at packet.cpp:659
#9 0x08098f5c in EQPacket::dispatchPacket (this=0xa34d458, size=94,
buffer=0xbf8511ca "E") at packet.cpp:583
#10 0x0809aaf9 in EQPacket::qt_invoke (this=0xa34d458, _id=2, _o=0xbf853248)
at packet.cpp:400
#11 0x02ddbc4a in QObject::activate_signal ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#12 0x02ddc63d in QObject::activate_signal ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#13 0x0316bd19 in QTimer::timeout () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#14 0x02e0328f in QTimer::event () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#15 0x02d723db in QApplication::internalNotify ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#16 0x02d739e1 in QApplication::notify ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#17 0x02d66322 in QEventLoop::activateTimers ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#18 0x02d19e1f in QEventLoop::processEvents ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#19 0x02d8bd02 in QEventLoop::enterLoop ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#20 0x02d8bbc6 in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#21 0x02d7201f in QApplication::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#22 0x08067402 in main (argc=136571048, argv=0xbf853e84) at main.cpp:723
Also working to fix:



Warning: OP_InspectAnswer (0x6145) (dataLen: 10) doesn't match: sizeof(inspectDataStruct):1860
Warning: OP_InspectAnswer (0x6145) (dataLen: 10) doesn't match: sizeof(inspectDataStruct):1860

[ieatacid]

<opcode id="0FF4" name="OP_InspectAnswer" updated="08/12/09">
<comment>old InspectDataCode</comment>
<payload dir="both" typename="inspectDataStruct" sizechecktype="match"/>
</opcode>

[ieatacid]

fransick, this will fix that crash


<opcode id="6967" name="OP_SendZonePoints" updated="08/12/09">
<comment>Coords in a zone that will port you to another zone</comment>
<payload dir="server" typename="zonePointsStruct" sizechecktype="none"/>
</opcode>

[rogues]

Yes! I can confirm that that fixes the crashes and I seem to be up and running.

Thanks!!!!

[rogues]

Just an FYI, a couple things:

1. It's not picking up despawns properly, it leaves the object where it despawns (at least for players).

2. I'm getting errors:
"Debug: SpawnShell::fillSpawnStruct - expect lengh: 345, read: 341 for spawn XXXX'" I'm not sure what affect that's having but maybe it's related to #1.

Thanks again for everybody's help with this!!!

[ieatacid]

I've updated all the opcodes and changed some of the source code.

I removed the handling for OP_RespawnFromHover because as I was going through it and testing, it appeared to work fine without that -- let me know if this causes any issues.

SVN is current with these changes or you can grab a diff from here (http://www.ieatacid.com/20090816.diff).

[ieatacid]

Just an FYI, a couple things:

1. It's not picking up despawns properly, it leaves the object where it despawns (at least for players).

2. I'm getting errors:
"Debug: SpawnShell::fillSpawnStruct - expect lengh: 345, read: 341 for spawn XXXX'" I'm not sure what affect that's having but maybe it's related to #1.

Thanks again for everybody's help with this!!!

1: Should be fixed with the updated opcodes.

2: Fixed on SVN and the diff in my previous post.

[fransick]

1: Should be fixed with the updated opcodes.

2: Fixed on SVN and the diff in my previous post.


As always, thanks to Ieatacid for the assist. My skills have definitely erroded over the years, so much so, I usually end up waiting for someone smarter than me to come to the rescue.

[rogues]

Diff applied, it seems to be working great!

I want to thank everybody for their work on this, it's very much appreciated, I can't say it enough.

[eqhunter]

when will the new build be posted?

[ieatacid]

Tomorrow.

I was waiting to see if there were any additional things that might've been missed.

[eqhunter]

Thanks Toons

[BlueAdept]

I believe there is another patch tomorrow. Might want to wait until after that to see if anything changes.

[Backspace]

Applied the diff and all looks good to go so far. Thank you.


I've updated all the opcodes and changed some of the source code.

I removed the handling for OP_RespawnFromHover because as I was going through it and testing, it appeared to work fine without that -- let me know if this causes any issues.

SVN is current with these changes or you can grab a diff from here (http://www.ieatacid.com/20090816.diff).

[SaLato]

I tried to use the patch and it doesnt work for me.

Here is what I am trying to do.

Create a filter and match the following ports

sip 5060
mydefinedport 4000-5000,8000-8999
rtsp 554

Is the patch intended to work with the above setup?

[ieatacid]

I'm not sure what you mean, but you don't even need that patch. There's a tarball posted in the News section that includes all of those changes plus others.