I just did that work around and, by switching to the horizontally flipped frame, the vehcile doesnt change direction due to negative speed -- however, the frame change is felt visually -- so its not an optimal solution.

Looks like when i enter speed as negative and activate match rotation, then the sprite is turned around -- i.e. the vehicle now drives around in reverse.

I think this is a side effect of working around the counter clockwise with negative speed.

Better, if orbit has a dedicated boolean to specify circling direction -- clockwise or counter clockwise -- so that one doesnt need to rely on negative speed.

I guess one work around is to create two opposite frames -- and upon entering the circle with negative speed switch to the other frame.

hopefully in the future orbit will get real booleans to specify direction

Yes -- it was overwritten by the code -- i thought it only works clockwise.

hmm, i tried that but it didnt work .. perhaps it was overwritten in the code

Is there a way to make orbit work counter clockwise?

Noticed this pixar video on linear interpolation:

khanacademy.org/computing/pixar/animate/ball/v/a2-quick

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.

Your "interpolation" solution is incredible -- i am looking at it, and it works, and i can't make sense out of it, including when reading the manual.

Is there some math sites you can reference where i can read up on the underlying math ...

Also, how does this work to create the straight move behavior and then the curved one as well.

Thanks.

I will review your suggestion carefully.

The easiest would be if Scirra adds one feature into orbit -- to indicate at what location on the circumference the orbiting sprite starts its orbit.

I asked if they are willing to add this feature -- hopefully, they will say yes.

Thank you for the suggestion.

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

Hello,

Consider a race track that has two parallel lanes and then a semi circle on each side.

Something like this: gettingoutofthegate.com/wp-content/uploads/2013/04/Saratoga-Main-Track.jpg, but for vehicles.

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.

around the center of the half circle