[Legion] Targeting pointers in 7.0.3

[reliasn]

I think it's worth mentioning the following changes:

Build 21742

int __cdecl Script_CastSpell(int a1)
{
  char v2; // [sp+8h] [bp-28h]@3
  int v3; // [sp+Ch] [bp-24h]@3
  int v4; // [sp+10h] [bp-20h]@3
  int v5; // [sp+14h] [bp-1Ch]@3
  int v6; // [sp+18h] [bp-18h]@2
  int v7; // [sp+1Ch] [bp-14h]@2
  int v8; // [sp+20h] [bp-10h]@2
  int v9; // [sp+24h] [bp-Ch]@2
  int v10; // [sp+28h] [bp-8h]@1
  int v11; // [sp+2Ch] [bp-4h]@1

  v11 = 0;
  if ( GetSlotFromLua(&v10, 0, 0) )
  {
    v6 = CGGameUI__m_lockedTarget;
    v7 = *((_DWORD *)&CGGameUI__m_lockedTarget + 1);
    v8 = *((_DWORD *)&CGGameUI__m_lockedTarget + 2);
    v9 = *((_DWORD *)&CGGameUI__m_lockedTarget + 3);
    if ( lua_toboolean(a1) )
    {
      ClntObjMgrGetActivePlayer((int)&v2);
      v6 = *(_DWORD *)&v2;
      v7 = v3;
      v8 = v4;
      v9 = v5;
    }
    CGSpellBook__CastSpell(v11, v10, &v6, 0);
  }
  return 0;
}

Build 22293

int __cdecl Script_CastSpell(int a1)
{
  int v1; // eax@2
  char v3; // [sp+4h] [bp-28h]@3
  int v4; // [sp+8h] [bp-24h]@3
  int v5; // [sp+Ch] [bp-20h]@3
  int v6; // [sp+10h] [bp-1Ch]@3
  int v7; // [sp+14h] [bp-18h]@2
  int v8; // [sp+18h] [bp-14h]@2
  int v9; // [sp+1Ch] [bp-10h]@2
  int v10; // [sp+20h] [bp-Ch]@2
  int v11; // [sp+24h] [bp-8h]@1
  int v12; // [sp+28h] [bp-4h]@1

  v12 = 0;
  if ( GetSlotFromLua(a1, &v12, &v11, 0, 0) )
  {
    v1 = (*(int (**)(void))(*(_DWORD *)off_C3A014 + 0xC))();
    v7 = *(_DWORD *)v1;
    v8 = *(_DWORD *)(v1 + 4);
    v9 = *(_DWORD *)(v1 + 8);
    v10 = *(_DWORD *)(v1 + 0xC);
    if ( sub_12DD3D(a1, 3) )
    {
      ClntObjMgrGetActivePlayer((int)&v3);
      v7 = *(_DWORD *)&v3;
      v8 = v4;
      v9 = v5;
      v10 = v6;
    }
    CGSpellBook__CastSpell(v12, v11, &v7, 0);
  }
  return 0;
}

Basically, CGGameUI__m_lockedTarget and other targeting pointers (Last Target, Focus Target, etc) seem to have been replaced by this new VMT that returns pointers to WoW GUIDs. Funny enough, the Mouse Over pointer (CGGameUI__m_currentObjectTrack) was the only one unchanged and you can still find it in Script_InteractUnit.

So, to get the current player target, you now need to read:

[ baseAddress + 0xC3A014 ] + 0x28

The 0x28 offset comes from the function that is called by the VMT ( [[[baseAddress + 0xC3A014]] + 0xC] ):

.text:0010C12D                               sub_10C12D      proc near               ; CODE XREF: sub_4E41E+Bp
.text:0010C12D                                                                       ; sub_E8957+1Bp ...
.text:0010C12D 8D 41 28                                      lea     eax, [ecx+28h]
.text:0010C130 C3                                            retn
.text:0010C130                               sub_10C12D      endp

And if you are reading the player's target from the 0xA0 descriptor, it's fine, but keep in mind that, upon changing targets, it takes like 1 second for WoW to update the descriptor. So it might not be a good idea to use it, depending on what you're doing.

[iceblockman]

is the descriptor 0x8 now ? (32bit) And I didn't get the 1 seconds delay. My target updated immediately when I changing target.

[reliasn]

is the descriptor 0x8 now ? (32bit) And I didn't get the 1 seconds delay. My target updated immediately when I changing target.

Yes for the descriptor. And well, this is the behavior I'm getting on the Target descriptor: https://vid.me/UWU7

It might not be 1 second, but there's definitely some delay that, once again, might cause problems depending on what you're doing.
For example, if you are listening the PLAYER_TARGET_CHANGED event and you read the descriptor value when it happens, it will give you a wrong value because the descriptor hasn't updated yet.

[Jadd]

Yes for the descriptor. And well, this is the behavior I'm getting on the Target descriptor: https://vid.me/UWU7

It might not be 1 second, but there's definitely some delay that, once again, might cause problems depending on what you're doing.
For example, if you are listening the PLAYER_TARGET_CHANGED event and you read the descriptor value when it happens, it will give you a wrong value because the descriptor hasn't updated yet.

The delay depends on your ping. Descriptors (even for yourself) are updated by the server, not the client.