We have reduced support for legacy browsers.

What does this mean for me? You will always be able to play your favorite games on Kongregate. However, certain site features may suddenly stop working and leave you with a severely degraded experience.

What should I do? We strongly urge all our users to upgrade to modern browsers for a better experience and improved security.

Umm… yeah it didn’t work. When I test this out it actually starts shaking no matter what. All the math is in radians, the turnSpeed is 10 because the unit is meant to turn pretty quickly. So I don’t think theres a problem there.

Using a dot product and a sign-switching variable is silly. Use the cross product instead, it preserves the sign of the angle:
`var angleDiff:Number = Math.asin(
Vector2.Cross(wantedForward, forward));`
… but since it’s 2D, the cross product is simply (x1y2)×(x2y1) so
`var angleDiff:Number = Math.asin(wantedForward.x*forward.y - forward.x*wantedForward.y);`

> *Originally posted by **[Arloistale](/forums/4/topics/319443?page=1#posts-6729186):***
>
> However, taking facing out of the equation seems to have worked for some reason.
The reason being it had no business being in it in the first place, as I explained. But hey, you’re welcome.
Edit: BobJanova, using cross-products and asin only works if the angle between the two vectors is in the [-90;90] degree range. In order to get the full angle you still need the dot product (its sign really) to determine the actual angle modulo 360 degrees.
Edit 2: Hahaha I didn’t see that:
> *Originally posted by **[Arloistale](/forums/4/topics/319443?page=1#posts-6729177):***
>
> All the math is in radians, the turnSpeed is 10 because the unit is meant to turn pretty quickly
10 radians per unit of time? How much is elapsedTime, and in what units? If you’re counting elapsedTime in ms and run at 30fps elapsedTime would be about 33 on average so you’d be turning at 330 radians per frame, or 52 turns and change. ‘pretty quickly’ indeed. If elapsedTime is in frames and you’re updating every frame then you’re ‘only’ doing one-and-a-half turn every frame, but it’s still nonsense. Only if you’ve set elapsedTime to be in seconds would you get a reasonable turn speed.
What I’m wondering is how you can have written two full classes and still be so uncritical of your own code and so passive when people suggest things to help you. You give the impression of trying out the things we suggest, make no effort to build up on them or further investigate the problems, and just come back to this thread for more suggestions. Have some initiative!

Aaand _triple post!_ How deep does this rabbit hole go? Nobody knows. In the meantime this:
`
public static function AngleBetween(vector1:Vector2, vector2:Vector2):Number
{
return Math.atan2(vector2.y - vector1.y, vector2.x - vector1.x);
}
`
is garbage.
Let’s take an example. Vector 1 is (5,5), vector 2 is (3,3). They’re obviously colinear, so the angle between them should be 0 (or pi, but in this case zero). By your formula (hint: the formula is wrong) the angle is actually Math.atan2(5-3, 5-3) = pi / 4. So yea, there’s that, too.
Edit: See, this is what I mean when I say you’re not critical of your own code. When I type up a function, I immediately test it by tracing the output it provides for every single special case, as well as for a general case for which I know what the answer should be. Had you done that, you would _never_ have left this monstrosity standing.

> Edit: BobJanova, using cross-products and asin only works if the angle between the two vectors is in the [-90;90] degree range. In order to get the full angle you still need the dot product (its sign really) to determine the actual angle modulo 360 degrees.
A fair point, although at least it degrades gracefully in that it turns you in the right direction for any target except one directly behind you. Most tracking algorithms assume that you’re pointing in roughly the right direction already so you can usually ignore this. But you’re absolutely right to point it out.
And regarding the triple post (ccccombo breaker :D): I have a unit testing framework, and that really helps. I post-hoc added tests for my collision detection/resolution code recently and I’ve found three bugs so far … and I’m a professional programmer for the day job, I’m probably making less dumb mistakes than most people.

Yes, the elapsedTime is measured in seconds as I assumed you would be smart enough to understand. If it had been turning like some kind of epileptic demon then of course I would not have let that stand. Furthermore, if these functions were “monstrosities” then I would be back here, as you say by being “not critical of my own code,” asking why the functions like AngleBetween didn’t work. It does work because I use Vector2 in place of Point so imagine the vectors you mentioned as points on a graph. The angle from the first (3,3) to second (5,5) is quite clearly 45 degrees. Unless you transformed the axis so that the x axis is along the line formed between (3,3) to (5,5) then I don’t see how it could be 0 or PI. The AngleBetween is meant to find the angle between the vectors relative to a normal system. However, I realize I did not take the Cross product solution seriously, and I’m sorry for that, but you seem to have already pointed out the flaw in using that method.

> *Originally posted by **[Arloistale](/forums/4/topics/319443#posts-6731731):***
>
> Yes, the elapsedTime is measured in seconds as I assumed you would be smart enough to understand.
why would we know it’s in seconds? it could be milliseconds or nanoseconds, days, hours, minutes or even tens of billions of years
also, your algorithm is absurdly slow: it looks like you’re intentionally choosing the slowest way possible to write code, then screwing over anyone with an older computer by using time-based physics instead of frame-based (equal to assuming the time between frames is always 33ms). do you work for zynga? they make things absurdly slow too

> *Originally posted by **[BobJanova](/forums/4/topics/319443?page=1#posts-6731532):***
>
> at least it degrades gracefully in that it turns you in the right direction for any target except one directly behind you.
True that. One thing neither of us pointed out that still bears saying, is that using the cross product also removes the need to keep track of the right-hand-side direction that the OP needed (the ‘right’ variable.) And that’s icing on the sign-tracking cake.
So, OP, does it work finally, or is it still bugged?
Edit: “asking why the functions like AngleBetween didn’t work. It does work because I use Vector2 in place of Point so imagine the vectors you mentioned as points on a graph.”
That’s _not_ what your own comments say:
`
* Calculates the angle, in radians, between two vectors.
* @param vector1 The first vector.
* @param vector2 The second vector.
* @return The angle between the two vectors.
`
I’m not going to go off on a rant about the pointlessness of comments but, if I was, I’d use these as textbook examples. Still, if you’ve written them, at least stand by them.

Skyboy, if this method is absurdly slow, then what is a faster method? Cos / sin calculations? I used time based movement for better accuracy, since I’ve found frames to be very inaccurate. I don’t understand why you are giving me criticism without telling me why it should be criticized…

To keep it simple:
If you use frames and the game lags, everything lags the same, including the frame-based timer and all calculations based on that.
If you use timers like that, everything gets screwed because of the difference between elapsed time and actual “game time”.
[http://www.fastswf.com/YLYkQqI](http://www.fastswf.com/YLYkQqI)
Click on it and press space to start causing lag. Give it a while and look at the Frame/Timer difference to see how lag can impact timer based logic.

But isn’t using elapsedTime supposed to solve this kind of problem where timing is inaccurate because of lag? What is the best way to stay consistent then? Using frame based in the past always made timing inaccurate

> *Originally posted by **[Arloistale](/forums/4/topics/319443#posts-6732563):***
>
> But isn’t using elapsedTime supposed to solve this kind of problem where timing is inaccurate because of lag? What is the best way to stay consistent then? Using frame based in the past always made timing inaccurate
inaccurate against real time, yes; but if your game requires active input (it’s not turn-based) then lag will cause things to move faster with less reaction time: input only occurs once per frame.
> *Originally posted by **[Arloistale](/forums/4/topics/319443#posts-6732464):***
>
> Skyboy, if this method is absurdly slow, then what is a faster method? Cos / sin calculations? I used time based movement for better accuracy, since I’ve found frames to be very inaccurate. I don’t understand why you are giving me criticism without telling me why it should be criticized…
instead of even using your vector class at all, inline everything and use a regular point: Math. is slow because it’s a static call; hiding that behind _another_ static call doubles your overhead. creating new objects all other place you don’t use consumes substantial time, hiding a fast operation (like subtraction) behind a function call and a static look up is one of the worst slowdowns: well over 30x slower. Point itself isn’t too fast either because x/y are getters. there are a dozen other things in the code you’ve posted

Frames aren’t perfect, but in this case, a frame based logic would be way more reliable.
You can throw a `getTimer()` in your main logic loop and do something to compensate for any lag, but to be honest, a standard ENTER\_FRAME listener will do just fine.
Yes, frames aren’t the best to keep rack of actual time, but that’s irrelevant when the alternative is to totally screw gameplay for people with slow machines.
As an example, I remember playing a game where levels were timed. I have an old desktop computer and the timer bar used to be half depleted by the time the intro animation was over, because the game used a timer instead of frames. No need to say it was totally unplayable for me and many others.