Page 1 of 1
DoV+ Grid ID problem
Posted: Tue Dec 06, 2011 9:50 am
by John Adams
We need to get this
major issue resolved. I know Zcoretri is AFK, and has tried extensively to identify the problem with DoV+ clients, but neither of us have been able to figure out what's wrong here.
I need help, and am asking for others to get involved to see if we can root out why, when a player moves after login, their grid_id (location) goes to 0. With an invalid grid_id, spawns cannot be seen, and nearly everything about the emulator stops working.
This needs to be resolved.
Emails to LE have given us some hints, but so far it has not helped. I will email him again, now that AoD is coming, and see if he can spare a few hours to help us sort out these major issues.
From Me:
John Adams wrote:Ok, I have a question of my own. We’re attempting to use the DoV (1096) client, and I have discovered that when the player logs in, the zone populates fine. Soon as the player moves, the player goes to “grid_id 0” and all the spawns disappear (of course).
Zcoretri is trying to find where the data changed, because player movement has apparently lost it’s pos.grid_id or something… but we’re a little lost. You have any idea if this has changed before? And if so, what did you do to fix it?
We’re anticipating this to change again for the next expansion, which will (hopefully) become our stable, long-term client we’ll support.
His Response:
LethalEncounter wrote:Hey! More than likely one of the structs is off which is causing the server and the client to get out of sync in regards to the grid id. I would look at each struct that uses grid id, but I would first look at the (going off of memory here) the player update struct. It is hard coded in the eq2commonstructs.h file. That is the one where the client informs the server which grid it is in. The server does some wacky calculations to compare the new location with the old location. It might be as simple as adding a break point and reviewing the information set for the old client and compare that with the new client. If the info is different than the struct likely needs to be changed for the latest client.
If that doesn’t solve it:
If I remember correctly we had this same exact problem a while back. You might be able to find a clue on the forums looking at old posts and searching for grid_id.
Seriously need some help with this. Please take a look.
Re: DoV+ Grid ID problem
Posted: Tue Dec 06, 2011 10:06 am
by John Adams
Checking in Player.cpp, ProcessMovement(), here's the code I think LE is referring to:
Code: Select all
if(appearance.pos.grid_id != update->grid_location){
LogWrite(PLAYER__DEBUG, "Player", "%s left grid %u and entered grid %u", appearance.name, appearance.pos.grid_id, update->grid_location);
const char* zone_script = world.GetZoneScript(GetZone()->GetZoneID());
if (zone_script && lua_interface) {
lua_interface->RunZoneScript(zone_script, "enter_location", GetZone(), this, update->grid_location);
lua_interface->RunZoneScript(zone_script, "leave_location", GetZone(), this, appearance.pos.grid_id);
}
appearance.pos.grid_id = update->grid_location;
}
the update->grid_location value is not correct, and I think is causing the whole problem. That is derived from:
Code: Select all
Player_Update* update = (Player_Update*)movement_packet;
and is in this struct:
Code: Select all
struct Player_Update{
/*0000*/ int32 activity;
/*0004*/ float unknown2; // 1
/*0008*/ float direction1;
/*0012*/ float unknown3[8];
/*0044*/ float speed;
/*0048*/ float side_speed;
/*0052*/ float unknown4;
/*0056*/ float orig_x;
/*0060*/ float orig_y;
/*0064*/ float orig_z;
/*0068*/ float orig_x2;
/*0072*/ float orig_y2;
/*0076*/ float orig_z2;
/*0080*/ float unknown5[3];
/*0092*/ int32 unknown6;
/*0096*/ float unknown7[3];
/*0108*/ int32 unknown8;
/*0112*/ int32 grid_location;
/*0116*/ float x;
/*0120*/ float y;
/*0124*/ float z;
/*0128*/ float direction2;
/*0132*/ float unknown9;
/*0136*/ float unknown10;
/*0140*/ float speed_x;
/*0144*/ float speed_y;
/*0148*/ float speed_z;
};
but when I map out the values from the packet, the int32 grid_location; seems to still be in this same position. Unless I am doing something wrong?
Re: DoV+ Grid ID problem
Posted: Thu Dec 08, 2011 12:27 am
by Jabantiz
I looked into this briefly and from what I can tell the struct changed. I added DumpPacket(movement_packet, sizeof(Player_Update)); in Player::ProcessMovementData() just after Player_Update* update = (Player_Update*)movement_packet; and then logged in with the dov client and the sf client. It appears that a float value(my best guess) was added after the speed value.
Code: Select all
struct Player_Update{
/*0000*/ int32 activity;
/*0004*/ float unknown2; // 1
/*0008*/ float direction1;
/*0012*/ float unknown3[8];
/*0044*/ float speed;
float unknown11;
/*0048*/ float side_speed;
/*0052*/ float unknown4;
/*0056*/ float orig_x;
/*0060*/ float orig_y;
/*0064*/ float orig_z;
/*0068*/ float orig_x2;
/*0072*/ float orig_y2;
/*0076*/ float orig_z2;
/*0080*/ float unknown5[3];
/*0092*/ int32 unknown6;
/*0096*/ float unknown7[3];
/*0108*/ int32 unknown8;
/*0112*/ int32 grid_location;
/*0116*/ float x;
/*0120*/ float y;
/*0124*/ float z;
/*0128*/ float direction2;
/*0132*/ float unknown9;
/*0136*/ float unknown10;
/*0140*/ float speed_x;
/*0144*/ float speed_y;
/*0148*/ float speed_z;
};
This seems to work for me but I just checked this really quick and late at night. Also it will probably mess up all clients below dov as this is a static struct and not dynamic like everything else seems to be.
Re: DoV+ Grid ID problem
Posted: Thu Dec 08, 2011 7:16 am
by John Adams
Nice, I will look into your discovery tonight. I was going to work on this last night, but Xinux got me all excited about AoD client and I started fixing LoginServer to support it
As for this new(er) client changing this struct, I think we can manage that by using a different struct if the client version is > 1096 or something. That's what I'll try out later.
Did you notice if the grid_id stayed > 0 when you moved, with this fix in place? If so, then that's the fix for sure. Thank you!
Re: DoV+ Grid ID problem
Posted: Thu Dec 08, 2011 2:05 pm
by Jabantiz
I did that last night while half asleep but what I did was compare the 2 packets, data at the end of the packets seemed identical just it was 4 bytes off. I found the new bytes between speed and side_speed, wich now that I think about it is probably air_speed but have no way to verify that.
As for testing it I logged on with the dov client and ran around then logged off and back in, before with the dov client I would appear below the world when I logged back in, I assume because of the grid_id, now everything is fine. Not the best way to test it but it was late and I wasn't thinking
When I have the time I will check grid_id's, unless you beat me to it.
EDIT: Was able to run a quick test and with the change to the struct the grid_id is never being set to 0
Re: DoV+ Grid ID problem
Posted: Thu Dec 08, 2011 3:39 pm
by John Adams
Jabantiz wrote:EDIT: Was able to run a quick test and with the change to the struct the grid_id is never being set to 0
Dude, you just saved the entire project. Without a grid_id, we have been unable to spawn zones or test anything interactive.
I'll see about implementing it with a version check, unless you already have or want to give it a try yourself.
Re: DoV+ Grid ID problem
Posted: Thu Dec 08, 2011 4:02 pm
by Jabantiz
I'll let you do that, was planning on trying to figure out if there is an update trait app or if that huge packet needs to be resent every time, and that could take me a while.
Re: DoV+ Grid ID problem
Posted: Thu Dec 08, 2011 7:35 pm
by John Adams
Jabantiz and I are talking this out on IRC, and here's the results of my latest test. I printed the entire "update" struct in the ProcessMovement() function. Here's the results, looks a little odd...
For the 1008 (SF) client, I noticed the stream of cout's was steady during my entire dash, which was about 10s long. The moving packet data looked like this:
19:48:48 D Player: Player_Update being used.
update->activity: 128
update->unknown2: 5.60519e-045
update->direction1: 93.9623
update->unknown3[0]: 0
update->unknown3[1]: 0
update->unknown3[2]: 0
update->unknown3[3]: 1
update->unknown3[4]: 1
update->unknown3[5]: 1
update->unknown3[6]: 0
update->unknown3[7]: 0.56
update->speed: 7.5
update->side_speed: 0
update->unknown4: 0
update->orig_x: 0
update->orig_y: 0
update->orig_z: 0
update->orig_x2: 0
update->orig_y2: 0
update->orig_z2: 0
update->unknown5[0]: 0
update->unknown5[1]: 0
update->unknown5[2]: 0
update->unknown6: 4294967295
update->unknown7[0]: 0
update->unknown7[1]: -1
update->unknown7[2]: 0
update->unknown8: 0
update->grid_location: 924281492
update->x: 46.9899
update->y: -3.37848
update->z: 168.169
update->direction2: 93.965
update->unknown9: -0
update->unknown10: 0
update->speed_x: 7.48205
update->speed_y: 0
update->speed_z: -0.518597
On the 1096 (DoV) client, running the same path for the same length of time, the stream if cout's was intermittent - and came almost to a complete stop just before I reached Murrar on QC:
19:52:19 D Player: Player_Update1096Plus being used.
update->activity: 128
update->unknown2: 5.60519e-045
update->direction1: 93.6014
update->unknown3[0]: 0
update->unknown3[1]: 0
update->unknown3[2]: 0
update->unknown3[3]: 1
update->unknown3[4]: 1
update->unknown3[5]: 1
update->unknown3[6]: 0
update->unknown3[7]: 0.56
update->unk_speed: 0.5408
update->speed: 7.5
update->side_speed: -9.98685e-007
update->unknown4: 0
update->orig_x: 0
update->orig_y: 0
update->orig_z: 0
update->orig_x2: 0
update->orig_y2: 0
update->orig_z2: 0
update->unknown5[0]: 0
update->unknown5[1]: 0
update->unknown5[2]: 0
update->unknown6: 4294967295
update->unknown7[0]: 0
update->unknown7[1]: -1
update->unknown7[2]: 0
update->unknown8: 0
update->grid_location: 924281492
update->x: 45.5192
update->y: -3.39092
update->z: 167.548
update->direction2: 93.6013
update->unknown9: -0
update->unknown10: 0
update->speed_x: 7.48519
update->speed_y: 0
update->speed_z: -0.471103
The second client/struct is with the new value in place... as you see.
Thoughts?