[Help Request] TLS / Object Structure

[Zephir]

Hey guys.

Read through pretty much everything on this forum that has to do with TLS. I ran IDE and found:

.text:0046C16C                 mov     ecx, large fs:2Ch
.text:0046C173                 mov     eax, TlsIndex
.text:0046C178                 mov     eax, [ecx+eax*4]
.text:0046C17B                 mov     ecx, [eax+8]

with TslIndex being:

.data:012F0CC8 TlsIndex        dd ?                    ; DATA XREF: sub_46C160+13r

so now i use Whalemarte's AutoIt Code. Edited the TlsIndex... wont work. I'm assume that the Object Structure changed? How do you guys dump the structure? any hint is appreciated.

Thanks,
Zephir

[SKU]

Uhm dude.. you might wanna post what exactly is not working (code).
Also, that other thread's like a year old.

[Cypher]

Well im not exactly sure what you want from the TLS, but if you just are wanting to scan it for objects and object Info, just search for Object manager, theres plenty of C++/C# source code for it, that can be easily converted to Au3, (took me about 5 mins) and it works great in Au3 also.

if you post a code snippet of what your trying to do or more info, we could help you more mate. good luck

The object manager is thread-local and hence WoW accesses it primarily through TLS.

[Zephir]

okay, i worked on my problem and managed to bring it down to one point:

1. TLS_Index = [0x013569BC] (for 3.1.0)
2. TLS_Offset = [TIB + 0x2C]
3. WoW Base = TLS_Offset + [TLS_Index * 4]

now i read [WoW Base + 8] for PlayerGUID! But how do i find the player base from here? I still dont understand wow's sturcture in memory .


thank you

Edit:
this question only applies, if step 1 through 3 is correct

[Cypher]

Loop through the linked list, for each object do a GUID compare. If the GUID matches then you have your local player pointer.

Pointer to the object manager is at 'WoWBase + 0x10'. Pointer to linked list is at (from memory) 0xAC.

Just look at how GetObjectByGUID is implemented. You can pretty much rip the code from there.

[Xzibit]

good explanation thanks cypher

[Zephir]

Loop through the linked list, for each object do a GUID compare. If the GUID matches then you have your local player pointer.

Pointer to the object manager is at 'WoWBase + 0x10'. Pointer to linked list is at (from memory) 0xAC.

Just look at how GetObjectByGUID is implemented. You can pretty much rip the code from there.

thank you cypher. everything works fine now. the problem was that i had object manager and playerGUID confused (0x8 and 0x10) so thats why garbage came out. now i got it.

now one more question. do the object structs ever change? e.g.

WoWObject{
dword var1;
dword var2;
dword DataPtr;
dword var4;
dword var5;
dword ObjectType;
dword var7;
dword var8;
dword var9;
dword var10;
dword var11;
dword var12;
uint64 GUID;
dword var13;
ptr NextObject;
}

Edit:
and +rep of course

Edit2:
Nevermind, found out they do.

[g3gg0]

Loop through the linked list, for each object do a GUID compare. If the GUID matches then you have your local player pointer.

why that slow method?

simply use that address - it contains the local player pointer

int playerObject = 0x01357CE4; // 3.0.9: 0x012EB404; // 3.0.8: 0x12EA404;//3.0.3: 0x012EA2F4; // 3.0.0: 0x012E813C; // 2.4.3: 0x00E29D28; // 2.4.2: 0x00E8AA38; // 2.4.1:  0x00E849E0;

[Cypher]

why that slow method?

simply use that address - it contains the local player pointer

int playerObject = 0x01357CE4; // 3.0.9: 0x012EB404; // 3.0.8: 0x12EA404;//3.0.3: 0x012EA2F4; // 3.0.0: 0x012E813C; // 2.4.3: 0x00E29D28; // 2.4.2: 0x00E8AA38; // 2.4.1:  0x00E849E0;

Gee, maybe because you then have access to ALL objects, not just the local one.

Durrrrrrrrrrrrrrrrrrrrrrr.

Also, it's far from slow. WoW does exactly what I described in all its LUA routines that need to get an object by its GUID. I'm sure they'd cache the pointer if it was a huge performance hit (Benchmark it, its a very fast and easy thing to do. Just basic pointer arithmetic and integer compares). Every frame I make a copy of WoWs object list using that method, then all my code uses that internal list (including a separately cached player pointer), the performance hit from doing something like that on every frame is practically zero.

[schlumpf]

But I'm running on a SLOOOOOOOOW machine!

I don't really get why you copy it all .. That's the only thing which seems a bit weird for me.

(Btw: update your blog with something)

[Cypher]

But I'm running on a SLOOOOOOOOW machine!

I don't really get why you copy it all .. That's the only thing which seems a bit weird for me.

(Btw: update your blog with something)

I will soon. So lazy though.

You copy it all because it's faster.

Lets say I need to do 9 passes of the list on a certain frame. If I keep internal lists (small correction, I actually keep more than one), I will get better performance than if I just called into WoW multiple times.

eg. Unit list, gameobject list, etc

Also, internal lists are easier to use. I can throw all the data into a STL container and the objects suddenly become 100x easier to search and manage.

[Zephir]

why that slow method?

just stopped the time needed for the fun of it: 18.157328 milliseconds. And i am using AutoIt! which means if ur using C# it would be even faster

[Cypher]

just stopped the time needed for the fun of it: 18.157328 milliseconds. And i am using AutoIt! which means if ur using C# it would be even faster

And faster again in C++.

[g3gg0]

yeah if you want now your supercool HP bars updated with 60 FPS, you get into trouble when you dont cache

edit:

Also, it's far from slow. WoW does exactly what I described in all its LUA routines that need to get an object by its GUID.

yes, its far from slow. is even damn ****ing slow

no, serious...
dereferencing one pointer vs. dereferencing up to some hundreds.
(imagine you are in dalaran)
that sums up. and if you are caching the object, you have to refresh
it on zone change/relog etc. if you dont - you will face problems and so on...

for the sake of object oriented, cool, feature-rich program languages many
people switch to C# or similar and forget even to use fast algorithms
or "simple" solutions to get smth working.

e.g. they scan all buffs to get "isMounted" status instead of reversing
the functions and seeing that this would need just one pointer dereference.

computers get faster every year...
but programmers fail to optimize their code and the programs get slower more and more and need more memory.
so we need even faster computers etc..

[Robske]

Wirth's law!