EQEMU v0.6.2, My Experience

[vRandom]

Maybe one of you can make sence of this...

I think this is where the error is returned

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;
	}

OP_ClientUpdate expected:38 got 36

now if i look for the PlayerPositionUpdateClient_Struct

I find

/*
** Player position update
**	Struct sent from client->server to update
**	player position on server
**
*/
struct PlayerPositionUpdateClient_Struct
{
/*0000*/ uint16	spawn_id;
/*0022*/ uint16	sequence;	//increments one each packet
/*0004*/ float y_pos;                 // y coord
/*0008*/ float delta_z;            // Change in z
/*0016*/ float delta_x;            // Change in x
/*0012*/ float delta_y;            // Change in y
/*0020*/ signed animation:10;     // animation
         signed delta_heading:10;  // change in heading
         signed padding0020:12;   // ***Placeholder (mostly 1)
/*0024*/ float x_pos;                 // x coord
/*0028*/ float z_pos;                 // z coord
/*0034*/ unsigned heading:12;     // Directional heading
         unsigned padding0004:4;  // ***Placeholder
/*0032*/ uint8 unknown0006[2];  // ***Placeholder
/*0036*/
};

Now if i'm understanding this doesn't that last line /*0036*/ mean this is 36 byte, then how does it expect 38, the only thing i dont understand is app->size since its part of the if statement and i either dont understand it or its being set to 38 somewhere which causes this to expect a 38 when it only gets a 36...

does any of that make sence?
vRandom

I'm not a c programmer so i could be totaly not reading it correctly...

