I'm trying to learn more about euds, but I'm confused about the offset. I'm trying to do health detection. Here's what it says on the tutorial.

What does this mean?

I got
00 00 00 00 00 00 00 00
as a byte offset. Did I do it right?

None of that makes any sense, not even the wiki article. That's why you're confused.

Uhm.. I guess I was too confused even to make sense.

So basically, what I'm trying to do is have HP detection. I used artmoney to find the adress, and it came out to be 00615B51. I put it into EUD trig, and I pressed the arrow going down. It gave me the player number (P8), the Unit ID, (11903), and the byte offset (00 00 00 00 00 00 00 00). The problem is I don't know what to do with the byte offset to figure out the death value.

I agree. ;o

My explanation is probably no better, but it's a start....

Ok. Here is what the little "00 00 00 00 00 00 00 00" diagram means...
EUDs read data in groups of 4 bytes (as deaths have a 4-byte value), but sometimes a value might not be aligned to 4 bytes. Each 00 represents one byte. There are eight in EUDTrig just so if you have a 4-byte value that isn't properly aligned it can spill into the next group (though I don't think this happens much). Just ignore the last 4 in most cases... The first red one is the address that you used. If you have the data length set to 1, only that one will be highlighted. If you set it to 2, then two will be highlighted, etc. This is mostly just so it is pretty...

Health detection should show something like...
00 00 00 00 00 00 00 00
The first byte in this 4-byte group is a regen counter for zerg units or a fractional HP value for other units, so you probably wont know this value (which is why the value you found never includes the first byte). The remaining three are the HP value you see in SC. Because the first highlighted one is not the first 00 group shown, you will have to multiply a value you want to compare to by an exponent of 256 (shown below)... like if you wanted to test to see if a unit had 1 hp, you would multiply 1*256=256. If you wanted to test for 100 hp, 100*256=25600. Etc.

If the first highlighted byte is in these positions, multiply by the value shown:
00 00 00 00 - Multiply by 1 (Or not at all.) (1 = 0x01)
00 00 00 00 - Multiply be 256 (256 = 0x0100)
00 00 00 00 - Multiply by 65536 (65536 = 0x010000)
00 00 00 00 - Multiply by 16777216 (16777216 = 0x01000000)
-- You should never see the 5th+ bytes as the first highlighted byte, as it would give you +1 unit or +1 player.

Also, the first byte is unknown so comparing Exactly probably isn't the best idea...
To test for 100 HP, I'd test something like:
at least 100*256
at most 101*256-1
Which would test for an HP value >= 100 and < 101.

Ask questions, I'm definitely not the best at explaining these things. ;o

EDIT:
Wait, I don't see why 0xXXXXXX51 would give 00 00 00 00. ;o
I get P8//11903 and 00 00 00 00. ;o

EDIT2:
By looking at the very last digit of the address of a value, you can see what its alignment will be:
_0 _1 _2 _3
_4 _5 _6 _7
_8 _9 _A _B
_C _D _E _F
First column will be 00 00 00 00, second will be 00 00 00 00, etc.
xD I don't know if this is helpful.

Post has been edited 2 time(s), last time on Sep 4 2009, 10:45 pm by FaRTy1billion.

That helped a bit, farty. I just want to clear some things out.


I re-entered the address into EUDTrig and it now came up as 00 00 00 00. Wierd


So only the first highlighted one matters? In my case, I should use multiples of 256, right?

Can you explain more, please?

That's interesting xD I have an address to detect upgrades that ends with D. The first highlighed byte was the second one.

And I have a couple more questions. How would you find out the address for a mouse click? And how would you make EUDs do crazy things using actions? Use the set death action?

hp is 4 bytes total
the first byte is 0-255, which is extra precision. This is a hidden number, you can't see it, but zerg regen works of this principle. It quickly adds 4 to this number (very small) to get a regeneration.
The next 3 bytes is the number you see in game. To read the second byte, it's 256*hp. Since the 3rd byte isn't where the hp is actually located, you don't have to worry about it, it's still 256*hp, but if you go over 256*255, you'll get into the 3rd byte naturally.

in short, the first byte is hidden, the second byte is hp.

What if a unit has half a hp? (I.E 4 1/2) It seems like it's messing up the euds.

as I said, the half hp is actually a hidden value. it's some number between 0-255, usually 128. when you detect life, detect a RANGE not an exact number like I did in my health detection map.

So if you have a unit which has 100 hp in game, the actual number sc is reading (and what your EUD needs to be) is 25600. If the unit gets hurt and goes down to 55.5 life, you can't actually see that .5, but you know its there. The number in SC would be somewhere between 14080-14336. More than likely it's going to be 14208, but with zerg unit's it's virtually impossible to tell.

Alright, thanks. Ill try making the death condition in a range and not using exactly.

I changed the condition from exactly (256, 512, 768) to at most and at least (1-256, 267-512, 513-768) but now the trigger doesn't work at all. I have no idea whats going on

Edit: I ran artmoney on it again, and the address changed! Does changing terrain and placing units change the address?

units, yes.