For everyone having problems with the "Move To" behavior
MarkOnTheIron
Member Posts: 1,447
Hi,
I read in many posts that the only way to solve it is by using the Interpolate behavior. The problem is that it's not always a possible solution.
For example in a scene I'm building I have four actors with a rule to generate a random position and then a Move To behavior to make them go to that position. However it only works for a little while and after some times the actors begin to go offscreen to uncharted positions.
Interpolate is not an option there because I want the actors to move at a fixed speed and by using Interpolate the actor would take the same amount of time for a 10 px movement and a 900 px one.
A workaround I found is by using the Change Velocity behavior. Here's what I did:
- On the actor I want to move after the random position generator rule (it generate a NewX and NewY number) I put a Change velocity and as a direction I used vectortoangle(NewX-self.PositionX, NewY-self.PositionY).
-To make the actor to stop I put a rule when ALL Attribute self.PositionX>NewX-5, Attribute self.PositionX<NewX+5, Attribute self.PositionY>NewY-5, Attribute self.PositionY<NewY+5 with a Change Velocity to 0 speed (but you can also use a Change Attribute for Motion Linear x and Y).
The last rule I used is to "create" a virtual square to trigger the last behavior. That is needed because apparently the angle at which the actor moves make it pass to strange positions (ie. 320,032 instead of 320).
I hope that someone could use that information. For me it's working until now without problems.
I read in many posts that the only way to solve it is by using the Interpolate behavior. The problem is that it's not always a possible solution.
For example in a scene I'm building I have four actors with a rule to generate a random position and then a Move To behavior to make them go to that position. However it only works for a little while and after some times the actors begin to go offscreen to uncharted positions.
Interpolate is not an option there because I want the actors to move at a fixed speed and by using Interpolate the actor would take the same amount of time for a 10 px movement and a 900 px one.
A workaround I found is by using the Change Velocity behavior. Here's what I did:
- On the actor I want to move after the random position generator rule (it generate a NewX and NewY number) I put a Change velocity and as a direction I used vectortoangle(NewX-self.PositionX, NewY-self.PositionY).
-To make the actor to stop I put a rule when ALL Attribute self.PositionX>NewX-5, Attribute self.PositionX<NewX+5, Attribute self.PositionY>NewY-5, Attribute self.PositionY<NewY+5 with a Change Velocity to 0 speed (but you can also use a Change Attribute for Motion Linear x and Y).
The last rule I used is to "create" a virtual square to trigger the last behavior. That is needed because apparently the angle at which the actor moves make it pass to strange positions (ie. 320,032 instead of 320).
I hope that someone could use that information. For me it's working until now without problems.
Comments
I'm now 14hours into the project, and, I don't think I will change it. I think "move to" only f*cks up when used with random. I only needed to change X to "rand(200,280)". But instead I used 240, and, it is not a really big difference. But, I'm sure someone will be grateful for your post.
And you can use interpolate too for what you did I think. You just need to come up with a complicated math rule for the time frame of interpolate behavior
Thank you again..
Edit: I noticed that I really can not use anything else. I need to use "move to" behavior. Nothing else works. I will post a video of my new game, so anyone can see. I'm doing something different..
I think one could also work on the Motion Linear X and Y attributes but I prefer the Change Velocity.
I hope they will fix this bug soon.