now consider an object at the far end of a parallel lane, and a vehicle driving to that object.

Once the vehicle arrives at the object, it should travel around the half circle, say, to an object located at the end of the half circle, to then continue on the other parallel path in the opposite direction.

It appears that the orbit behavior doesn't work for this because once activated it repositions the vehicle, arbitrarily, to a new position on the circle (South-East) while, i need to continue moving the vehicle smoothly into the half circle.

Is there a way to solve it.

thanks,

Dan

p.s. i programmed my own circle routine, but its very cumbersome to use -- for example, it repositions the x/y of the vehicle at every tick -- if i want to adjust the speed, then i have to work with second rations per tick, and "calibrate" these to fit with speed settings typically elsewhere.

If there is a predefined solution that would be great.

You are looking at it the wrong way. Use car behavior

Then create a sprite ( just a simple colored rectangle ) with an instance variable called position ( or whatever ), copy it maybe 10 times and place around the track

set instance variable of each sprite 0-10.

Give your car instance var called position too. set it to 0

Then use events to set angle of your car toward sprite with instance variable position that matches same named instance variable of the car which will be 0, and simulate car behavior accleration

once it reaches that one add 1 to car's instance variable, so now the car will turn towards the sprite with position variable 1, and so on.

That is the general idea, then tweak to make it nicer

I think this is a great work-around, and i will try it.

However, once aspect of the problem i didn't mention is that the radius and hence path is dependent on the type of vehicle and it can be arbitrarily set by the player.

So, the actual radius is not predefined -- the only thing that is predefined is the location of the center -- however, also these could be changed by the user in the future -- i.e. user configured track.

So, i could still generate those guide instances -- but, best if i could do the real thing -- get orbit to work via any entry point, center and radius

One idea is to find the closest point on the line segment between the two centers from the car. Then move a radius distance from that point.

Here's it in one event. Change the radius and speed instance variables as needed. The long formula is just a vector projection in case you were curious where it came from.

Well the bulk of it is a vector projection, so reading a tutorial on vector math may be useful.

This equation sets t to a normalized vector projection of p onto the line between the two centers.

t = clamp(((p.x-c0.x)*(c1.x-c0.x)+(p.y-c0.y)*(c1.y-c0.y))/((c1.x-c0.x)^2+(c1.y-c0.y)^2),0,1)

Combined with:

targetx = lerp(c0.X,c1.X,t)

targety = lerp(c0.y,c1.y,t)

you end up with the point closest to object p on the line segment between c0 and c1.

If you could do vector math directly in construct it could look like this:

A = p-c0 // vector from c0 to p
B = c1-c0 // vector from c0 to c1
t = (A dot B)/length(B)^2 // normalized vector probjection
t = clamp(t, 0, 1) // limit to the line segment
closetPoint = c0 + B*t // get point by lerping between c0 and c1 by t

So anyways, you get a point between c0 and c1 close to p.

Next it moves p toward that point so it's exactly a 'radius' away.

Then it turns p left 90 degrees and moves forward at "speed" pixels per second.

Honestly it's just a bunch of simple things put together. I usually draw a picture as i go coming up with these things. Then i simplify the math as much as possible.

You could google things like "vector projection" and "point closest to a line segment" to find more info about the math.

The construct specific stuff:

clamp(value, low, high) limits a value to be between a low and high value

lerp(a, b, t) moves a percentage from a to b by t. Where t is between 0 and 1.

I am looking to analyze how exactly it works -- and why, when orbit is enabled, it doesn't arbitrarily displace the sprite, but keeps it going on the right path / (tangential) turn around the edge.

How would you extend this solution to have a road coming into the track, where, for the first time, the sprite travels down the road to the track, does a first full "hello" round, and then continues on around the track,as its now.

I am curious if orbit can be configured for such an initial behavior as well, in particular, when the incoming road could have any kind of angle.

Yes, I think it's possible. I would probably do this with invisible marker sprites, green blocks on the picture below.

Define a bunch of instance variables on markers, to store parameters of the next corner - circle radius, orbit target (circle center), orbit offset, orbit distance.

Move the car to the first marker. When arrived, set orbit parameters from the instance variables. After the car orbited a specified number of degrees, move to the next marker and repeat.

But for a complex track it may be easier to use some other method, like building the path with waypoints.

Honestly it's just a bunch of simple things put together. I usually draw a >picture as i go coming up with these things. Then i simplify the math as much >as possible

Simple for you :-)

I feel like i am only getting to see the projected vector, and not the original one, and why projecting a vector is in fact a solution for identifying the path over time.

Also the 90 degree turn that happens every tick is completely opaque to me -- there is no turning happening visually -- and interesting, when i set it to -90 the movement is reversed! -- holy cow -- how did that happen :-)

I also like to work things out by drawing the out geometrically in powerpoint -- but, my trig. is rusty, and now, apparently, i need to get into vec again -- which is even more rusty :-)

Looks like what i am missing here is the (formal) math of animation ...

I can now see how great this math has been packaged into sprite behaviors -- making the accessible with limited such math knowledge ...

Dan

Well the bulk of it is a vector projection, so reading a tutorial on vector math may be useful.

This equation sets t to a normalized vector projection of p onto the line between the two centers.

t = clamp(((p.x-c0.x)*(c1.x-c0.x)+(p.y-c0.y)*(c1.y-c0.y))/((c1.x-c0.x)^2+(c1.y-c0.y)^2),0,1)

Combined with:

targetx = lerp(c0.X,c1.X,t)

targety = lerp(c0.y,c1.y,t)

you end up with the point closest to object p on the line segment between c0 and c1.

If you could do vector math directly in construct it could look like this:

A = p-c0 // vector from c0 to p
B = c1-c0 // vector from c0 to c1
t = (A dot B)/length(B)^2 // normalized vector probjection
t = clamp(t, 0, 1) // limit to the line segment
closetPoint = c0 + B*t // get point by lerping between c0 and c1 by t

So anyways, you get a point between c0 and c1 close to p.

Next it moves p toward that point so it's exactly a 'radius' away.

Then it turns p left 90 degrees and moves forward at "speed" pixels per second.

Honestly it's just a bunch of simple things put together. I usually draw a picture as i go coming up with these things. Then i simplify the math as much as possible.

You could google things like "vector projection" and "point closest to a line segment" to find more info about the math.

The construct specific stuff:

clamp(value, low, high) limits a value to be between a low and high value

lerp(a, b, t) moves a percentage from a to b by t. Where t is between 0 and 1.