According to the wiki, deaths counts are signed. However in my map, I have something like this.

Conditions:
Always
Actions:
Set deaths for "timer", subtract 1
preserve trigger

Conditions:
deaths for "timer" are exactly 0
current player brings at least 1 "hero" to "heal beacon"
Actions:
set hp for all "hero" at "healing location" to 100%
set deaths for "timer", set to 180
display message "wait 30 seconds for next heal"
preserve trigger

Conditions:
Always
Actions:
Half speed hyper triggers

If death counters were signed, then the trigger wouldn't work, since "timer" would be 0 only for a 6th of a second, then it would descend into the negative numbers.

So why does the wiki say that death counters are signed?

The actual byte value that StarCraft reads IS signed, but StarCraft does not subtract into negative (you can, however add a negative number to get into the negative range!), nor does it overflow to 4,3 billions.

And aside from that, the triggers you mentioned would still work, something like this:

Trigger cycle 1:
DC value is 1
Trigger subtracts 1
DC Value is 0
Trigger 2 runs, sets DC value to 180
Next Trigger Cycle

OR, if you reversed the trigger order

Trigger Cycle 1:
Trigger doesn't fire since deaths = 1
Trigger subtracts 1
DC = 0

Trigger Cycle 2:
Trigger fires since deaths = 0, sets to 180
Trigger subtracts 1, deaths = 179

How do you put a negative value into the set deaths action in SCMDraft2?

What I do is enter 2147483648 into the number field, and then it turns into -2147483648, then change the number to what I want... Or copy/paste works, I think...

Ok, death counts are unsigned. The wiki entry is wrong.

Case in point:


After running this trigger deaths for goliath turret are equal to zero. They should be equal to 8.

The only way this makes sense, is if death counts are unsigned.

Change your action from "subtract, -3" to "add, -3"

Dude, I'm not trying to get into the negative range. Subtracting -3 from 5 should yield positive 8.

Further evidence that death counts are unsigned.

"Deaths >= 1" prints

None of this makes sense if death counts are signed.

However if starcraft actually sees -3 as positive 4294967293, then all of these results make sense.

Now if you say:

The result is 4294967290, a number classic trigedit believes to be -3. Why?
Because what classic trigedit swears is -3, is actually 4294967293.
4294967293 + 4294967293 = 8589934586
Written in hex this is: 0x1FFFFFFFA
The overflow bit (the 1 at the beginning) gets ignored. This leaves us with: 0xFFFFFFFA = 4294967290

Post has been edited 3 time(s), last time on Nov 15 2009, 11:09 pm by scwizard.

You don't subract -3, you ADD, I have tested this myself, if you use StarForge to add a negative number, once you do it when it's already at 0, it jumps up to 4294967294, which is the equivalent of -1, it's just how signed numbers are actually handled in memory, while a memory scanner may see it as such a huge number, it's really negative. Honestly, when you really think about it there is no true difference between signed and unsigned, except in how we or a compiler handles it.

Yes there is, subtraction handles signed and unsigned numbers completely differently.

And starcraft handles death counts like unsigned numbers when performing subtraction.

The less than function handles signed and unsigned numbers very differntly, and the starcraft less than function for death counts treats death counts like unsigned numbers.

The add function works the same regardless of wheather the number is signed or unsigned. However because starcraft treats the data as unsigned when running the other functions on it, we should call it an unsigned number.

Which makes more sense, to say:
Death counts are signed, except subtracting an negative death count from a positive death count always yields zero, and negative values are always considered greater than all positive numbers according to the condition.

Or do say:
Death counts are unsigned.

The wiki should state the later.

My argument can be sumerized thus:
If it looks like a duck, swims like a duck or goose, walks like a duck or kind of like a goose, and quacks like a duck, it's a duck.

Post has been edited 4 time(s), last time on Nov 16 2009, 4:41 am by scwizard.

I don't know much about this specific topic, but in rebuttal: If it is actually a goose, but seems to have the characteristics of a duck more so than a goose, it should still be known as what it really is.

There is no such thing as a goose that quacks like a duck.

Geese go "honk honk" ducks go "quack quack."

Until you can perform some genetic testing (by dissembling starcraft, and seeing if it uses the signed or unsigned comparison operators to compare death counts), I declare that quacking bird over there to be a duck.

Seriously though, if it used the signed comparison operators, then it wouldn't declare 0xFFFFFFFF to be greater than 0x0000001.

One more thing:
Finally I know someone is going to jump on me about me being wrong about subtraction distinguishing between signed and unsigned numbers. I had forgotten for a second that it subtraction didn't.

What starcraft is doing here is ignoring overflow when performing death counter addition, and in the case of death counter subtraction setting the result to 0 in the case of overflow.

EDIT: Wait no it's something different from that.

Post has been edited 1 time(s), last time on Nov 16 2009, 5:06 am by scwizard.

I'll say it again, there really is no difference between signed and unsigned except how your compiler and how you handle it, in this case, the programmers of SC handled it like an unsigned number, in how they created their conditions, so I wouldn't call it signed or unsigned, however, you are right, it has more characteristics of an unsigned number, and I don't know who decided it was signed.

I know this. There's no data typing in machine code, it's all ones and zeros. However if you point that out when I point to a memory address being passed to a function and say "this is a memory address" you're being pedantic.

And that's why we should call it an unsigned number.

Hold on, scwizard is right.

Bull's eye hit! If starcraft triggers handle it as unsigned, why are we calling them signed then?

However, please make it clean to me what happens when we add 1 deaths to the 0xFFFFFFFF. Will the resulting number (I mean the number which is written in memory) be the same or zero?

It would be zero of course:
http://codepad.org/twW0UzLJ

A more relevant question is the result of comparison:
http://codepad.org/oOEq0Wfr

SC follows unsigned patterns in that case as I have discussed.

It's both signed and unsigned.

Signed in score and set deaths (action).
Unsigned in deaths (condition).

That doesn't make sense.

If it was signed in set deaths, then why would the following:
"Set deaths "goliath turret" set to 5 for current player"
"Set deaths "goliath turret" subtract -3 for current player"

Result in deaths of "goliath turret" equal to 0, instead of equal to 8?

Also can you realistically imagine the starcraft coders casting the value to unsigned to write the code for conditions? That would be silly.
Adding and subtracting signed values is indistinguishable from adding and subtracting unsigned values.

Therefore it would be correct to say that the values are unsigned for death count actions, and we should say so since it's less confusing.

The alternative is saying: "death counts behave like unsigned values in conditions, and behave like both signed and unsigned values in actions"

Post has been edited 1 time(s), last time on Nov 16 2009, 5:27 pm by scwizard.

Ugh, I am getting confused.

scwizard, I'm not asking what happens in C, because I know that would be an overflow. However who told SC triggers behave exactly like C? My question is if there is an overflow if one executes "Set deaths for Player 1: Add 1 for 'Terran Marine'", given that Player 1 has already got 0xFFFFFFFF deaths of 'Terran Marine'?

If there is, one can state SC handles DCs as signed (however it is still up to the mapmaker how she treats em). If there are no overflows there is nothing even to talk about signed.

By now I see contrast answers. NudeRaider states there are no overflows. scwizard states there are. Heinermann states SC actions treat DCs as signed, hence there are overflows.

Confused here. Please clearfy.

Post has been edited 1 time(s), last time on Nov 16 2009, 9:46 pm by Wormer.

When performing addition, there are most certainly overflows. I have tested this.
Subtraction still needs to be tested more.
Comparison treats the values as unsigned.