[deazone]

Originally Posted by WildcardX

vRandom,

I was just looking at that exact code! the reason why the server is "expecting 38" is because it is getting that number from the sizeof(STRUCT) function.. So 38 in this code is pretty much a constant as the memory signature of the PlayerPositionUpdateClient_Struct doesnt change. What is changing, the "36" and "37" from app->size is the size of that same struct the client is sending to the server. In effect, the server expects the size of this structure to be 38 bytes long, but the client is sending 2 different PlayerPositionUpdateClient_Struct sizes of 36 and 37 bytes. Upon reviewing the code further, I see this struct is instrumental in determining both player coordinate position in the eq world as well as positions of mobs. I'm still trying to understand this more so I can attempt a fix. I would think its simply the opcode for the OP_ClientUpdate is wrong and that we simply need to recapture this packet, but what I am confused about is why the client is sending 2 different sizes for the same structure unless the client has changed and broken what was once OP_ClientUpdate into 2 different opcodes...

6.1dr1 also receives two OP_ClientUpdates
as shown below:
[Error] OP size error: OP_ClientUpdate expected:30 got:31

Normally the 6.1 client does send 30 bytes.

I believe the opcode in opcodes.conf is correct. I believe it is serverside which is not allocating the PlayerPositionUpdateClient_Struct correctly.

void Client::Handle_OP_ClientUpdate(const EQZonePacket *app)
  {
  	if (IsAIControlled())
  		return;
  	
  	if (app->size != sizeof(PlayerPositionUpdateClient_Struct)) {
 	LogFile->write(EQEMuLog::Error, "OP size error: OP_ClientUpdate expected:%i got:%i", sizeof(PlayerPositionUpdateClient_Struct), app->size);
  		return;

As you can see sizeof(PlayerPositionUpdateClient_Struct) is always showing as 38, the clients are sending the 36byte packet. Every now and then a 37 byte packet.

Could it be that:

VCPP is not allocating the same memory as GCC. Normally eqemu has no problem with the OS port. However perhaps something was missed. Does anyone have a linux server up that could confirm this?