[Retail] Shadowlands 9.0.1.36230 Offsets

[ChrisIsMe]

In retail (probably TBCC too, I haven't looked because it's relatively useless (to me)...) there's also a count of active objects @ s_curMgr] + 0x10

But you can't reliably loop the objects with that amount, since they change too frequently.

[ChrisIsMe]

I know combat reach/bounding radius, I think the surrounding bit of the struct is

Key:
< == going backwards in struct from offset
> == going forward in struct from offset
@ == size of variable

charm @ 0x10 bytes <
summon @ 0x10 bytes <
critter @ 0x10 bytes <
charmedBy @ 0x10 bytes <
summonedBy @ 0x10 bytes <
createdBy @ 0x10 bytes <
demonCreator @ 0x10 bytes <
lookAtControllerTarget @ 0x10 bytes <

0x1c38 TargetGUID start

target GUID @ 0x10 byes >
battlepetcompanionguid @10 bytes >
battlepetdbid @8 bytes

flags 1<
flags2 <

0x1cc4 Flags 3 start

flags 3 >
aurastate >
rangedattackbasetime >
bounding radius >
combat reach >
attack round base time @0x8 byte size >
display ID >
display scale >
native display ID (aka mount?) >
native display scale

CGUnit_C descriptors at least.

I'm not really interested in getting all of the information in the struct, I thought about trying but it seems like in retail there's a lot of different stuff going on, like power is always 0 and health is not actually the health shown in game (20 at level 1 === 622 in memory for example), it doesn't seem like a worth while time sink.

[ejt]

In retail (probably TBCC too, I haven't looked because it's relatively useless (to me)...) there's also a count of active objects @ s_curMgr] + 0x10

But you can't reliably loop the objects with that amount, since they change too frequently.

You're thinking about the TSHashTable which is the first object inside the curmgr, its similar to classic from what I can remember and should be 0x50 in size. Directly after it comes another TSHashTable containing invalid objects, after that of course comes a bunch of TSList's or maybe TSLink, can't remember off the top of my head. Should be around 15 of them and lastly you have things like local guid, map id, movement globals, connection manager.

I'm feeling generous today so here's the TSHashTable for classic, should be similar or identical to what retail uses, you figure it out.

// size = 0x50
template <typename T>
struct TSHashTable
{
	uintptr_t vtable;			// 0x00
	TSList<T> List;				// 0x08
	TSGrowableArray<T> Array;	// 0x20
	int32_t SlotMask;			// 0x38
	int32_t unk_03C;			// 0x3C
	int32_t unk_040;			// 0x40
	int32_t unk_044;			// 0x44
	int32_t key;				// 0x48
	int32_t unk_04C;			// 0x4C

	T* operator[](WowGuid guid)
	{
		auto k1 = 0xA2AA033B * static_cast<uint32_t>(guid.high & 0xFFFFFFFF);
		auto k2 = 0x292FE70B * static_cast<uint32_t>(guid.low & 0xFFFFFFFF);
		auto k3 = 0xA2AA033B * guid.high;
		auto k4 = 0xD6D018F5 * guid.low;

		uint32_t hash = static_cast<uint32_t>(k1 - k2 + ((k3 + k4) >> 32));
		auto index = hash % key;

		auto obj = (Array.Data + index)->object;
		while (!(reinterpret_cast<uintptr_t>(obj) & 1) && obj)
		{
			if (obj->GuidHash == hash)
				return obj;

			obj = obj->LastLink.Next;
		}

		return nullptr;
	}
};

Have not tested the hashing algorithm for tbcc but should not have changed since 1.13

[ChrisIsMe]

You're thinking about the TSHashTable which is the first object inside the curmgr, its similar to classic from what I can remember and should be 0x50 in size. Directly after it comes another TSHashTable containing invalid objects, after that of course comes a bunch of TSList's or maybe TSLink, can't remember off the top of my head. Should be around 15 of them and lastly you have things like local guid, map id, movement globals, connection manager.

I'm feeling generous today so here's the TSHashTable for classic, should be similar or identical to what retail uses, you figure it out.

