Get real energy value

[Edder]

please scroll down...

[flo8464]

Thanks for all the usefull data you supplied to us.
Nobody is able to help you without knowing what you exactly do.

[Edder]

Im getting the energy with this piece of code:

// C#
// patch 3.3.5a
int Energy = wow.ReadUInt(wow.ReadUInt(playerbase + 0x8) + ((uint)UnitFields.Energy * 4));

And I update the value every second just like health, health is everytime correctly updated, energy isnt (only tested with mana).
Example: From memory I read value 90 but the client shows me 100 mana and it does not update, after casting a spell which cost 5 mana, the mana is correctly updated to 95 but it doesnt continue to 100 (full mana).

[_Mike]

Energy is UNIT_FIELD_POWER4, mana is UNIT_FIELD_POWER1 iirc

[Edder]

Energy is UNIT_FIELD_POWER4, mana is UNIT_FIELD_POWER1 iirc

Correct, but thats not the point. The way of getting the power value is fine.

In my case -> Energy = 0x19 = UNIT_FIELD_POWER1

[andy012345]

Look at 0x5B2BD0 (CGUnit_C::GetPower) and 0x88D750 (GetPowerDivisor). Your power is first / second.

[_Mike]

Correct, but thats not the point. The way of getting the power value is fine.

In my case -> Energy = 0x19 = UNIT_FIELD_POWER1

I see. I thought it might have been some weird side effect of reading the wrong power type. But then I don't know, sorry.

[Bananenbrot]

This happened to me too when I accessed the descriptors out of process. CE shows the same values, it's stored like that in memory. Actually I would be interested in this, too.

[andy012345]

Heres code for the function btw: DWORD __thiscall sub_5B2BD0(CGUnit_C *this, int powertype) { CGUnit_C *v2; / - Pastebin.com Edit: pastebinned, forum likes to remove newlines

[Edder]

Look at 0x5B2BD0 (CGUnit_C::GetPower) and 0x88D750 (GetPowerDivisor). Your power is first / second.

You mean like this?

uint one = wow.ReadUInt(playerbase + 0x8) + (0x5B2BD0 * 4);
uint two = wow.ReadUInt(playerbase + 0x8) + (0x88D750 * 4);
uint actual_mana = one / two;

Does not work :S get always zero

I should mention that Im on a private server and I guess the mana is a visual client effect and in the memory is the last value the server send the client?!
Will try to get my mangos server back up and test it locally.

[andy012345]

Those are addresses of functions. lul

[Edder]

Well this was a serverside effect, on my local mangos server it worked right now just fine, on the other (trinity I guess) I got the mana update problem.

[andy012345]

Thats cool, but not everyone plays private servers. My help was for people who want to get their power the correct way, some emus are probly still sending power updates out because they havn't implemented predicted power correctly, or just left the code in there because it doesn't really bother them. Client ignores updates from power fields with predicted power enabled anyway, so it doesn't really bother the emus.

[Edder]

So, by calling the function at 0x5B2BD0 and dividing the result through the value resulting from calling the function at 0x88D750, I get the current power and it doesnt matter if I play a class with mana, rage, runicpower or whatever?
How do I call a function, if I got the address?

[Edder]

I'm now able to get the health and mana or even the level from Character logged in, but what about the race and class (to determine if energy, mana etc. is used)?
I found no offset for race/class and I think there is none, so how do we get it? Lua function?

I also saw UNIT_FIELDS_BYTES_0 and stumbled over this in another source of a bot, I study:

const Structures::Races Objects::playerRace()
{
   return (Structures::Races)(UINT8)
      ((readUInt(unitField(playerBase()) + Offsets::UNIT_FIELD_BYTES_0 * 4) >> 0));
}

const Structures::Classes Objects::playerClass()
{
   return (Structures::Classes)(UINT8)
      ((readUInt(unitField(playerBase()) + Offsets::UNIT_FIELD_BYTES_0 * 4) >> 8));
}

I tryed it on my code, but I cant get it to work, I dont get the values that identify my class/race, my playerbase must be correct (i get correct health, mana, level values) and my UNIT_FIELD_BYTES_0 is 0x17.
In particular I dont understand this: >> 8 respectively >> 0