Get who unit is attacking...

[jbrauman]

I was looking through the various addresses in the unit fields, and there is nothing to tell me who the unit is attacking. I wanted to get the guids of all the units who are attacking myself by looping through the object manager and getting the guid of an object if the guid of the thing it is attacking (if any) is me. This would also tell me if I am in combat or not:

 
if (LocalPlayer.AttackingUnits.Count != 0)
  // in combat
else
  // not in combat

Could someone please describe how to get the guid of who a player/mob is attacking?

Cheers.

[jjaa]

[07:14:50]: UNIT_FIELD_FLAGS = 0x3A
[07:14:50]: UNIT_FIELD_FLAGS_2 = 0x3B

I think its in one of those

EDIT: wait that will tell you that the unit is attacking...

[schlumpf]

Then check the flags and their target. If its attacking and targeting you, its attacking you.

[Robske]

I believe attacking is stored in the DYNAMIC_FLAGS, as for target, just cycle through the list with UNIT_FIELD_TARGET

[jbrauman]

Thanks for all the replies.

I believe attacking is stored in the DYNAMIC_FLAGS, as for target, just cycle through the list with UNIT_FIELD_TARGET

Rob: How should I determine whether that unit is attacking by reading DYNAMIC_FLAGS? According to this:

    /* offset:[0x0120] */    unsigned long UNIT_DYNAMIC_FLAGS;

A ulong is stored in there. What are the possible values that this ulong could be, and how can I determine if the unit is attacking or not? Or is UNIT_DYNAMIC_FLAGS (I assume we are referring to the same address here) another structure? If so, what is the layout of this structure?

Forgive me for being totally ignorant but currently I have no knowledge of ASM or debugging / reversing and cannot find these things out myself (bar guesswork).

[Robske]

Hehe, noticed I was wrong, it's stored in the UNIT_FIELD_FLAGS allright.

Straight from BS's WOWXBase:

bool CGUnit_C::IsAggro()
{
return ( ( GetKnownField( UNIT_FIELD_FLAGS ) >> 0x13 )&1 );
}

[Cypher]

Then check the flags and their target. If its attacking and targeting you, its attacking you.

Totally unnecessary and won't work in certain situations.

Better way:
CGUnit_C member at 0x0A38. WGUID AttackingGUID.

[schlumpf]

Totally unnecessary and won't work in certain situations.

Better way:
CGUnit_C member at 0x0A38. WGUID AttackingGUID.

You don't want to upload all your classes etc. somewhere so we can use all your information, eh?

Still: When wont that work? Where are situations, where the target is different to the unit attacked? oO Or do you mean that checking two things is useless?

[jbrauman]

Totally unnecessary and won't work in certain situations.

Better way:
CGUnit_C member at 0x0A38. WGUID AttackingGUID.

Thanks Cypher. What structure is CGUnit_C? Unless I'm totally ignorant, you meant WGUID AttackingGUID is read from "CGUnit_C"-base + 0x0A38. However I have not come across this structure before. Was it the technical name for Unit_Fields? Or something completely different.

[Robske]

You don't want to upload all your classes etc. somewhere so we can use all your information, eh?

Still: When wont that work? Where are situations, where the target is different to the unit attacked? oO Or do you mean that checking two things is useless?

Why should he upload his classes?

Besides, there may be cases where a mob targets you yet doesn't attack (none come to mind however), using UNIT_FIELD_TARGET and UNIT_FIELD_FLAGS means atleast 2 reads and a call/loop while CG_UNIT_C's AttackingGUID member will yeild you an indisputable GUID.

[Cypher]

You don't want to upload all your classes etc. somewhere so we can use all your information, eh?

Still: When wont that work? Where are situations, where the target is different to the unit attacked? oO Or do you mean that checking two things is useless?

Ummm..... No?

Units can have aggro on another unit without actually targeting them. Last time I checked the target was cleared but the AttackingGUID still held true.

Thanks Cypher. What structure is CGUnit_C? Unless I'm totally ignorant, you meant WGUID AttackingGUID is read from "CGUnit_C"-base + 0x0A38. However I have not come across this structure before. Was it the technical name for Unit_Fields? Or something completely different.

Not gonna bother answering you anymore if you're not gonna bother doing some of your own damn research (on crap that has been covered a billion times).

Why should he upload his classes?

Besides, there may be cases where a mob targets you yet doesn't attack (none come to mind however), using UNIT_FIELD_TARGET and UNIT_FIELD_FLAGS means atleast 2 reads and a call/loop while CG_UNIT_C's AttackingGUID member will yeild you an indisputable GUID.

Obviously because schlumpf is the center of the universe and I should immediately release all information I have on WoW just to make his life easer, regardless of the impact that would have.

Also yes, using the unit flags and target is waste of resources and may not be 100% accurate.

[Xarg0]

