i'm not speak English well, so please understand my English skills, vocabulary and grammar.


I can't find local unit's health EUD.
I can't suppose how to find this EUD using Artmoney filter, either.
if local 0 recognize offset is 0x0059CCE4, how to recognize local 0's health?

what i want to know is when i clicking on local id ## unit, then EUD condition recognize this unit's health, and run trigger action.
if i'm not use 'detect Local id's unit health' EUD, my map will crash when it play multiplay mode.

It was posted somewhere, or you use ArtMoney. Create a unit and you know that its local ID is 0. Then change its HP with triggers and see what value changes in ArtMoney.

Quote

what i want to know is when i clicking on local id ## unit, then EUD condition recognize this unit's health, and run trigger action.

You must know the Local ID of the unit to find its HP. There is not a way to find out the HP of the unit you clicked on.

What I do is put the Current Selection Group address in ArtMoney and then read the first 4-byte int in ArtMoney (takes out the whole search/filter process. ) That is the pointer to the unit in the unitnode table. Then, as shown in the UnitNode Struct, you find HP is +0x8 of that address.
However, the first byte of HP is for regen timers (Zerg) and for a fraction (I'm not completely certain about this, but it is used for something related to HP and screws up the values.) So when reading multiply the number by 256. It would probably be best if you did At Least HPVal*256, At Most (HPVal+1)*256-1 or something.

(Sorry if any of that is confusing, I just woke up and am not thinking properly yet.)

Divide by 256*.

EDIT: Nvm.

Post has been edited 1 time(s), last time on Jul 3 2008, 1:41 am by Clokr_.

Why would you dividy by 256? If you have the value 35 on the 2nd byte, you multiply.
00230000h = 8960d, not 0.13671875.

You are comparing values, not converting them.

The second byte is 0x0000AA00 <- that one. Blame Intel's little endian byte order. If you want to remove the first byte you gotta shift right the number 8 bits or use the integer division by 256.

You are comparing the values, not converting or removing anything. If you want to see if HP is 35, you multiply 35 by 256 and compare that to what is in the death. I am aware of little-endian stuff.

The second byte is offset 0x00000001, not 0x00000002. If you dividy by 256 you get some decimal, and these aren't FP.

But you're supposing that the low 8 bits of the HP field contains zeros. And that might not be true in an ongoing game, so you'd have to compare it to 35*256, 35*256+1, 35*256+2, ..., 35*256+255 because all of them would be valid values for 35 HP.

Also by 0x0000AA00 I was refering to the number 0000AA00h using C's notation, not an offset (AA was just a placeholder to mark the position).

I still don't know where you are getting dividing by 256 from. You can't edit the value you are reading, and even if you could bad things would happen if you did.

You guys are misunderstanding each other.

When going from "SC Values" to "logical HP" you divide by 256. When writing a trigger to compare SC's values, you multiply the HP you want by 256.

Endianness does not come into play here.

Yeah, that's right. Got confused when I read "So when reading multiply the number by 256". Anyway "It would probably be best if you did At Least HPVal*256, At Most (HPVal+1)*256-1 or something" comparing it that way is analogous to divide the DC value by 256.