DoV+ Grid ID problem

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

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:

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.

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

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

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

[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

[John Adams]

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.

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

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