Folks, if you'd search trought the older posts you'd find Cyphers WoWClasses, you could also use the WoWClasses of WoWX base, they're pretty much the same as they result from reversing the wowclasses. And if you'd look at the stickied 3.0.2 Thread you'd also find a lot of code from Cypher, if not his hole wowobjects.

Edit: Charmander was faster than me, this time...

[schlumpf]

Ummm..... No?

Units can have aggro on another unit without actually targeting them. Last time I checked the target was cleared but the AttackingGUID still held true.

Ah, I thought, that the flag would show if the unit is attacking, not if its has aggro.

[Robske]

regardless of the impact that would have.

"How to make people curious, a guide for dummies" - By Cypher

[jbrauman]

Okay, I think I understand what Cyper said, let me just throw this out there, and please tell me if it is right.

All objects in the object manager are subclasses from a "base class". I'm calling this base class WowObject. To my knowledge, the object manager never has an object with its class being WowObject. All the objects in there are subclasses of this WowObject and inherit all of WowObject's members, and they also extend WowObject depending on what class they are. This can be described programmatically like this:

class WowObject
{
   ulong Guid;  // read from base+0x30
   uint Type;   // read from base+0x14
   double XPosition;   // read from base+0x7D0
   ...
}
 
class PlayerObject : WowObject
{
   int Health;   // read from player unit fields + (0x17 * 4)
int MaxHealth;   // read from player unit fields + (0x1F * 4)
...
}
class DynamicObject : WowObject
{
   ulong Caster;
   int SpellId;
   ...
}
 
...

Which means that for every WowObject, be it a player or gameobject or dynamic object or w/e, you can get certain information from them (ie guid) in the same way, but then you can get information pertaining only to that object type (ie spell id)

Is that about right?
Thanks.

Edit: I tried to implement this functionality in my current code, but apparently it turns out casting (more specifically downcasting) is quite... interesting. Instead I just put in a "WowObject.ToPlayerObject" for every subclass. Eg. I'm reading from ObjectManager, and then determining what type of object it is, and then converting it to the type of object it is and continue reading information about it (only have a couple of NPC fields done but it shows what I'm doing (actual code, lol):

publicvoid UpdateObjectList()
{
// this method will loop through every item in the object manager
// and retrieve information about that object, then add it to the
// objectlist.
// make a temporary object and set the base address of it to the
// first object in the object manager
WowObject CurrentObject = newWowObject();
CurrentObject.BaseAddress = ReadUInt32((IntPtr)(ObjectManagerBase + GlobalAddresses.FirstObjectOffset));
 
// read from first object to last object in object manager
while (CurrentObject.BaseAddress != 0)
{
CurrentObject.Guid = ReadUInt64((IntPtr)(CurrentObject.BaseAddress + ObjectAddresses.GuidOffset));
CurrentObject.Type = ReadUInt32((IntPtr)(CurrentObject.BaseAddress + ObjectAddresses.TypeOffset));
CurrentObject.XPos = ReadFloat((IntPtr)(CurrentObject.BaseAddress + ObjectAddresses.XPositionOffset));
CurrentObject.YPos = ReadFloat((IntPtr)(CurrentObject.BaseAddress + ObjectAddresses.YPositionOffset));
CurrentObject.ZPos = ReadFloat((IntPtr)(CurrentObject.BaseAddress + ObjectAddresses.ZPositionOffset));
CurrentObject.Rotation = ReadFloat((IntPtr)(CurrentObject.BaseAddress + ObjectAddresses.RotationOffset));
switch (CurrentObject.Type)
{
case (uint)ObjectTypes.Item:
break;
case (uint)ObjectTypes.Container:
break;
case (uint)ObjectTypes.NPC:
NPCObject CurrentNPCObject = CurrentObject.ToNPCObject();
CurrentNPCObject.UnitFieldsAddress = ReadUInt32((IntPtr)(CurrentNPCObject.BaseAddress + 0x8));
CurrentNPCObject.CurrentHealth = ReadInt32((IntPtr)(CurrentNPCObject.UnitFieldsAddress + UnitFieldsOffsets.CurrentHealth));
CurrentNPCObject.MaxHealth = ReadInt32((IntPtr)(CurrentNPCObject.UnitFieldsAddress + UnitFieldsOffsets.MaxHealth));
// more to do
ObjectList.Add(CurrentNPCObject.Guid, newNPCObject(CurrentNPCObject));
// copy that into my local idictionary of wowobjects through copy constructor
break;
case (uint)ObjectTypes.Player:
break;
case (uint)ObjectTypes.GameObject:
break;
case (uint)ObjectTypes.DynamicObject:
break;
case (uint)ObjectTypes.Corpse:
break;
}
// set our current object as the next object
CurrentObject.BaseAddress = ReadUInt32((IntPtr)(CurrentObject.BaseAddress + ObjectAddresses.NextObjectOffset));
}
}

And by the way Cypher, I understand now what you were saying, applied it and it worked. Your terminology was what put me off.


EditEdit: Okay apparently this textbox cant understand the indentations in my code copied from Express C# so I screw it, its still kind of readable.