I ask this out of curiosity, it's not like my project is stuck because of this. Trying to implement health detection EUDs I found that the health variable for a unit is 2 bytes (correct me if I'm wrong), so would that mean the range of health points would be 65535 including 0? Also, I remember reading something like the first byte for zerg units' HP is for the purpose for acting as a timer and constantly increasing itself and adding 1 to the second byte when it's full, is this true? If it is then only the second byte would be the unit's HP, and it would only have 255 maximum HP, and that's obviously not true, so how does that work?

It's probably that I have no idea what I'm talking about, so I would be glad if someone could clarify how the bytes in unit HP work.

Post has been edited 1 time(s), last time on Nov 10 2009, 1:34 am by yoonkwun.

Whoever told you that is wrong. Health is 4 bytes. However, the displayed health value is actually the health points divided by 256. When a Zerg unit regenerates health, it's health actually just goes up by 4.

What about the byte needed to determine when to go up by 4 in zerg units? Would the actual health value be only 3 bytes then?

http://www.staredit.net/wiki/Regeneration <- how regeneration works.

HP is 4 bytes. The first byte is the hidden one, so the one you can see is 3 bytes. A marine with 10 HP would look like this: 00 0A 00 00. The actual range of HP is:
http://www.staredit.net/wiki/Map_Limits
8338607. That's 00 FF FF 7F. However, the first byte can still be FF, but that only corresponds to 255/256 visible HP, and not that important. SCMDraft and Starforge won't even let you input a number higher than 10 in the extra box, I don't think, but you can hex edit it in. Should you go any higher, the 32nd bit will be ticked, and you'll end up with negative HP, due to it being signed.

Note that when you read HP via an EUD condition, it requires you to read all 4 bytes. That makes it hard to detect zerg HP.

Ok, it's making some sense now. Another question out of curiosity again, why is the visible HP limited to FF FF 7F and not FF FF FF?

It's a signed integer.
0x7FFFFFFF is the maximum value, 0x80000000 is the minimum value.
The displayed value is (int)(HP >> 8).

I was giving you little endian numbers, which is what you'd see in a memory editor. The digits are in order from 0-7 like so:
10 32 54 76 = 0x01234567. If it's confusing, blame intel. Motorola uses big endian, which makes a little more sense, but nobody uses power PC anymore in a regular computer.

To understand signed integers, it works best if you understand the binary behind it.

Let's say we have a 4 bit signed integer. The 4th bit will be most significant, and will create the negative part of it. The first 3 bits add their respective numbers, and the last bit subtracts its number. So, going from binary to decimal:

1110 = 1 + 2 + 4 = 7
1111 = 1 + 2 + 4 - 8 = -1
0001 = -8
0011 = 4 - 8 = -4

Since in binary, each bit represents twice as much as the previous bit, you'll never have a positive number in a signed integer as long as the last bit is on.

FF FF FF would equal -1.
1111 1111 1111 1111 1111 1111 = 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 + 256 + 512 + 1024 + 2048 + 4096 + 8192 + 16384 + 32768 + 65536 + 131072 + 262144 + 524288 + 1048576 + 2097152 + 4194304 - 8388608 = -1

Also, if the unit has anything in the first byte, starcraft will round it up on the GUI that you see, which is why you can have units with 41/40 life. The unit only has 40 life + whatever is in that first byte.

Thanks all. At least now I know it's a topic beyond me =\

Ignore rockz's last post.

Really the most complicated part is understanding that the first byte is ignored.

Let's review...
- HP is 4 bytes.
- The first byte is essentially unknown for our purposes, the remaining 3 are the HP value.
- For positive health values, the max is 0x7FFFFF. Unless you set the unit's HP differently in the editor, it wont be any higher than that. You don't even need to know this ... Just read for whatever value you want. If you for some reason are reading a value greater than 0x7FFFFF, then you'd probably notice that your unit has negative HP and would probably do something about that.

To ignore the first byte of HP, do it like this....
Say you want to test to see if a unit has 10 HP. You now understand that the "10" will be in the second byte, not the first. That means you have to multiply the value 10 by 256 to make it read into the second byte. To ignore the first byte, just read every possible value for it... from 10*256 to (10+1)*256-1 (or from 10 to the greatest value less than 11). You can do that with At Least/At Most! The conditions will read At Least 2560 (or 10*256) and At Most 2815 (or 11*256-1).

Any questions? xD

Post has been edited 3 time(s), last time on Nov 10 2009, 11:39 pm by FaRTy1billion.

I think I get it now. I did something similar for my zerg health detection but might've got a number wrong in duplication, so now I know the proper way. Thank you. For terran and protoss units, though, using the Exact comparison with 2560, 2816 etc would be the correct way, right? Just to make sure.

Also, while we're on this general topic I have two questions regarding EUDs/starcraft memory, it's not about health directly but I'll ask it here anyway. If EUDs are just a buffer overflow, would it be possible to reach outside of StarCraft's memory? And since the Unit IDs and Player IDs just go above what's expected, is there any values that are, in a sense, before the Unit IDs and Player IDs and are unreachable with EUDs? I don't know if what I said made sense, if it doesn't tell me. Sorry if it's been answered before.

No, use the range. If it's greater than 25345 and less than 25600, the unit has 100 life. Terran and Protoss units can still negate some damage, and end up taking .5 damage.

I assume yes, you can read outside starcraft's memory. Isn't that how the theoretical virus could be written?

Player number can be negative, so you can reach any value.

I didn't think it was that confusing.

Thanks, is there a known limit to what it can detect, in EUD conditions, outside of StarCraft's memory? However I'm assuming it's really hard or unreliable because there are no maps that detect anything out of StarCraft's memory in the current patch to my knowledge..

Other than this that settles my curiosity for now.

Um, if StarCraft is like all the C++ programs I write then, no you can't read outside of StarCraft memory, it'll just cause a segmentation fault (aka StarCraft will crash). Operating systems these days are quite advanced and so each program is isolated in its own memory space.

He probably means outside of the main module(in the same memory space). Of course you can, but it'll crash if you try to read unallocated memory.

The main point of my saying that was that it goes into unnecessary detail.