sorry again, but two 2 dat no stop for take the name of my target drive me crazy...
well... looking in some thread i found someone that use g_client_connection (static pointer) + an offset for the object manager, and some other that use a directly static pointer to the object manager. well wich one i need to use?? an then is this analysis correct? can't understand very well the structure of object in object manager... why if the "next object" have the offset 3C, the coordinates of the same object is at 798 and more? it's an overlap of object or is more table object with different object???
if someone could explain to me i would be very glad.
tks in advance.
Ruzzichella.
Mostly the meaning of the fields. While your structure layout may be correct, the fields aren't. See here.What am I wrong about? I don't see anything in your analysis of the function that proves me wrong.
The field names were incorrect, and I think I admitted that.
The field names were wrong, you're right. I went after this. You still had fixed char arrays, which were wrong (I think).
[16:15:41] Cypher: caus the CPU is a dick
[16:16:07] kynox: CPU is mad
[16:16:15] Cypher: CPU is all like
[16:16:16] Cypher: whatever, i do what i want
That could be; depends how it's loaded into memory. Don't have IDA from my current location, so can't really check.The field names were wrong, you're right. I went after this. You still had fixed char arrays, which were wrong (I think).
Also, it seems SourcePeek's listing is out of date (?). Either way, I've heard something about the in-memory cache structs not being the same as the actual structures in the cache files... I'll take a stab at that later, when I reach home today.
EDIT: This might be of use.
Last edited by XTZGZoReX; 03-13-2010 at 11:50 AM.
For the most part; the structs are fairly similar. It seems that Blizz has a habit of putting strings at the end of the struct.
DBCs seem to match their file counterparts almost exactly. (The exception being that there is only 1 string, instead of the 7 localized)