[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...

[vRandom]

WildcardX,

That would be a good question, hummm

Can we get it form the peq server, i mean dont they have one that works?
vRandom

[WildcardX]

Thats a good question. I hope that is the answer. I did log onto the PEQ server over the weekend to make sure my client worked, but I didnt try to attack anything. When I get home (I am at work right now. I am a c++ and c# developer for a software company and a project I just completed is being tested out by the bug team so I have some down time right now) I'll have to log back onto PEQ to see if I can attack anything.

[vRandom]

Cool, I'm in that downtime spot atm too... but i work from home so i can make downtime but today is vacation day

I refuse to work and more than i must today... lol

I'm running around and killing stuff with spells and just goofing off atm

I am getting this when i'm sitting in a zone and doing nothing for awhile.

[Error] Unhandled incoming opcode: OP_Unknown (#0, eq=0x0000), size: 8, Client:
Blahs
   0: 49 DD 12 00 00 DD 12 00                            | I.......

though i dont understand how to figure out what they are...
vRandom

edit: sure i open my mouth about being on vacation and the damn phone rings and now i have to go fix something grrrrrrr

[WildcardX]

Anyone know if this ever got done?

case CLIENT_CONNECTED: {
ClientPacketProc p;
p = ConnectedOpcodes[opcode];
if(p == NULL) {
//TODO: replace this 0 with the EQ opcode
LogFile->write(EQEMuLog::Error, "Unhandled incoming opcode: %s (#%d, eq=0x%04x), size: %i, Client: %s", OpcodeNames[opcode], opcode, 0, app->size, GetName());
if(app->size<1000)
DumpPacket(app->pBuffer, app->size);
else{
cout << "Dump limited to 1000 characters:\n";
DumpPacket(app->pBuffer, 1000);
}
break;
}

Notice that comment: //TODO: replace this 0 with EQ opcode... In the source I am looking at, it seems:

p = ConnectedOpcodes[opcode];
if(p == NULL)

is kicking out the error message when zone.exe starts for a char about OP_AnnoyingZoneUnknown. Thats the first error message we see in zone.exe before we start seeing all those messages about OP_ClientUpdate. Unfortunately, I can not debug this at work atm and will have to wait until I get home to place a break point here to see what this value is.

[Status] 99875 New client from ipxxxxxxxxx port:1038
[Error] Unhandled incoming opcode: OP_AnnoyingZoneUnknown (#299
e: 8, Client: Tallerin
0: 37 02 00 00 40 00 00 00 | 7...
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:37
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36

EDITED: I think I am on to something.. I dont know what OP_AnnoyingZone opcode is suppose to do, but I believe it is wrong in opcodes.cfg. The above log is truncated. (#299 is missing some digits) Right now in the latest opcodes.cfg, OP_AnnoyingZone equals = 0x63da which is 25562 in decimal. The missing digits from the above log, #299... This is the opcode that OP_AnnoyingZone should be, right? I think I am correct but it will have to wait until I get home to check for sure. Meanwhile, if someone wants to try this, just run your server and note that error message and get the full 5 digit number from your output. Then open a calc in windows and switch it to scientific view. Then select "decimal" and type in that 5 digit number, then select "hex" and you should get a number like 0x63da. Then replace that number in your opcodes.cfg for OP_AnnoyingZone and then rerun your server and BE SURE TO COME BACK TO THIS THREAD AND REPORT RESULT THX!!

[jillmatik]

I can start testing this now.. here's my error code.. what number should i replace in opcodes.conf ??

Received Message SyncWorldTime
Time Broadcast Packet: EQTime [10:26 pm]
[Status] 161941651 New client from ip:ipaddress port:1964
[Status] Weather should change in 6932 seconds
[Error] Unhandled incoming opcode: OP_AnnoyingZoneUnknown (#299, eq=0x0000), size: 8, Client: Test
0: 38 02 00 00 40 00 00 00 | 8...@...
[Error] Unhandled incoming opcode: OP_AnnoyingZoneUnknown (#299, eq=0x0000), size: 8, Client: Test
0: 38 02 00 00 80 00 00 00 | 8.......
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36

Just tried editing the opcodes.conf file with the updated hex number. This was the resulting output:

Received Message SyncWorldTime
Time Broadcast Packet: EQTime [02:28 am]
[Status] 196613 New client from ip:ipaddress port:1997
[Error] Unhandled incoming opcode: OP_Unknown (#0, eq=0x0000), size: 8, Client: Test
0: 3A 02 00 00 40 00 00 00 | :...@...
[Error] Unhandled incoming opcode: OP_Unknown (#0, eq=0x0000), size: 8, Client: Test
0: 3A 02 00 00 80 00 00 00 | :.......
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36

I agree.. hopefully someone will chime in! Worth a shot though thanks for the work!

[jillmatik]

You guys are blowin my mind here.. I'm so clueless about this stuff. From the snipets you've posted, it seems that the problem area has been isolated and I really hope you can stick with it and find something!

I think I'm doin good if I can just edit some ini files lmao! Keep at it!

[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?

[tallerin]

Also i have to agree the opcode in the opcode.conf is the right one as i get 0x14cb for the OP_ClientUpdate from peq server when i ran a packetcollector

[WildcardX]

It is true that different platforms will get different sizeof() results for datatypes. I did notice in that structure you mentied above that some structure members are declared as a float instead of the cross platform accepted float32 type, for example. That could result in a different sizeof(structure) result.

[MikeyUSC]

/*
** Player position update
**	Struct sent from client->server to update
**	player position on server
**
*/
struct PlayerPositionUpdateClient_Struct
{
/*0000*/ uint16	spawn_id;
/*0022*/ uint16	sequence;	//increments one each packet
/*0004*/ float y_pos;                 // y coord
/*0008*/ float delta_z;            // Change in z
/*0016*/ float delta_x;            // Change in x
/*0012*/ float delta_y;            // Change in y
/*0020*/ signed animation:10;     // animation
         signed delta_heading:10;  // change in heading
         signed padding0020:12;   // ***Placeholder (mostly 1)
/*0024*/ float x_pos;                 // x coord
/*0028*/ float z_pos;                 // z coord
/*0034*/ unsigned heading:12;     // Directional heading
         unsigned padding0004:4;  // ***Placeholder
/*0032*/ // COMMENT ME OUT!! uint8 unknown0006[2];  // ***Placeholder
/*0036*/
};

Simply comment out the last line, and all is well..

RadarBlipBox on the LoginServer is now running with this modification..try & see if anyone has any problems..

[jillmatik]

I'll definitely try this server once I get home from work. If this does turn out to be the fix, would greatly appreciate a link for any updated files! I have no way to compile any updates :(

Thanks,
J

[tallerin]

wooohooo thats it i can move somewhere else and attack and it works on radarblipbox