Possible to use the "Move" behaviour to move in a circle?

Tiny_Ideas

Hello all,

Rather than constraining the rotation, and x and y positions of an actor to sine and cos to make them to in a circle. Is there a way to use the "Move" behaviour to do this?

I need to be able to change the speed of the actor. Either stop, normal, or fast.
Currently I am using the move behaviour, setting it straight relative to the actor and having a rotate clockwise rule at a speed that I found through trial and error that would work to do a circle. However, after stopping and starting, the actor finds it self off the orginal track a fraction every time and is no longer doing the correct circle. Either shifts up or down, left or right by at least 20 pixels.

To change the speed I simple tap the actor. It goes from stop to speed of 50, tap again it goes to speed of 250, tap again it stops.
Any ideas to keep it at a perfect circle and still be able to change the speed.?

Socks

Hello all,

Rather than constraining the rotation, and x and y positions of an actor to sine and cos to make them to in a circle. Is there a way to use the "Move" behaviour to do this?

Sure, just make the direction an ever increasing (or decreasing) value, use whatever you want to change this value (self.time, game.time, make it an attribute and then interpolate this attribute's value . . . . etc etc)

I need to be able to change the speed of the actor. Either stop, normal, or fast.

That's much easier to do with sin and cos, all you have to do is change the speed of the angle that sin and cos are operating on . . . lots of people use a built in clock like game.time or self.time, with these you'd simply multiply them by a value, big values = fast, small values = slow.

You can do this with move, although it's a little more tricky, with my above example of using an ever changing direction to make Move go in a circle - if you were to increase the speed you would just get a bigger circle, if you slow the speed down you get a smaller circle - what you have to do is to compensate the increase (or decrease) in the speed value by an increase (or decrease) in the rate the direction is changing, not mind-bendingly difficult by any means but not as straightforward as using sin and cos.

Currently I am using the move behaviour, setting it straight relative to the actor and having a rotate clockwise rule at a speed that I found through trial and error that would work to do a circle. However, after stopping and starting, the actor finds it self off the orginal track a fraction every time and is no longer doing the correct circle. Either shifts up or down, left or right by at least 20 pixels.?

That's the wonder of sin and cos driven by game.time, the physical locations can never stray, it's always absolute, as is the speed/time.

Any ideas to keep it at a perfect circle and still be able to change the speed.?

Sin and cos locked to game.time or self.time !!

Tiny_Ideas

@Socks

I am very impressed by your responses, nice layout and information.
Currently setting up sine and cos function now, will see if it works as I am hoping it will.
Thank you

Tiny_Ideas

@Socks, right, came across an issue.

The actor is travelling straight at 45 angle. After a timer or 1 second, it is triggered to then constrain to go into a circle, however it jumps to the right hand side of the circle and continues from there doing a circle. It doesn't start from its current position/ rotation. Would this involve an extra function, taking into consideration its current rotation and position?

Socks

@Socks, right, came across an issue.

The actor is travelling straight at 45 angle. After a timer or 1 second, it is triggered to then constrain to go into a circle, however it jumps to the right hand side of the circle and continues from there doing a circle. It doesn't start from its current position/ rotation. Would this involve an extra function, taking into consideration its current rotation and position?

Without knowing how you have the circle constrain set up it's hard to diagnose.

Typically a circle might be driven by two constrains that are using self.time or game.time as their angle (which means the angle is always increasing - which is what you want if you want something moving in a circle).

Again, as I don't know how you have your project set up I will have to make some guesses, if you are using self.time as the angle - and the circle constrain is triggered after 1 second then self.time is 1 (self and game time are measured in seconds) - which means the angle of the circle constrain is 1° - which is, visually, as good as 0° - which is the three o'clock position on a clock - so I'd expect the circular path to start on the right - although if you are multiplying the self.time value by some other value (to speed it up) this might all be wrong as the multiplier would need to be 360 (or 720 or 1080 . . . etc) to end up on the right after 1 second.

You don't really need any extra functions, you just need to stick in an offset (on the angle) that takes into account where your actor is. I think I've made it sound more complicated than it actually is, basically the circular path needs to start where your actor is and not some arbitrary angle defined by whatever you are using to sweep through the angle.

Here's where the offset goes . . .

Radius*sin(angle*speedmultiplier+offset)+centre

So, a 200 pixel radius circle in the middle of an iPad screen, moving at 112° a second - but starting at 67° (rather than 0°)

constrain x to 200*cos((self.time*112)+67)+512
constrain y to 200*sin((self.time*112)+67)+384

RThurman

@Socks -- I am sure @Jeromy will figure this out pretty quick. But for the sake of the other unseen thousands who will look at this thread later , they will need to know how to calculate the angle offset. They will need the offset in order to start the circle movement at the actor's exact angle from the center of the circle. Because the actor's place on the circle may vary each time it is started, this offset will need to change each time the actor is sent in a circular pattern. So... how can they derive the 67 degrees in the above example?

Socks

@RThurman

@Socks -- I am sure @Jeromy will figure this out pretty quick. But for the sake of the other unseen thousands** who will look at this thread later , they will need to know how to calculate the angle offset. They will need the offset in order to start the circle movement at the actor's exact angle from the center of the circle. Because the actor's place on the circle may vary each time it is started, this offset will need to change each time the actor is sent in a circular pattern. So... how can they derive the 67 degrees in the above example?

(**me, you and Jeromy ?)

Good point (I take it your question is rhetorical), you calculate the 67° (or whatever the value needed is) by using good ol' vector to angle on the actor . . .

vectorToAngle(self position X - position X of the centre of the circle, self position Y - position Y of the centre of the circle).

There's some guess work here as I don't know how the moving actor interacts with the circular path, does it cross it and then enter the circular path, or does the circular path form wherever the actor is on screen - if so how is its centre point chosen ? (etc etc), so all this is just a rough guide.

Tiny_Ideas

@socks

Well I spent last nigh figuring it out in my own, better to learn than to be shown.

Here is what I wanted,

An actor travelling at a speed at angle 45 angle. Once it goes a certain distance, it must than start moving in a circle, continuing on from its orginal angle.

Here's what I did,

Made an actor move in direction of 45 angle, when reach certain certain x and y points, change move circle to TRUE.
When move circle is TRUE
Constrain x to ..............
Constrain y to ...........
Constrain angle to ............

I added in the offset angle because its only moving in a straight line before hand.


Here the issue,

The actors self.time has already increased by the time it reaches the x and y points. Which means when it starts its circular movement, it jumps to a different area of the circle rather than where it is now.
To try an pd fix this I made a attribute which recorded the self.time when it was time to start moving in a circle, and then just subtracted it from the self.time so it started at zero again. However this sort of works, expect now it isn't smooth transition. It moves back a bit a long the circle a bit, and each time I test in device it ranges from a small jump to a large jump in positioning.

Any ideas?

Socks

@socks

Well I spent last nigh figuring it out in my own, better to learn than to be shown.

Yep, always good to get your hands dirty !

An actor travelling at a speed at angle 45 angle. Once it goes a certain distance, it must than start moving in a circle, continuing on from its orginal angle.

Still not 100% what I am looking at here . . . . . ?

45° only tells us the angle of travel, not the direction - it could be going from the lower left to the upper right . . . . or from the upper right to the lower left . . . . also 45° in common parlance can often mean 45°, 135°, 225° and 315° (basically it is interchangeable with 'diagonal') . . . etc etc etc . . .

And when it gets to a certain distance and then starts to move in a circle, where is the centre of the circle ? For example the description could describe a clock face where an actor starts from the centre of the clock heading up and to the right - and when it hits the edge it starts moving counter clockwise . . . . or it could mean a few other things . . . etc etc

I know it sounds like I am being a pedant (I am a pedant ), but these things matter, if you could hammer them down then the number will fall into place.

The actors self.time has already increased by the time it reaches the x and y points. Which means when it starts its circular movement, it jumps to a different area of the circle rather than where it is now.

The offset should accommodate this, the offset is thrown onto the angle (which you are using self.time to represent), with an offset you can start the circle wherever you want.

Any ideas?

Like I say, the problem is probably really basic, really straightforward, the real work is always trying to imagine what it is you are looking at on your monitor.

Socks

Here's what I imagine you want:



or it could be this:



Or this:

or a few other things . . . etc etc

Tiny_Ideas

@socks

This is exactly it, I was in the middle of setting up Dropbox so I could share an image.

The actor is travelling in a diagonal direction, as seen, when it reaches the 135 degree it needs to move in a circle. Following that red line.


Another issue, which may not be an issue if I can the movement to work, is when I make it stop, by changing the speed to zero, it jumps to a another angle of the circle.


Thanks

Socks

Another issue, which may not be an issue if I can [get] the movement to work, is when I make it stop, by changing the speed to zero, it jumps to a another angle of the circle.

Of course ! It should jump to the three o'clock position (using a clock as a visual reference) - as this is 0º.

Socks

@Jeromy

Here's a demo file, it shows the basic idea . . .

If you click anywhere on the screen the actor stops dead . . .

online backup

Tiny_Ideas

@Socks

Great, will check it out now, you been very helpful. Thank you.
Hopefully after a bit of trial and error or googling, i can come up with how to make it start again once it has stopped.

Tiny_Ideas

Tested my add on to the demo on a device, saw it jump, so I went and tested your demo alone on device and it still jumped. Not a smooth transition.

This got me thinking, is there a more actuate way to just change the rotation of an actor and apply the move behaviour. If if the actor is moving up relative to it rotation. Simply changing the rotation should make it rotated in a perfect circle. However it doesn't.

I even tried just moving ups and constraining the rotation to the its own position and the centre point position and it slowly just went further away from the centre point every orbit.

Unless I need to look back and refine the function for constrains.....?

Socks

. . . so I went and tested your demo alone on device and it still jumped. Not a smooth transition.

Works fine for me.

Tiny_Ideas

Yeah I can get it to work correct like 1 out of 6 times. So not sure whats going on here. Further more,
I also looked a bit into it and it really isn't that effective, to make it stop, spawning and destroying isn't an option. Changing speeds and continuing on won't work.

Which is my I can't thank you enough for the time and demos, but constraining a circle doesn't work.



Currently I am looking for a another way, almost as perfect without constraints, like using move. Behaviour or the rotate behaviour.

Hello all,

Rather than constraining the rotation, and x and y positions of an actor to sine and cos to make them to in a circle. Is there a way to use the "Move" behaviour to do this?

Sure, just make the direction an ever increasing (or decreasing) value, use whatever you want to change this value (self.time, game.time, make it an attribute and then interpolate this attribute's value . . . . etc etc)

I need to be able to change the speed of the actor. Either stop, normal, or fast.

That's much easier to do with sin and cos, all you have to do is change the speed of the angle that sin and cos are operating on . . . lots of people use a built in clock like game.time or self.time, with these you'd simply multiply them by a value, big values = fast, small values = slow.

You can do this with move, although it's a little more tricky, with my above example of using an ever changing direction to make Move go in a circle - if you were to increase the speed you would just get a bigger circle, if you slow the speed down you get a smaller circle - what you have to do is to compensate the increase (or decrease) in the speed value by an increase (or decrease) in the rate the direction is changing, not mind-bendingly difficult by any means but not as straightforward as using sin and cos.

Currently I am using the move behaviour, setting it straight relative to the actor and having a rotate clockwise rule at a speed that I found through trial and error that would work to do a circle. However, after stopping and starting, the actor finds it self off the orginal track a fraction every time and is no longer doing the correct circle. Either shifts up or down, left or right by at least 20 pixels.?

That's the wonder of sin and cos driven by game.time, the physical locations can never stray, it's always absolute, as is the speed/time.

Any ideas to keep it at a perfect circle and still be able to change the speed.?

Sin and cos locked to game.time or self.time !!

I am not really seeing how it is easier to stop it using sin and cos. Unless I am missing something, I guess I am back to sqaure one.

Socks

. . . it really isn't that effective, to make it stop, spawning and destroying isn't an option. Changing speeds and continuing on won't work.

I just threw the spawn / destroy in there, you don't have to use it, there are numerous other ways, it was just a quick and convenient way to stop something.

I'm not sure why you think changing speeds or continuing on won't work (you don't say why) ?

I am not really seeing how it is easier to stop it using sin and cos. Unless I am missing something, I guess I am back to sqaure one.

It's trivial to stop something being moved by sin or cos, sin and cos operate on an angle (the thing in the brackets - more often than not self.time/game.time), if the value in the brackets, that's to say the angle, stops changing, the object stops moving, it's about as straightforward as you can get, if you have a variable that is increasing or decreasing ('sweeping' the angle) then stoping/pausing that changing value stops the object from moving, there are numerous simple ways to make this value static, it's just a number, change it and the object moves, keep it static and the object stops.

Anyhow, I think I've said enough to confuse you for one day ! I hope you sort something out that works for you.

Tiny_Ideas

@socks

Maybe it might be how i am doing it then. The reason why i can't get it to start stop, is that is running on self.time. I can stop it, but the self.time still continue on so when i start it again using self.time its angle has changed, hence it will change location.

I have tried things like my own self.time that only increases when i want it, but i couldn't get it to work smooth. However, judging by the fact that i couldn't even get your demo to runs smooth, it might "meant" to be working, but for some reason it wont show up on any viewer.

I am aware of how it works, i just can't get it to work.
Its been three days, non stop trial and error, some work for a bit but then they stutter.
Apologies if i was wrong that using constrains isn't as easy. What is most likely happening is that what is meant to work, isn't working for me.

Tiny_Ideas

On a side note,

If an actor is moving at a speed of 100 and is rotating clockwise at a speed of 50, it does a perfect circle.

But if I have a rule that says after 3 seconds,

Change moving speed to 200 and Change rotational speed to 100, which is exactly double.
It doesn't follow the same circle. It shifts over a few pixels, or down a few, depending on when the change in speeds occur.

Why would this be happening?

Even having it all run of attributes and just change the attribute, instead of using a new Move behaviour, it still doesn't work.
What would be the cause, and is there a way to fix it?
Thank