[Help][SL 9.2.7] UseItem

[Trogg]

Hi, i trying to call sub_1D9E1D0(int slotID, wGUID *target, int *a3) from Lua_UseInventoryItem
Also, tryed to call sub_18CAD40(DWORD_PTR BagItemAddr, wGUID *target, int a3, int *a4) from Lua_UseItemByName
both functions do nothing after call, sub_18CAD40 returns DisplayError and ingame log:

The spell "[Spiritual Healing Potion]" [Dev] did not work. (You have not given enough items to cast this spell.) //potions exists in bag, on cd, error "not ready yet"

DWORD_PTR __fastcall Item__GetPtrFromID(void* a1, int itemID, int a3) {
	return ((DWORD_PTR(__fastcall*)(void*, int, int))(Hook::baseAddress + 0x19E7590))(a1, itemID, a3);
}

void __fastcall UseInventoryItem(int slotID, wGUID* target, int* a3) {
	((void(__fastcall*)(int, wGUID *, int*))(Hook::baseAddress + 0x1D9E1D0))(slotID, target, a3);
}

bool __fastcall sub_18CAD40(DWORD_PTR BagItemAddr, wGUID* target, int a3, int* a4) {
	return ((bool(__fastcall*)(DWORD_PTR, wGUID*, int, int*))(Hook::baseAddress + 0x18CAD40))(BagItemAddr, target, a3, a4);
}

int v19 = 0;
auto &myGUID = playerData.me->wguid;
UseInventoryItem(14, &myGUID, &v19); //nothing after call

wGUID targetGUID = 0;
void* item = reinterpret_cast<void*>(playerData.me->addr + 0x8798);
auto v6 = Item__GetPtrFromID(item, 171267, 0);
auto UseI = sub_18CAD40(v6, &targetGUID, 0, &v19); //or the same if (id == 171267) { auto UseI = sub_18CAD40(itemobj->addr, &targetGUID, 0, &v19);} //nothing after call
std::cout << "UseI " << UseI << std::endl; //returns 1

seems i have missing something, but what, I can’t understand

[scizzydo]

Hi, i trying to call sub_1D9E1D0(int slotID, wGUID *target, int *a3) from Lua_UseInventoryItem
Also, tryed to call sub_18CAD40(DWORD_PTR BagItemAddr, wGUID *target, int a3, int *a4) from Lua_UseItemByName
both functions do nothing after call, sub_18CAD40 returns DisplayError and ingame log:

The spell "[Spiritual Healing Potion]" [Dev] did not work. (You have not given enough items to cast this spell.) //potions exists in bag, on cd, error "not ready yet"

DWORD_PTR __fastcall Item__GetPtrFromID(void* a1, int itemID, int a3) {
	return ((DWORD_PTR(__fastcall*)(void*, int, int))(Hook::baseAddress + 0x19E7590))(a1, itemID, a3);
}

void __fastcall UseInventoryItem(int slotID, wGUID* target, int* a3) {
	((void(__fastcall*)(int, wGUID *, int*))(Hook::baseAddress + 0x1D9E1D0))(slotID, target, a3);
}

bool __fastcall sub_18CAD40(DWORD_PTR BagItemAddr, wGUID* target, int a3, int* a4) {
	return ((bool(__fastcall*)(DWORD_PTR, wGUID*, int, int*))(Hook::baseAddress + 0x18CAD40))(BagItemAddr, target, a3, a4);
}

int v19 = 0;
auto &myGUID = playerData.me->wguid;
UseInventoryItem(14, &myGUID, &v19); //nothing after call

wGUID targetGUID = 0;
void* item = reinterpret_cast<void*>(playerData.me->addr + 0x8798);
auto v6 = Item__GetPtrFromID(item, 171267, 0);
auto UseI = sub_18CAD40(v6, &targetGUID, 0, &v19); //or the same if (id == 171267) { auto UseI = sub_18CAD40(itemobj->addr, &targetGUID, 0, &v19);} //nothing after call
std::cout << "UseI " << UseI << std::endl; //returns 1

