It is hex. Just add '0x' before it. ('0x0059cc99')
Do you plan on hexediting the triggers yourself? xP If not, this isn't necessary.
Change "Unit Unit" to "Number Unit"

I don't fully understand what you are stating here... but the red 00s are byte placement based on the 4-byte value returned by Deaths. If you see only the left one highlighted, then you use a normal value. If the second set is highlighted, you multiply by 256. If the third, multiply by 65536. If the fourth, multiply by 16777216. Also you need to keep in mind that based on the data length size, there may exist other values in the result to be accounted for.

This is the data length... If you have an array of bytes (each value has a length of 1), select accordingly. Same with 2 or 4... I didn't really think of struct arrays when I made this, or else I'd make it an inputted value.

Well, it appears you are using StarForge, so you want signed. Technically, the values should be unsigned, but StarForge uses VB and VB refuses to allow unsigned values.
If you don't understand un/signed, here is a quick explanation:
We all know a byte is 8 bits, and has a value range of 0 (00000000b) to 255 (11111111b)... This would be unsigned because it has no +/- sign ever, always +.
Now for a signed value, it allows you to have negative numbers making the range -128 (10000000b) to +127 (01111111b).
One cool thing is that if you add the binary, signed and unsigned act exactly the same.

lolalreadydid.

I don't think it's 0x0059cc99, I'd put in 0x59cc99.

I agree though, don't hex edit unless you have to, or you want to learn how to do it. It's worthwhile to know, but if you can't figure it out with the information I've already given you, don't try.

It doesn't make a difference... Just like you could put 20 zeroes before a number, and it would still be exactly the same...

good to know, but there is an x in there, so I didn't know if that made a difference. After all, 0s after a . DO make a difference in the number...

'0x' is just the hex-notation...identifier...thingy. It isn't like a decimal point.
And 0s after a decimal don't make a difference... >.> As long as they are after the number. 1.1 = 1.100

They DO make the difference, if you use them correctly you show the precision that your calculation used.

Sry, I couldn't resist

1.1 doesn't need precision. 11/10, exactly. And adding trailing zeroes makes no difference because the 0s are just useless. >.> And if you want to get technical with calculators, it cuts off the trailing zeroes. They do exist in calcs, just not dispalyed. Would you like to see the ASM routines for it? xP

Ok, you really want to know it... so be it.
I didn't mean that the 0s change the value. They obviously do not.
But when talking about technical figures it's often unreasonable or impossible to display all fractional digits, so we round the number. But how do we know what a 'reasonable' precision would be?
I'll tell you what I learned in school (especially physics class, not maths!) about that, using a simple exercise:

Calculate the circumference C of a circle with the radius r = 2,52. pi = 3,1415
As a good pupil you will know: circumference C = 2 * pi * r. Exact answer: C = 15,83316

BUT when I answer 15,83316 I made a mistake and don't get full points. The correct answer is 15,8.
The reason is that I only have 3 significant digits: 2,52. Pi has 5 (in this exercise, I know it has actually 1 or 2 more^^) but only the number with the least digits (0,000032 is still 2 significant digits) is relevant.
The same thing is valid when you are supposed to multiply 2,5 and 3,6. You would have to answer 9.0.
At least that's what I learned but don't forget that it only applies to technical figures where it's important to actually put the calculated number into use. My comment wasn't entirely serious.

That's wrong - when you get to higher math you will learn error propagation.

Ex - area of a circle:

You know the radius is 1.0 (that's 1 ± 0.01 in your little 'sig-fig' notation).

A = πr² so dA = 2πrdr

Therefore, A = π(1)² = π and dA = 2π(1)(0.01) = 0.02π. So your area is π ± 0.02π (most exact answer). You can approximate pi to at least 2 decimal places to put it within the error range.

So really, zeroes after the final decimal number are insignificant


But yeah, like Farty said the '0x' in hex is just to say "this number is in hex, not decimal". It's a bit like (if you've ever programmed) writing 1L to mean the number 1, but as the long datatype.

No, the way I learned significant figures (Sig Figs) in chemistry was pretty much the same thing as what you stated but, when your answer is longer (contains more digits then what you started with) you have to compensate. When you have 15,83316 and you need 3 Sig Figs you take the first 3 numbers (1,5,8) and place them into a decimal. 1.58 . Then you have to put it into scientific notation of this to get the correct place values for the digits. 1.58 x 10⁶

