Archaeology world object orientation?

[gerardolm]

Hi.

I've been playing with WoW memory reading for a bit, and so far I've been able to get XYZ coords and color (red, yellow, green) for archeology objects.

My problem is that the object's rotation/orientation always comes up as 0. This makes no sense as it should work as every other object in the game unless it's a rotation measured relatively to its parent, etc...

Any thoughts? (I think my offsets are not wrong because I can get the right rotation for everything else that I tried)

Thanks for reading.

[andy012345]

Are you handling rotation correctly? IIRC it was turned into a packed vector of the pitch roll and yaw.

[gerardolm]

Actually, that makes sense... I hadn't checked before, but I'm getting rotation 0 for all world objects (I'm getting the right one for all entities and units, but of course they're stored differently).

I'll look into it

Edit: Ugh, I can't find the offset for pitch, yaw and roll in game objects.

[andy012345]

It's a descriptor, GAMEOBJECT_ROTATION iirc.

Edit: No it's not it's in the movement block of SMSG_UPDATE_OBJECT.

    if (flags & 0x200)
    {
        double tmp;
        if (GetOrientation() < M_PI)
            tmp = sinf(double(GetOrientation()) / 2.0f);
        else
            tmp = -sinf(double(GetOrientation()) / 2.0f);

        tmp *= 0x100000;

        uint64 rot = tmp;

        //someone tell me if they find something with a rotation on other axis

        *data << rot;
    }

[Silinoron]

Er...

enum EGameObjectFields
{
	OBJECT_FIELD_CREATED_BY = OBJECT_END + 0x0,
	GAMEOBJECT_DISPLAYID = OBJECT_END + 0x2,
	GAMEOBJECT_FLAGS = OBJECT_END + 0x3,
	GAMEOBJECT_PARENTROTATION = OBJECT_END + 0x4,
	GAMEOBJECT_DYNAMIC = OBJECT_END + 0x8,
	GAMEOBJECT_FACTION = OBJECT_END + 0x9,
	GAMEOBJECT_LEVEL = OBJECT_END + 0xA,
	GAMEOBJECT_BYTES_1 = OBJECT_END + 0xB,
	GAMEOBJECT_END = OBJECT_END + 0xC
};

...yeah.

EDIT: Isn't gameobject rotation a quaternion?

[gerardolm]

Er...

enum EGameObjectFields
{
	OBJECT_FIELD_CREATED_BY = OBJECT_END + 0x0,
	GAMEOBJECT_DISPLAYID = OBJECT_END + 0x2,
	GAMEOBJECT_FLAGS = OBJECT_END + 0x3,
	GAMEOBJECT_PARENTROTATION = OBJECT_END + 0x4,
	GAMEOBJECT_DYNAMIC = OBJECT_END + 0x8,
	GAMEOBJECT_FACTION = OBJECT_END + 0x9,
	GAMEOBJECT_LEVEL = OBJECT_END + 0xA,
	GAMEOBJECT_BYTES_1 = OBJECT_END + 0xB,
	GAMEOBJECT_END = OBJECT_END + 0xC
};

...yeah.

EDIT: Isn't gameobject rotation a quaternion?

That's parent rotation. It's giving me weird/wrong values all the time... I can't seem to find any memory offsets that point to object rotation/orientation (other than units).

[Silinoron]

Andy is right. That uint64 is a packed quaternion:

        public Quaternion ReadPackedQuaternion()
        {
            var packed = ReadInt64();
            var x = (packed >> 42) * (1.0f / 2097152.0f);
            var y = (((packed << 22) >> 32) >> 11) * (1.0f / 1048576.0f);
            var z = (packed << 43 >> 43) * (1.0f / 1048576.0f);

            var w = x * x + y * y + z * z;
            if (Math.Abs(w - 1.0f) >= (1 / 1048576.0f))
                w = (float)Math.Sqrt(1.0f - w);
            else
                w = 0.0f;

            return new Quaternion(x, y, z, w);
        }

[gerardolm]

Well, the thing is I'm getting the same values over and over (uint64 = 0) even though it's clear in-game that the orientation has changed ><.

Also, judging by the +0x4 and +0x8, either GAMEOBJECT_PARENTROTATION is 4 bytes (32 bits) or 16 bytes (I guess enums are uint based and not byte based).

[andy012345]

You won't find any useful info in the parent rotation.

Maybe Zor can shed some light on this, I havn't taken a look at wow in months. And I don't know what kind of offsets it would use because I only really cared about the structure of the packets, not where they stored that data.

[_Mike]

float __thiscall GetFacing(void* objectPtr) = vmt[14]
Should be enough since you don't need to know pitch and roll for archaeology.

[gerardolm]

float __thiscall GetFacing(void* objectPtr) = vmt[14]
Should be enough since you don't need to know pitch and roll for archaeology.

CGObject_C::GetFacing always returns 0.0 (FLDZ, RET)
CGObject_C::GetFacing_Override looks like a dynamic call:

CGObject_C__GetFacing_Override proc near
mov     ecx, dword_D7F7F4
mov     eax, [ecx]
mov     edx, [eax+34h]
jmp     edx
CGObject_C__GetFacing_Override endp

[caytchen]

CGObject_C::GetFacing always returns 0.0 (FLDZ, RET)

What the hell captain obvious? There is a reason its a virtual function.

[gerardolm]

What the hell captain obvious? There is a reason its a virtual function.

Well, it could be a virtual function and still offer some generic behaviour for all objects (instead of just returning 0).

Also, I have to ask that, if you have nothing to contribute, you should not post in this thread. Thanks.

[_Mike]

Well, it could be a virtual function and still offer some generic behaviour for all objects (instead of just returning 0).

Also, I have to ask that, if you have nothing to contribute, you should not post in this thread. Thanks.

The behaviour IS generic for all object types, it returns the facing. The implementation however is not.

[Cypher]

For gerardolm's benefit:
http://en.wikipedia.org/wiki/Virtual_function#C.2B.2B