seems i have missing something, but what, I can’t understand

You're missing a bit more data passed into the "v19" in your UseInventoryItem call, or the "v19" in the 18CAD40 call. If you look at the code in a disassembler, 0x1D9E1DO (CGCharacterInfo::UseItem) calls 0x18CAD40 (CGItem_C::Use). When looking at the stack for your "v19", it appears to be a data structure (which I didn't have the time to get each field from, but see examples from the game itself)

  __int64 a3; // [rsp+40h] [rbp+7h] BYREF
  int v12; // [rsp+48h] [rbp+Fh]
  __int64 v13; // [rsp+4Ch] [rbp+13h]
  __int16 v14; // [rsp+54h] [rbp+1Bh]
  char v15; // [rsp+56h] [rbp+1Dh]
  char v16; // [rsp+57h] [rbp+1Eh]
  int v17; // [rsp+58h] [rbp+1Fh]
  __int16 v18; // [rsp+5Ch] [rbp+23h]
  __int128 v19; // [rsp+60h] [rbp+27h]
  __int128 v20; // [rsp+70h] [rbp+37h]
  __int128 v21; // [rsp+80h] [rbp+47h]

And initialized with:

  a3 = 0i64;
  v12 = sub_1417CF7E0();
  v14 = 0;
  v15 = 0;
  v17 = 0;
  v18 = 0;
  v19 = 0i64;
  v20 = 0i64;
  v21 = 0i64;
  v13 = 0i64;

Then, when called with CGCharacterInfo::UseItem:

   if ( !stricmp(v7, "cursor") )
  {
    LOBYTE(v17) = 1;
LABEL_15:
    CGCharacterInfo::UseItem(v2, (__int64)itemGUID, (__int64)&a3);
  }

You can see that the address of the structure is passed into the arg3, which in turn gets passed into CGItem_C::Use arg4. A few call chains down, you can see when it's used in another function, you can see where other parts of this structure are read at the various points. Essentially, you're hitting undefined behavior, because your stack only is placing the slot into the first data field, and the functions below are de-referencing data that is already on the stack (undefined data by you)

Hope this helps, without giving the answer. (Although, just defining that structure alone should be enough for you to call it)

[Trogg]

Thanks, this helped, I declared the structure and passed it to the call.
That's the thing, I followed this variable in sub_18CAD40

int *v79;
v79 = a4;
return Spell_C::Cast(v9, v79, a1, v77);

the only place where it is used and then the trace is lost, only in sub_178D540 i can see index calls
In standard castes, Spell_C::Cast works for me with v79 = (unsigned __int64)(Hook::baseAddress + 0x37DF820)

 a3 = 0i64;
  v12 = sub_1417CF7E0();
  v14 = 0;
  v15 = 0;
  v17 = 0;
  v18 = 0;
  v19 = 0i64;
  v20 = 0i64;
  v21 = 0i64;
  v13 = 0i64;

In IDA, is such a listing of arguments a hint that some structure is being initialized?

[scizzydo]

Thanks, this helped, I declared the structure and passed it to the call.
That's the thing, I followed this variable in sub_18CAD40

int *v79;
v79 = a4;
return Spell_C::Cast(v9, v79, a1, v77);

the only place where it is used and then the trace is lost, only in sub_178D540 i can see index calls
In standard castes, Spell_C::Cast works for me with v79 = (unsigned __int64)(Hook::baseAddress + 0x37DF820)

 a3 = 0i64;
  v12 = sub_1417CF7E0();
  v14 = 0;
  v15 = 0;
  v17 = 0;
  v18 = 0;
  v19 = 0i64;
  v20 = 0i64;
  v21 = 0i64;
  v13 = 0i64;

In IDA, is such a listing of arguments a hint that some structure is being initialized?

It definitely screams a structure initialization, and then looking at the stack space pretty much confirms it