Spawn Locations in spawnStruct

[kofiv]

For the past couple of days I've been trying to better understand how spawn locations are stored in spawnStruct. After logging the opcodes and mapping them to the struct, here is what I have for the location data:



/*0548*/
// bits: 00 00 77 01
signed deltaZ:13
signed y:19

/*0552*/
// bits: 10 00 00 00
signed z:19
signed animation:10
signed padding0552:3

/*0556*/
// bits: 00 00 00 00
signed deltaHeading:10
signed deltaY:13
signed padding0556:9

/*0560*/
// bits: 00 00 00 20
signed x:19
signed padding0560:1
unsigned heading:12

/*0564*/
// bits: 00 00 00 00
signed deltaX:13
signed padding0054:19


I got the data from OP_ZoneEntry. My loc at the time was 375.00, 0.00, 1.77.

If my byte-ordering is correct, the last 19 bits of 0548 does equal 375 and the first 19 bits of 0560 seem okay too. My problem is with the z-axis: how can "10 00" be equal to "1.77"? To me, it looks like that is 16.

I'm definetly missing something here; any help or clarification would be greatly appreciated.

[purple]

Z-axis while zoning is off slightly often. You don't notice it, but a lot of times when you zone, you fall a little as you align with the geometry. It's usually close, though.

[uRit1u2CBBA=]

On a related note, I've been trying to figure this out as well.

I can't seem to find where it is in the packet by looking at the dump.

If I have an in-game loc of 564.50 -51.88, 1.75, what would that look like in the data stream?

Thanks :)

[purple]

I guess you could take the time to do that, uRit, but it may not help. In game, you can get nudged places, or be levitating or various other things that make it so that the position that comes across from the server isn't where you are when you type /loc.

I never go that direction, personally.

When I do positioning, I do the client->zone part of it first. This is easy since there are no bitfields. Then I usually log in a second character and go to a quiet zone and get an OP_ClientUpdate zone->client for the second character. I then parse it over to find x/y/z with a cheesy-ass program. There's probably smarter ways to do this, but this is what I do.



#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <math.h>
#include <stdlib.h>

#pragma pack(1)
struct pos
{
uint16_t spawnId;


signed deltaY:13; // change in y
signed x:19; // x coord

signed z:19; // z coord
signed padding0058:1; // ***Placeholder
unsigned heading:12; // heading

signed padding0070:19; // ***Placeholder
signed deltaX:13; // change in x

signed y:19; // y coord
signed deltaHeading:10;// change in heading
signed padding0054:3; // ***Placeholder

signed deltaZ:13; // change in z
signed padding0066:9; // ***Placeholder
signed animation:10; // animation
};
#pragma pack(0)

#define FLOAT(x) float(x)/8.0
#define HEADING(x) 360 - ((((int8_t)lrintf(x)) * 360) >> 11)

int main(int argc, char** argv)
{
// 68.64, -141.63, 5.84
uint8_t input[] =
{
0x35, 0x2c, 0x00, 0xa0, 0x44, 0x00, 0x2e, 0x00,
0x10, 0x02, 0x42, 0x00, 0x80, 0x0c, 0x93, 0xfb,
0x9f, 0x34, 0x00, 0x00, 0x01, 0x00
};

struct pos* p = new struct pos();

memcpy(p, input, 20);

printf("X: %f Y: %f Z: %f Head: %f\n",
FLOAT(p->x), FLOAT(p->y), FLOAT(p->z), FLOAT(p->heading));
printf("dx: %f dy: %f dz: %f dh: %f\n",
FLOAT(p->deltaX), FLOAT(p->deltaY), FLOAT(p->deltaZ), FLOAT(p->deltaHeading));
}


When I get a new point, I hand type it in there and then play with the struct until I have x/y/z correct. Then I put it into everquest.h. The main reason I do this is because it takes forever to recompile seq after changing everquest.h. Well, not forever, but long enough that it sucks to have to keep recompiling.

Once I have x/y/z in the positioning, I try to place it properly in spawnStruct and make sure things move and are in the right spot in general, then I start working on deltas. To do deltas, there is some #if 0'd out code in player.cpp and spawnshell.cpp that I use.

[uRit1u2CBBA=]

I'm thoroughly confused now - when I have more time, I'll take a look at this.