Player position - best method? (what is base+0xF4?)

[Tanaris4]

So come patch to patch, I've always found the x,y,z from the baseaddress. As of 4.1.0, it's:

    BaseField_XLocation                 = 0x780,
    BaseField_YLocation                 = 0x784,
    BaseField_ZLocation                 = 0x788,

Then I was looking at this function:

void *__stdcall CGUnit_C::GetPosition(void *a1, int a2)
{
  CPassenger::GetPosition(a1, *(_DWORD *)(a2 + 0xF4), *(_DWORD *)(a2 + 0xF4) + 0x10);
  return a1;
}

And realized the position is also at [[baseAddress+0xF4] + 0x10]. So my question, what is +0xF4? I thought maybe GAMEOBJECT_FIELDS, but 0x10 is GAMEOBJECT_PARENTROTATION (shouldn't it be POSITION)?

I know unit fields is +0xEC, item fields is +0xF0, and player fields is +0x11F8, I'm just confused as to what +0xF4 may be (or what I should name it).

Thanks!!

[Robske]

It's probably the CMovement struct of the unit.

Both methods you've described point to the same set of floats

if you calculate the offset from [base + 0xF4] + 0x10 to the base address you'd end up with 0x780

[Tanaris4]

Sure, makes sense. Do you have the CMovement struct?

I know it's :

	//BaseField_TransportGUID				= 0x778,  // 4.1.0
    BaseField_XLocation                 = 0x780,
    BaseField_YLocation                 = 0x784,
    BaseField_ZLocation                 = 0x788,
    BaseField_Facing_Horizontal         = 0x78C,
    BaseField_Facing_Vertical           = 0x790,
    
    //BaseField_MovementFlags             = 0x7B0,
    
    BaseField_RunSpeed_Current          = 0x7F8,
    BaseField_RunSpeed_Walk             = 0x7FC,	// (you sure this is runspeed walk? - i noticed it was 2.5, yet current speed when walking was 7.0) 3.0.9: 0x83C
    BaseField_RunSpeed_Max              = 0x800,
    BaseField_RunSpeed_Back             = 0x804,
    BaseField_AirSpeed_Max              = 0x810,

But don't know the others

[TOM_RUS]

I guess you were reading position directly from "CMovement MovementInfo" in unit struct before.

I only had CMovement struct for some 3.x build 11159, may be you can update it to latest build:

C3Vector *__thiscall CGUnit_C__GetPosition(CGUnit_C *this, C3Vector *a2)
{
  CMovement__GetPosition(this->MovementPtr, a2, &this->MovementPtr->Position);
  return a2;
}

struct CMovement
{
  TSLink_CMovement MovementLink;
  WGUID TransportGuid;
  C3Vector Position;
  int field_1C;
  float Facing;
  float Pitch;
  WGUID *Guid;
  int UnkFlags_field_2C;
  int field_30;
  int field_34;
  C3Vector GroundNormal;
  int MovementFlags;
  __int16 MovementFlags2;
  char SeatPosition;
  char gap_4b[1];
  C3Vector AnchorPosition;
  float AnchorFacing;
  float AnchorPitch;
  int MoveStartTime;
  C3Vector Direction3d;
  C2Vector Direction2d;
  float AnchorCosPitch;
  float AnchorSinPitch;
  int TimeFallen;
  float FallStartElevation;
  float SplineFloat_Elevation_field_88;
  float CurrentSpeed;
  float WalkSpeed;
  float RunSpeed;
  float RunBackSpeed;
  float SwimSpeed;
  float SwimBackSpeed;
  float FlightSpeed;
  float FlightBackSpeed;
  float TurnRate;
  float PitchRate;
  float UnkElevation_field_B4;
  float JumpVelocity;
  void *Spline; // pointer to CMoveSpline struct
  int UpdateTimeMs_field_C0;
  int LastEventTime;
  int field_C8;
  int field_CC;
  float f_field_D0;
  C3Vector PositionDiffFromLastMoveEvent;
  int FacingDiffFromLastMoveEvent;
  int PitchDiffBetweenLastMoveEvent;
  __int16 field_E8[32];
  int field_128;
  int MSTime_field_12C;
  int TimeSinceLastMoveEvent;
  int MSTime_field_134;
  int field_138;
  int field_13C;
  void *PlayerMoveEventList_Head_field_140;
  CGUnit_C *Unit;
};

struct CGUnit_C
{
  CGObject_C ObjectBase;
  CGUnitData *UnitData; // pointer to descriptiors
  int field_D4;
  CMovement *MovementPtr;
  int field_DC[427];
  CMovement MovementInfo;
  // lots of other fields...
};

struct CGObject_C
{
  CGObject_C__vTable *vTable;
  int field_4;
  CGObjectData *ObjectData; // pointer to descriptors
  int field_C;
  int field_10;
  int TypeId;
  int field_18;
  int field_1C;
  int field_20;
  int field_24;
  int field_28;
  int field_2C;
  int field_30;
  int field_34;
  int field_38;
  int field_3C;
  int field_40;
  int field_44;
  int field_48;
  int field_4C;
  int field_50;
  int field_54;
  int field_58;
  int field_5C;
  int field_60;
  int field_64;
  int field_68;
  int field_6C;
  int field_70;
  int field_74;
  int field_78;
  int field_7C;
  int field_80;
  int field_84;
  int field_88;
  int field_8C;
  int questStatus;
  int field_94;
  int field_98;
  int field_9C;
  int field_A0;
  int field_A4;
  int field_A8;
  int field_AC;
  int field_B0;
  int field_B4;
  int field_B8;
  int field_BC;
  int field_C0;
  int field_C4;
  int field_C8;
  void *field_CC;
};

[namreeb]

It looks like CPassenger::GetPosition takes +0xF4 as a parameter. Can't you look to your debug Mac binary and see what the parameter type is for that function? (Assuming you want to verify the answer given by Robske)

[Tanaris4]

It looks like CPassenger::GetPosition takes +0xF4 as a parameter. Can't you look to your debug Mac binary and see what the parameter type is for that function? (Assuming you want to verify the answer given by Robske)

There is some debug info, not structs I believe (or if there are I don't know how to determine that). When I view as pseudocode it shows the params as ints + ptrs

@TOM_RUS tyvm! I'll start updating + post back

[_Mike]

Looking at CGUnit_C::GetPosition in the debug binary we get

__text:004E4207 8B 5D 08                          mov     ebx, [ebp+arg_0]
__text:004E420A 8B 45 0C                          mov     eax, [ebp+arg_4]
__text:004E420D 8B 90 F4 00 00 00                 mov     edx, [eax+0F4h]
__text:004E4213 8D 42 10                          lea     eax, [edx+10h]
__text:004E4216 89 44 24 08                       mov     [esp+8], eax
__text:004E421A 89 54 24 04                       mov     [esp+4], edx
__text:004E421E 89 1C 24                          mov     [esp], ebx
__text:004E4221 E8 CA 02 EC FF                    call    __ZNK10CPassenger11GetPositionERK8C3Vector ; CPassenger::GetPosition(C3Vector  const&)

Which unless I'm horribly mistaken would make [+0xF4] a CPassenger* and [[+0xF4]+0x10] a C3Vector

When I view as pseudocode it shows the params as ints + ptrs

If you don't specify parameter types manually then hex-rays just puts in a pod type that fits. (It's probably a bit more complicated than that, but that's how it seems to me at least )
It does not seem to use the types specified in the debugging info.

[caytchen]

There is some debug info, not structs I believe (or if there are I don't know how to determine that). When I view as pseudocode it shows the params as ints + ptrs

@TOM_RUS tyvm! I'll start updating + post back

Stop relying so much on pseudocode, seriously. Its cool to get a quick grasp, but its not necessarily correct. To achieve better results, its absolutely crucial to tell IDA about structures and sometimes calling convention/parameters when it gets it wrong.

When C++ introduced function overloads, it was no longer possible to export functions simply using their name, they added parameter types and other information in what is known as name mangling
Thus, the exported functions should indeed have at least the parameter types and IDA does give you the unmangled names in the functions window. The only reason they don't make it into pseudocode is because it knows nothing about their definition.

[Tanaris4]

Stop relying so much on pseudocode, seriously. Its cool to get a quick grasp, but its not necessarily correct. To achieve better results, its absolutely crucial to tell IDA about structures and sometimes calling convention/parameters when it gets it wrong.

When C++ introduced function overloads, it was no longer possible to export functions simply using their name, they added parameter types and other information in what is known as name mangling
Thus, the exported functions should indeed have at least the parameter types and IDA does give you the unmangled names in the functions window. The only reason they don't make it into pseudocode is because it knows nothing about their definition.

Thanks for the insight, where specifically am I looking to understand more info about the parameter types? I don't see this in the function list:

[_Mike]

Thanks for the insight, where specifically am I looking to understand more info about the parameter types? I don't see this in the function list:

__text:004E4200                   ; CGUnit_C::GetPosition(void)const
__text:004E4200                                   public __ZNK8CGUnit_C11GetPositionEv

Unmangled vs mangled name.. from the 13850 mac binary.
You can also use c++filt (from binutils) to unmangle names manually from binaries compiled with gcc, and undname.exe for msvc

[caytchen]

Thanks for the insight, where specifically am I looking to understand more info about the parameter types? I don't see this in the function list:

Its a class function, so what IDA marks down as the first parameter is actually the this pointer, which would be CGUnit_C*. So the first thing you should do is correct the type of the first argument and add a CGUnit_C structure to properly work with it.

[Tanaris4]

add a CGUnit_C structure to properly work with it.

This is what I don't know how to do. When I try to rename it it fails (which makes sense as IDA doesn't know what the class/struct is)

[MaiN]

This is what I don't know how to do. When I try to rename it it fails (which makes sense as IDA doesn't know what the class/struct is)

Local types (Shift-F1).

[_Mike]

Slightly off-topic, but one thing that has been confusing me is that in build 13850* the class pointer is the second argument. Is this specific to some combination of mac/gcc/debug settings or are all mac binaries this way? And what is the first parameter?

For example:

__text:004E4200                   ; CGUnit_C::GetPosition(void)const
__text:004E4200                                   public __ZNK8CGUnit_C11GetPositionEv
__text:004E4200                   __ZNK8CGUnit_C11GetPositionEv proc near
__text:004E4200
__text:004E4200                   var_4           = dword ptr -4
__text:004E4200                   arg_0           = dword ptr  8
__text:004E4200                   arg_4           = dword ptr  0Ch
__text:004E4200
__text:004E4200 55                                push    ebp
__text:004E4201 89 E5                             mov     ebp, esp
__text:004E4203 53                                push    ebx
__text:004E4204 83 EC 14                          sub     esp, 14h
__text:004E4207 8B 5D 08                          mov     ebx, [ebp+arg_0]
__text:004E420A 8B 45 0C                          mov     eax, [ebp+arg_4]
__text:004E420D 8B 90 F4 00 00 00                 mov     edx, [eax+0F4h]
__text:004E4213 8D 42 10                          lea     eax, [edx+10h]
__text:004E4216 89 44 24 08                       mov     [esp+8], eax
__text:004E421A 89 54 24 04                       mov     [esp+4], edx
__text:004E421E 89 1C 24                          mov     [esp], ebx
__text:004E4221 E8 CA 02 EC FF                    call    __ZNK10CPassenger11GetPositionERK8C3Vector ; CPassenger::GetPosition(C3Vector  const&)
__text:004E4226 83 EC 04                          sub     esp, 4
__text:004E4229 89 D8                             mov     eax, ebx
__text:004E422B 8B 5D FC                          mov     ebx, [ebp+var_4]
__text:004E422E C9                                leave
__text:004E422F C2 04 00                          retn    4
__text:004E422F                   __ZNK8CGUnit_C11GetPositionEv endp

Here arg_4 is the CGUnit_C pointer, not arg_0

*) I haven't checked any other mac builds so I don't know if they are the same way

[TOM_RUS]

Things on mac seem to be different. Those functions isn't thiscall, while on windows they are...