[/quote]
That's what I learned at university. Still what I said earlier is valid in certain boundaries (school and when you didn't visit university).
Btw. lol about those numerous replies about a joke...

More questions:

I still don't get what the "Byte Offset" values mean.

Can you explain it visually?

Byte Offset: 00 00 00 00 00 00 00 00 = x?
Byte Offset: 00 00 00 00 00 00 00 00 = x?
Byte Offset: 00 00 00 00 00 00 00 00 = x?
Byte Offset: 00 00 00 00 00 00 00 00 = x?
Byte Offset: 00 00 00 00 00 00 00 00 = x?
Byte Offset: 00 00 00 00 00 00 00 00 = x?
Byte Offset: 00 00 00 00 00 00 00 00 = x?
Byte Offset: 00 00 00 00 00 00 00 00 = x?

NOTE: x? = Multiply by what. Also how do we know what to multiply by? EX: If you say multiply by 256, how do we find the number to multiply with by? EX:EX: N x 256 = ??? How do we know what N equals?

Post has been edited 1 time(s), last time on May 4 2008, 8:51 pm by Brontobyte. Reason: Fixed Equation

Byte Offset: 00 00 00 00 00 00 00 00 = 0x00 multiply by 2^8 = 256
Byte Offset: 00 00 00 00 00 00 00 00 = 0x01 multiply by 2^16 = 65536
Byte Offset: 00 00 00 00 00 00 00 00 = 0x02 multiply by 2^24
Byte Offset: 00 00 00 00 00 00 00 00 = 0x03 multiply by 2^32
Byte Offset: 00 00 00 00 00 00 00 00 = 0x04 ... etc.
Byte Offset: 00 00 00 00 00 00 00 00 = 0x05
Byte Offset: 00 00 00 00 00 00 00 00 = 0x06
Byte Offset: 00 00 00 00 00 00 00 00 = 0x07

Post has been edited 1 time(s), last time on May 4 2008, 9:05 pm by NudeRaider. Reason: added multis

The 0x0(#) = The first part of the hex code in the "Memory Offset" or that has nothing to do with it? If yes or no, what do I use it for? How do I find the number that I multiply by?

Each set of deaths for players is a four-byte long when evaluated in Starforge. The bytes are compiled in reverse "numerical" order, with the pointer 0x0 being the ones place, 0x1 the 256ths place, etc.

00 00 00 00

is the ones place - "multiply by 1"


00 00 00 00

is the next place - "multiply by 256" = 2^8


00 00 00 00

is the next place - "multiply by 65536" = 2^16


00 00 00 00

is the next place - "multiply by 16777216" = 2^32

There are only 4 bytes to the long. In the case of a longer sequence, only four bytes at a time correspond to given unit deaths value.

Someone should consolidate the information in these posts into a wiki.

I will do it, once I fully understand how to do this. Good idea.

Ok, here is what I have. The "Memory Offset" is correct, and all the other fields are correct. Now what do I do?
What do I multiply by 256? I know in rockz's EUD Health map, he used the triggers ~Exactly 256 deaths of Unit ID: ????. Does this mean 1 HP = 256 Deaths of the given Unit ID?



Post has been edited 1 time(s), last time on May 4 2008, 9:23 pm by Brontobyte. Reason: Added Quote

Yes.

Oh right, because the leading byte is the fractional HP flag. Note that you will get DIFFERENT death values for 2 hp and 2 1/2 hp, etc, since the leading byte will change (is it 0x00 and 0x01?)

Triggers will look like this:
Player 8 has suffered 256 deaths of UnitID:1585
Display for Current Player: "1"

Player 8 has suffered 25600 deaths of UnitID:1585
Display for Current Player: "100"

You may want to experiment with the extra precision (the numbers in between the multiples of 256, which I believe to be the regeneration counter for Zerg units) so that you also include them. For example:

Player 8 has suffered at most 25600 deaths of UnitID:1585
Player 8 has suffered at least 25473 deaths of UnitID:1585
Display for Current Player: "100"

Player 8 has suffered at most 128 deaths of UnitID:1585
Player 8 has suffered at least 1 deaths of UnitID:1585
Display for Current Player: ".5"

Of course, for your dragoon, the unit will always have a multiple of 128, since it can only have life at multiples of .5. In my map, if one of the Terrans gets hit by a 0 damage attack, or something, and somehow gets a .5 current life, the "exactly 256x" condition no longer detects properly, and doesn't display a number.