Math woes

[Teelo]

Oookay. So. I have a bunch of units spread out in a grid, with their locations stored in a two-dimensional array (struct with an array of another struct).

Here is the function that is annoying me:

.

function get_target_square takes square origin, real angle, integer distance returns square
        local integer c = origin.x
        local integer r = origin.y
        
        if (angle < 90.0 or angle > 270.0) then 
            set c = c + distance
        endif
        if (angle > 90.0 and angle < 270.0) then 
            set c = c - distance
        endif
        if (angle < 180.0 and angle > 0.0) then 
            set r = r - distance
        endif
        if (angle > 180.0 and angle < 360.0) then 
            set r = r + distance
        endif
        
        call BJDebugMsg("DEBUG. get_target_square: angle = " + R2S(angle) + ", origin = " + I2S(origin.x) + " " + I2S(origin.y) + ", c = " + I2S(c) + ", r = " + I2S(r))
        if (c < 0 or c > 7 or r < 0 or r > 7) then
            return null
        endif

Angle comes from the units facing, and that method is supposed to work out what square in the grid it is looking it. It is supposed to return the square directly infront of it, based on its facing.

Here is some data I'm plugging in, and the incorrect results that method is returning:

origin.x = 3
origin.y = 0
angle = 270.000
distance = 1

Output (from that BJDebugMsg):
c = 2
r = 1

Its returning the correct row in the grid, but it is changing the column when it shouldn't be changing it at all. The angle is 270, or directly south, so the column is supposed to be the same as the origin. Its acting like the angle is 225...

if (angle > 90.0 and angle < 270.0) then is returning true when it shouldn't be... when the angle is 270!

 

[Pharaoh_]

What the facing angle has to do with the column?
Plus, maybe you should also add

>=

?

 

[Teelo]

Well thats the problem. Its not less-than-or-equal-to, but its returning true as if it was.

If the angle is 0, it should be returning c+1, r+0.
If the angle is 45, it should be returning c+1, r-1.
If the angle is 90, it should be returning c+0, r-1.
And so on.... 270 is supposed to return c+0, r+1.

Angle of 90 returns c+1, r-1 too.

---

Okay, changing the conditions to < 89 || > 271, >91 || < 269 fixed it.
I don't understand why though... is the GetUnitFacing somehow a 269.999999 and rounded during a R2S()?

 

[Pharaoh_]

Well, so you are suggesting that the string caused the problem, not the actual real.

 

[Teelo]

No. When I hardcoded this units facing, I set it to 270.00. When that R2S() confirms for me that the facing is still indeed 270, it outputs "270.000". I wonder if internally the units facing is calculating something other than what the R2S is telling me?

 

[Pharaoh_]

Nah, I think it's a matter of accuracy actually, because interface real values have 270.00, but floating texts that display the values are like 270.0000 (and maybe more; get a damage detection system and you'll realize that).

 

[Justify]

Comparing reals to exact values is quite hard, yes, they seem to be quite inaccurate sometimes.

 

[Mooglefrooglian]

Ahem, *cough*.

function get_target_square takes square origin, real angle, integer distance returns square
        local integer c = origin.x
        local integer r = origin.y
        
        set c = c + R2I(Cos(angle)) * distance
        set r = r + R2I(Sin(angle)) * distance

        call BJDebugMsg("DEBUG. get_target_square: angle = " + R2S(angle) + ", origin = " + I2S(origin.x) + " " + I2S(origin.y) + ", c = " + I2S(c) + ", r = " + I2S(r))
        if (c < 0 or c > 7 or r < 0 or r > 7) then
            return null
        endif

Sine and cosine exist for a reason, you know. Specifically, to help with this sort of thing.

return null

How is that not erroring? A "square" is an integer, you should have to return square(0).

Edit: If you use an angle in degrees like you seem to be using, CosBJ and SinBJ. The non bjs take radians, not degrees.