[Classic] 1.13.2.31882

[SatyPardus]

simple code to increase nameplate range if anyone was curious

*reinterpret_cast<float*>(Base + 0x2534BF0) = 60.0f;

That's amazing. Works great.

I do have a question though.
The ObjectGUID should be unique, right? (I mean the name implies that), though when I read out the GUIDs of all objects together with their positions and other info, I get a lot of duplicates.
Also, the target and mouseover target have the same behavior. Am I doing anything wrong or am I misinterpreting the GUID.

Also, I found the current players name at "Wow.exe+0x26133E8" (It's my first time trying to find offsets, hope this is useable and right lol)

[xalcon]

wow's GUIDs are unique. Keep in mind they are 128 bit numbers. If you only read 64 bit, then you might run into duplicates, especially since they are not randomly generated but have an actual structure encoded into them.

[SatyPardus]

wow's GUIDs are unique. Keep in mind they are 128 bit numbers. If you only read 64 bit, then you might run into duplicates, especially since they are not randomly generated but have an actual structure encoded into them.

Aaaaah... Yeah I really have trouble finding resources for the proper types of fields. I was thinking it's a 64bit value as it returned the most promising results. 128bits works perfectly now and got no duplicates anymore (as far as I see).
Thank you a lot.

Another thing: The Object Types are single bytes, right? I found in the Constant Data Thread it's announced as "uint", though the values don't line up at all. I currently get 7 for myself, 6 for other player, 5 for NPCs and 8 for Objects like couldrons, foodcrates etc. But I can not line that up with any information I could find. Any search terms for these kind of things would be greatly appreciated! I just try to google for example "wow classic memory reading unit types" but that doesn't get the results I come up with. (No matter what variable type I use)

[KKira]

wow's GUIDs are unique. Keep in mind they are 128 bit numbers. If you only read 64 bit, then you might run into duplicates, especially since they are not randomly generated but have an actual structure encoded into them.

Can you explain how a size of 4 stores 128 bits? assuming 4 is in bytes 4*8 = 32 bits, or am I misunderstanding the size in the descriptors?
also what does flags and MIRROR_ALL mean?

[ChrisIsMe]

Can you explain how a size of 4 stores 128 bits? assuming 4 is in bytes 4*8 = 32 bits, or am I misunderstanding the size in the descriptors?
also what does flags and MIRROR_ALL mean?

I'm not sure I get what you're saying, but I feel like you're trying to think of the whole GUID being in one single address, which it's not.

struct ObjectGUID {
    int guid1;
    int guid2;
    int guid3;
    int guid4;
};

[xalcon]

Can you explain how a size of 4 stores 128 bits? assuming 4 is in bytes 4*8 = 32 bits, or am I misunderstanding the size in the descriptors?
also what does flags and MIRROR_ALL mean?

/* EDIT: Descriptor field sizes are actually not given in bytes but DWORDs and therefore need to be multiplied by 4 */
Generally, yes, Descriptor Fields are given with their size in bytes (even though the values arent 100% correct, i recall seeing some comments on the MoP descriptor dumper tomrus has on his github). I'm not fully informed on this topic since the last time I actually played around with the object manager was back in cata.
See, the GUID is structured as it contains several information like object type, server, npc id and so on.

For creatures, pets, objects, and vehicles: [Unit type]-0-[server ID]-[instance ID]-[zone UID]-[ID]-[spawn UID] (Example: "Creature-0-970-0-11-31146-000136DF91")

I assume that the "GUID" in the object descriptor is what wowpedia calls the "spawn id". The full guid is stored elsewhere.
On the topic of mirror flags, i have no clue. Might have something to do with server synchronization. Maybe someone else can enlighten us.

Another thing: The Object Types are single bytes, right? I found in the Constant Data Thread it's announced as "uint", though the values don't line up at all. I currently get 7 for myself, 6 for other player, 5 for NPCs and 8 for Objects like couldrons, foodcrates etc. But I can not line that up with any information I could find. Any search terms for these kind of things would be greatly appreciated! I just try to google for example "wow classic memory reading unit types" but that doesn't get the results I come up with. (No matter what variable type I use)

It depends, what type are we talking about? There are actually 2:
A 4 byte bit mask in the object manager linked list entries and a 1 byte type value in the object descriptor.
The bitmask has a bit set for each descriptor type this object has while the type value in the object descriptor itself is the actual object type.
The values in the constant data thread are probably severely outdated and I'm not in the position to verify the current ones since I'm only working on the 1.12.1 client at the moment - but I recall seeing some updated ones in one of the bin dump threads of legion.. or WoD, not sure. (I know there are quite a few, so this will be a bit of work, but i cant spoon feed you everything, right? )

[shauren]

Generally, yes, Descriptor Fields are given with their size in bytes (even though the values arent 100% correct, i recall seeing some comments on the MoP descriptor dumper tomrus has on his github). I'm not fully informed on this topic since the last time I actually played around with the object manager was back in cata.
See, the GUID is structured as it contains several information like object type, server, npc id and so on.

I assume that the "GUID" in the object descriptor is what wowpedia calls the "spawn id". The full guid is stored elsewhere.

Your assumption would be incorrect, that is in fact the full guid, each "field" in the format described on wowpedia does not take up a full int/byte/whatever, they are packed more densely
See TrinityCore ObjectGuid class for an example (accurate for Creature guids but not all 40+ types) TrinityCore/ObjectGuid.h at c674a3a18843c79b133600667f0b2bfc4c3d6594 . TrinityCore/TrinityCore . GitHub

On the topic of mirror flags, i have no clue. Might have something to do with server synchronization. Maybe someone else can enlighten us.

These determine what fields you are allowed to see on client (checked serverside)

It depends, what type are we talking about? There are actually 2:
A 4 byte bit mask in the object manager linked list entries and a 1 byte type value in the object descriptor.
The bitmask has a bit set for each descriptor type this object has while the type value in the object descriptor itself is the actual object type.
The values in the constant data thread are probably severely outdated and I'm not in the position to verify the current ones since I'm only working on the 1.12.1 client at the moment - but I recall seeing some updated ones in one of the bin dump threads of legion.. or WoD, not sure. (I know there are quite a few, so this will be a bit of work, but i cant spoon feed you everything, right? )

Constants data is indeed outdated, object types changed in 8.0 with addition of ActivePlayer and AzeriteItem stuff - applies to classic as well since its based on 8.0 client

[xalcon]

Your assumption would be incorrect, that is in fact the full guid, each "field" in the format described on wowpedia does not take up a full int/byte/whatever, they are packed more densely
See TrinityCore ObjectGuid class for an example (accurate for Creature guids but not all 40+ types) TrinityCore/ObjectGuid.h at c674a3a18843c79b133600667f0b2bfc4c3d6594 . TrinityCore/TrinityCore . GitHub

/* EDIT: A misunderstood the size in the descriptor fields. Size is indeed multiplied by 4 bytes, so the descriptor contains the full 128 bit GUID. Sorry! The following paragraph contains bullshit and is only retained to show how bad i am. */
The code you are refering to uses the 64 bit _high part of the guid to encode additional data. I was talking about the lower 32 bit of the _low part. I think we are talking about different things here. I dare to say the ObjectDescriptor.GUID field does not contain the full GUID but only the lower 32 bit and the full GUID is actually stored in the object manager linked list entry. But - as always - take my information with a grain of salt :P There might be a way to encode 128 bit worth of data into a 32 bit space that I don't know about - but Trinity's ObjectGuid isnt doing that.

Constants data is indeed outdated, object types changed in 8.0 with addition of ActivePlayer and AzeriteItem stuff - applies to classic as well since its based on 8.0 client

I see a lot of conflicting information about this, but 8.0 would make the most sense to me. Thanks for your input.

[shauren]

I should have extended the hilighted lines to include one more function, my bad

Adding to that, pay close attention to what ida shows you, client can compare/read/store entire guid at once using xmm registers

[NoxiaZ]

Hi,

Anyone found the offset for the Viewmatrix of the Camera?

[georgeon]

please,how to get the unit name?
ObjectName1 = ObjMgrPtr + 0x478,
ObjectName2 = ObjMgrPtr + 0xE0,
UnitName1 = ObjMgrPtr + 0x17B8,
UnitName2 = ObjMgrPtr + 0xE0,
the offset i can not get any more...thx