How do I trigonometrizzle this?

Hi,

(edit:) tl;dr: I want to create a position on a circle, found a formula for it, but am not sure what the highlighted part means (below)

Quick context:

My enemies are supposed to circle the player (roughly) when getting within a certain distance of him.

I want to use pathfinding, so I simply want to create a position within said distance and have pf resolve movement.

Now i found this online and it looks just like what i need; but I have trouble reading one particular line.

a = (r02 - r12 + d2 ) / (2d)

h = r0 sinP0 ((or) r1 sinP1)

P2 = P0 + a ( P1 - P0 ) / d

i.e.,

x2 = x0 + a (x1 - x0) / d

y2 = y0 + a (y1 - y0) / d

x3 = x2 ± h ( y1 - y0 ) / d

y3 = y2 ± h ( x1 - x0 ) / d

So this translates nicely to my setup, my only trouble is that black line:

what is "r0 sinP0"?

sinus of a position vector, multiplied by the radius? is that what it's saying? how do i take sinus of a vector?

And while I'm here posting, can anyone suggest a better approach?

I previously achieved this using a bullet behaviour and moving the enemy orthogonally while looking at the player.

But using pathfinding just prevents collision issues with environment better.

Take a look at the line of sight behavior.

Why, does that have some way of providing a position for my enemy to move to that I've been missing so far?

That doesn't make sense. What in particular are you looking to solve with that diagram?

Is P0 the player and P1 the enemy and you want to find p3?

First one is my trying to visualize what I want the resulting behaviour to look like instead of long text.

Second one is what i found online, some bloke determining the intersection point of two circles (P3)

For my situation that translates to:

P0 is the player

P1 is the enemy

r0 being the circling range

r1 being the destination distance

and yes, P3 is what I want to find

https://dl.dropboxusercontent.com/u/542 ... rsect.capx

dist = distance between centers

ang = angle from one center to the other

Then from the first center you move r0 pixels at angle ang+acos((r0^2 -r1^2 +dist^2)/(2*dist*r0)) to get to the left intersection point. You can also use -acos to get the right intersection point.

Why, does that have some way of providing a position for my enemy to move to that I've been missing so far?

That's what it does.

The problem with the pathfinding behavior is that it makes the object turn to the angle of motion before it moves.

So basically you would have to split up a circle, and find a path to each point of the circumference.

That's not hard, but it's incredibly wasteful.

R0J0hound thank you for your example, and thanks for your ongoing patience and support for that matter!

newt I'm aware that I'm losing the circluar route this way, but that's fine.

I don't understand how you think I should use LoS to improve this. Can I get you to point me there?

When the ai has los to the object you trigger an event that creates a point, or points on a circle. There are two ways to do it.

Create a list of points to follow, while its still has los, meaning you have to restart the list at some point.

Or pick a single point on a circle, move it, then find another point of that circle, while it still has los.

It aint pretty:

https://dl.dropboxusercontent.com/u/666 ... kgles.capx

facecrime

You can manually do the math the way your picture shows, or you can let C2 do the work for you.

I whipped up a sample - where I pin circular sprites to the player and enemy and then test for overlapping (these can be set to invisible, but I left them showing so you can see what is happening). Player has 8-direction behavior so you can move him around. Enemy has bullet behavior and always moves towards Player.

It doesn't do any obstacle avoidance - because I have no idea what your layout looks like, but this might give you some ideas to try out.

capx: http://www.rieperts.com/games/forum/RotatingEnemy.capx

newt thanks for your example, helped me a bunch. I originally thought you were using LoS somehow to determine that intersection point, but I do of course also use it to check for range and actual LoS.

but what I was really missing is retrieving that intersection point, and you just casually threw that in there. thanks again, exactly what I need.

AllanR thanks for putting that together, very slick. it's actually close to what I had, but I need to get rid of the bullet behaviour for a few reasons.

Here's what it looked like:

That's of course smoother than what I'll be getting with pathfinding, but that's ok, cos the circular path doesn't matter so much