Trigger - Basic Trignometry Problem

I'm trying to use some basic trig to place a unit directly behind another unit. I've been testing it using a timed trigger that every interval it repositions the unit with a "move instantly facing point with offset X,Y" action.

However, for some reason my math seems to be wrong even though on paper the tests I did gave the right results. The unit does get moved accurately to the circle's perimeter points, but not always to the correct point. Out of the four sectors in the X,Y plane starting at an assumed 0, 0 the move into two of the extremes have the unit directly in front of the unit in the opposite ones the unit is directly behind the unit. The moving unit moves perfectly in a circle around the target unit as it's facing angle changes by player control, however it seems to be moving in the opposite direction it should be. If the controlled unit turns counterclockwise the instant moving unit should follow this direction and stay behind it, and clockwise it should do the same again.

The math here is pretty basic trig as I'm no master at it.

I take the current "unit facing angle" and add 180 to it to get the angle that should be directly behind the unit. I do a sine function on that to get the X offset and then I do a cosine function on that again to get the Y offset. I then multiple those results by 150 (assuming like a 150 game units or however it measures distance, as 100 seems to be about melee range).

Here's my trigger for those who want to play with it and see what I'm talking about:

I made a unit called "DragUnit" that has 0 movement speed and can't be controlled for the most part, and then put it and a Paladin hero into a basic new map.


Now is my math wrong or the offset coordinates behave differently than I'm expecting or is there some other mechanic thing I've neglected? Let me know, and if you can solve it please explain as it will help learn. Thanks. ;)

Use polar offset, it will do the trigonometry for you.

Else apply "Divide and conquer" that's what sucks about GUI kind of forces you to do giantic lines of non-sense instead of dividing the problem, in JASS you would just create x,y variables and separate the deal

Thanks Vex, I didn't notice the polar offset option. That's a really simple way to handle the situation.

Although I'm still curious as to why this is coming out improperly. Would you be able to elaborate more on what causes this to happen or why? This division in the plane.

I was thinking that the normal offsets would be from an origin of 0, 0 and follow the negative values properly.

Yeah I haven't gotten into the full swing of Jass yet, I am a programmer and I would be inclined to lean that way, but I really don't do a lot of things if ever that would call on directly coding the triggers. The GUI triggers have long been familiar with me since Starcraft and I work a bit faster with them.

hmnn for starters you were using cos for x and sin for y

Actually, I don't think that matters, it depends on how you orient the axis. I think Blizzard has everything oriented so that cosine works with X and sine works with Y. It does appear that you're adding 180 after performing the function instead of before, that might be one of the biggest problems. You'd end up having the X and Y vectors on such a large scale that the small difference between the ratios would make it seem like nothing, plus the unit will move much more than you want it to.

Edit: Ignore that part about adding afterward, couldn't figure out which parenthesis went where. And I think Vexorian was right about using sine and cosine for the wrong axes. I think it's x-offset before y-offset.

Doh. Yeah that was it Vex. It works just the same now as the polar offset version. Thanks guys for the input, I appreciate it.

Edit: Yeah Naak, GUI triggers can be a cumbersome read at times.

set a = GetUnitFacing(target) - 180
set x = GetUnitX(target) + distance * CosBJ(a)
set y = GEtUnitY(target) + distance * SinBJ(a)
call SetUnitPosition(unit, x, y)

looks alot better than all that gui crap.

or even better :p

set a = (GetUnitFacing(target) - 180) * bj_DEGTORAD
set x = GetUnitX(target) + distance * Cos(a)
set y = GEtUnitY(target) + distance * Sin(a)
call SetUnitPosition(unit, x, y)

Yeah these guys tell you how to do it
Since you are a programmer, you will quickly learn and like Jass.

Btw, doing it with PolarProjectionBJ is just sin/cos math so whats the difference apart from the fact that you dont need to think how it works.

The difference is in efficiency. It might not be that big, but it's there.

PolarProjectionBJ uses a location.
Using reals is just performance wise, and faster.
Although, on wc3jass they say that they tested it, and said locations
are faster.

My point is that you dont have to worry about using a location and destroying it with polarprojectionbj, you can just use reals and
make it manually to prevent the very usage of the locations.

passing locations to natives instead of coordinates

But Location() + RemoveLocation() make it slower

And PolarProjectionBJ is an extra function call, besides of converting the angle to Rad twice.

So to sum up using just coordinates + Cos + Sin is way faster than PolarProjectionBJ

Read the whole tread, and look closely at the code. When Natuko(I think it was) did it he removed the passed location in the called function, so everything was just creating at 0,0 by default, so whos to say if that test really figured anything out.

Ah.
Well, I said that's what they said, not what I said.