Say you have 2 non-static points on the map (meaning that they could change), and the second point was below the first one, how would you calculate a negative slope? Do death counts even store negative numbers?

They don't. But you could use a switch or another DC as a "negative bit". Here's what I mean: let's say you have a number represented by "DC" and "SWITCH". If "DC" = 7 and "SWITCH" is Cleared, then the number is 7, but if "SWITCH" is Set, then the number is -7.

Post has been edited 1 time(s), last time on Feb 15 2009, 1:58 am by NudeRaider. Reason: LOL

You could use a traditional coordinate system to determine the two points. Set two DCs based on each coordinate's y value. Subtract one from the other (with binary countoffs). If one value reaches 0 before the other, it is lower.

death counts can be negative as long as they are set to that number (you can't subtract less than 0). -1 in binary is the highest number possible in binary (1111 1111 1111 1111 1111 1111 1111 1111). -2147483648 is the lowest decimal value (the most significant bit adds -4294967296). I don't think you can put negative numbers in scmdraft.

i posted this in another topic before and everyone told me it wouldnt read it as the negative number

so i just found a high number to use as my zero.

so like u could set 0 = 100 or w.e number floats ur boat and a "negative" number would be anthing X <100

I believe if you add a negative number and a positive number, they will subtract due to rollback. I haven't bothered to try as negative numbers are very confusing.

Slope? You mean an angle?

If you're looking for an angle, you can get the tan/cotan value, and have a pre-made table of values recorded in your map. Of course this will have to be approximate, and it might get a bit tricky:

Not only will the map have to hold all the whole numerical results, but also the remainders for cases when the whole result is not big enough... It's the only way to achieve atleast so-so accuracy that I can think of.

The negative bit is easy (as others have already said) - either use an additional switch/dc or set a high number as your zero.

No, I'm not talking about an angle, I'm talking about the slope of the line so that I can create explosions running from one point to another.

Rather than having a negative slope, just have the slope start out as a higher positive, like have 10 be the 0, instead of actual 0, so anything lower than 10 is basically negative.

Death Counts are unsigned, so if you try to add a negative number(only way to go past 0) they go to 65536, and if you go past that, it goes back to 0.

Ohhhhh. Then contact Lethal_Illusion, his first released FRAGS map involved exactly that. There is some quite simple formula for it...

FRAGS is an intersection formula. I'm pretty sure he's looking for something like Elementa.

You sure? If memory serves, the very first FRAGS version I've seen shot Dark Archon explosions in the direction you selected from the middle... Maybe we're talking about different versions?

Anyway, that doesen't matter because he needs to contact Lethal anyway.

I guess we're talking about different versions. I don't remember seeing that version. Could I have it to look at?

I'm not on my main comp, and I won't be on it for the next 1.5 months. Ask Lethal for it. I hope that my memory isn't failing me and the map I was talking about existed... I really forget a lot when I have 3-month breaks from mapping. >_<

DCs can be negative. You can subtract less than zero.
Add -1. If SCMDraft is retarded (and it probably is), you may have to put 4294967295.
If you ever use Subtract on any number less than or equal to zero, StarCraft will set it to zero if it is less. There is no such check anywhere on Add or Set.
Signed or Unsigned integers are exactly the same. Any operations done to them will come out the same...

For one, yes, SCM Draft is retarded, I ended up just using StarForge, however, how would you go about using it when it's unsigned? It doesn't actually go negative, it shoots up to the mega high binary number(I might have been wrong earlier).

Yes, but mathematically speaking, it doesn't work.

How doesn't it?

For one byte (to be simple)...
Given 0xFA (-6 signed, 250 unsigned) and adding 1 each time,
0xFA + 1 = 0xFB (-5 signed, 251 unsigned)
0xFB + 1 = 0xFC (-4 signed, 252 unsigned)
0xFC + 1 = 0xFD (-3 signed, 253 unsigned)
0xFD + 1 = 0xFE (-2 signed, 254 unsigned)
0xFE + 1 = 0xFF (-1 signed, 255 unsigned)
0xFF + 1 = 0x100 (which is an overflow for 1 byte, so it is cut to 0x00.)
When subtracting 1 from 0, you get 0xFF (or -1)... As we learn some time ago, subtracting is adding the opposite:
0 - 1 = 0 + -1 (0xFF, or 255)

Post has been edited 1 time(s), last time on Feb 17 2009, 2:53 am by FaRTy1billion.

Yes, but that now is basically splitting the number in half, and while yes, it does work, conditions and such that detect using At Least would detect 2147483648 as a really high number, rather than detecting it as -2147483647