// size = 0x50
template <typename T>
struct TSHashTable
{
	uintptr_t vtable;			// 0x00
	TSList<T> List;				// 0x08
	TSGrowableArray<T> Array;	// 0x20
	int32_t SlotMask;			// 0x38
	int32_t unk_03C;			// 0x3C
	int32_t unk_040;			// 0x40
	int32_t unk_044;			// 0x44
	int32_t key;				// 0x48
	int32_t unk_04C;			// 0x4C

	T* operator[](WowGuid guid)
	{
		auto k1 = 0xA2AA033B * static_cast<uint32_t>(guid.high & 0xFFFFFFFF);
		auto k2 = 0x292FE70B * static_cast<uint32_t>(guid.low & 0xFFFFFFFF);
		auto k3 = 0xA2AA033B * guid.high;
		auto k4 = 0xD6D018F5 * guid.low;

		uint32_t hash = static_cast<uint32_t>(k1 - k2 + ((k3 + k4) >> 32));
		auto index = hash % key;

		auto obj = (Array.Data + index)->object;
		while (!(reinterpret_cast<uintptr_t>(obj) & 1) && obj)
		{
			if (obj->GuidHash == hash)
				return obj;

			obj = obj->LastLink.Next;
		}

		return nullptr;
	}
};

Have not tested the hashing algorithm for tbcc but should not have changed since 1.13

It's relatively useless in Classic in my opinion, because there doesn't seem to be as many environmental triggers or 'hidden' objects that would benefit you as such in Retail. It can be quite valuable to visualize where certain types of 'trap doors' or such are, that will let you know when hidden ground destruction mechanics or things like that, will take place.

This is basically a '0 day' share though, can't wait for the next public bot to feature thousands more objects than previous.

Good share, regardless.

// Edit; And no, the object count I'm referring to is not related to this hashlist. The hashlist count is usually like 2048 or 4096.

The count I'm talking about is the actual size of the Linked List, but the list changes quite quickly.

Although the GUID hashing algorithm is the same as the name cache, so it should be simple for everyone to port the code and use.

Alll of the GUID hash tables seem to be built around GitHub - jandrewrogers/MetroHash: MetroHash v1: Exceptionally fast and statistically robust hash functions or something very very similar.

[ejt]

It's relatively useless in Classic in my opinion, because there doesn't seem to be as many environmental triggers or 'hidden' objects that would benefit you as such in Retail.

Hash tables are used to increase speed not get access to any "hidden" objects. All the objects in the active objects hash table also exist in the other lists.

Looking up guid => object using the hash method is O(1) while using the linked-lists is O(n). This is why you use the hash table.

This is basically a '0 day' share though, can't wait for the next public bot to feature thousands more objects than previous.

This is not a 0day share, they used this for a while now and is well known and reversed. Also as mentioned above, you don't get access to any "hidden" or extra objects by using the hash table.

// Edit; And no, the object count I'm referring to is not related to this hashlist. The hashlist count is usually like 2048 or 4096.

The count I'm talking about is the actual size of the Linked List, but the list changes quite quickly.

There are two storages in the hash tables, a linked-list and a dynamically allocated array. What you are mentioning here (2048 & 4096) is the number of allocated objects in the dynamic array.

When you say it changes quickly I think you mean the number of objects in the list and of course depending on if you're standing in a big city or a desert its going to be faster or slower adding/removing objects. If you're not syncing when reading objects it's inevitably going to end up with misses no matter which list or method you choose.

[ChrisIsMe]

Hash tables are used to increase speed not get access to any "hidden" objects. All the objects in the active objects hash table also exist in the other lists.

Looking up guid => object using the hash method is O(1) while using the linked-lists is O(n). This is why you use the hash table.



This is not a 0day share, they used this for a while now and is well known and reversed. Also as mentioned above, you don't get access to any "hidden" or extra objects by using the hash table.



There are two storages in the hash tables, a linked-list and a dynamically allocated array. What you are mentioning here (2048 & 4096) is the number of allocated objects in the dynamic array.

When you say it changes quickly I think you mean the number of objects in the list and of course depending on if you're standing in a big city or a desert its going to be faster or slower adding/removing objects. If you're not syncing when reading objects it's inevitably going to end up with misses no matter which list or method you choose.

If you're not seeing substantially more objects then this is something different than I am thinking of entirely.

Without comparing your ObjectManager class/struct to mine, I couldn't tell you.



Now I've said too much

[ejt]

Now I've said too much

Ignorance is bliss