Position Packet struct

[jimbo]

I spent an ass-load of time figuring this out. So throw me a red cent if you find it helpful. Or if you know the two pieces of it that I don't know (Unknown2 and Unknown8), give me those instead. I think it is complete enough for most purposes now though.

typedef struct _PositionPacket {
     unsigned short SpawnID;		//1
     unsigned short TimeStamp;		//1
     signed int ZHeading:11;		//2	scale -512(-0x200) to +512(0x200) down to up
     DWORD Unknown2:21;			//2     0 until you zone first time, 0x00633+1bit thereafter for low-lvl toon?
     float DeltaZ;			//3
     float X;				//4
     signed int DeltaHeading:10;	//5
     signed int Animation:10;		//5	speed-related -- spoof this low to avoid boot - walk=18, run0=27, walk/run backward=-18
     signed int Padding5:12;		//5	0
     float Y;				//6
     float DeltaX;			//7
     unsigned int Heading:12;		//8	scale 0 to 2047 (0x7FF) CCW starting at N
     DWORD Unknown8:20;			//8	0 until you zone first time, 
     float DeltaY;			//9
     float Z;				//10
} PositionPacket, *pPositionPacket;

--jimbo

 

[odessa]

How is that different from the old packet?
Unknown2 (1 in mine) is different depending on toons and zones and so on. No clue what it really is.
Animation is really animation related.
Heading is 0 to 512, the other two bits are for the remainder.
Where I say can be non-zero I mean it, and I have no idea about the method in that madness.

struct MOVEPKT {
	unsigned short SpawnID;
	unsigned short TimeStamp;
	int ZHeading:12;
	unsigned int Unknown1:20; // can be nonzero
	float DeltaZ;
	float X;
	int DeltaHeading:10;
	unsigned int Animation:10;
	unsigned int Unknown2:12; // can be nonzero
	float Y;
	float DeltaX;
	unsigned int HeadingRemainder:2;
	unsigned int Heading:10;
	unsigned int Unknown3:8; // can be nonzero
	unsigned int Unknown4:12; // can be nonzero
	float DeltaY;
	float Z;
} PKT;

p.s. still, cent for you, keep it up man.

 

[TeachersPet]

That's pretty good work on the movement struct. Definitely looks a hell of a lot better than mine did when I was tearing it apart after the last patch when it broke.

Mine looked something like this:

struct MovePacket {
	spawnid;
	timestamp;
	fuckyou;
	dontcare;
	dZ;
	X;
	dontcare2;
	abortion;
	Y;
	dX;
	heading;
	dY;
	Z;
} P;

 

[jimbo]

How is that different from the old packet?

Odessa,
Literal Answer:

old packet		-->	new packet

unsigned short SpawnID;		unchanged
unsigned short TimeStamp;	unchanged
int ZHeading:12;		11 bits instead of 12 for range of -512 to 512
unsigned int HeadingRemainder:2;\
unsigned int Heading:10;	 > unknown 21 bits instead of 20	
unsigned int paddingHeading:8;	/
float DeltaY;			DeltaZ
unsigned int Animation:10;	\
unsigned int paddingAnimation:22;> float X
float DeltaX;			DeltaHeading(10), Animation(10)(signed), Padding(12)
float Y;
int DeltaHeading:10;		\
int paddingDeltaHeading:22;	 > DeltaX
float DeltaZ;			Heading(12), unknown(20)
float Z;			DeltaY
float X;			Z

Now, if you tell me that the packet you have quoted in your post was published somewhere here, I'm gonna cry, cause that certainly ain't what I am referring to as 'the old packet'. And if I had been privey to that, it would have saved me about 8 or 10 hours.

I do not understand the 'remainder' business. Would you elaborate on the source of that? Your 512 scale for the heading is certainly better than what I came up with by including the 'remainder' in the value. And I can certainly chop off two bits to fix mine, but I sure would like to understand it better.


Here is my theory on the 'Animation'. As you see, mine is a signed int, as opposed to Odessa's unsigned int. I think the Animation, (even if it is only discrete values) is derived only from a toon's ground-speed, with higher values representing faster speeds. I think this is a 'tell' for speed cheaters. The Absolute value of my signed int will tell you the animation, and the sign will tell you the direction of travel. Interpretting the Animation as an unsigned int will give you erroneous large values for backward movement due to the way negative integers are stored in memory, thus obscurring the fact that they are speed-related. Now if this is correct, I just IMPROVED UPON ODESSA's work. Nevermind that it is a tiny, insignificant improvement to Odessa's struct. It is an improvement. And that makes me at least ten feet tall, cause Odessa is King of the Packets.


TP's element names are certainly more imaginative, and I do like them, but I wanted to keep mine consistent with Odessa's since that seems to be the defacto standard. Congrats to TP for using the KISS theory. It has everything you need (except in a few cases maybe, the Animation part), and he probably figured it out in a tenth the time it took me.


So now that the packet is out, can we start having the packet-related plugins back in the main distribution, with source?

--jimbo