"move to" at high speeds, often not stopping

Sparkyidr

Just been messing around with an actor that controls the camera, and some move to behaviours that happen when an attribute is set.
I have a scene, 3 screens wide, and have an actor sitting in the middle of the middle screen.
I then have 2 buttons for left, and right, when I press left, it sets an attribute "game.started" to 1, if I click the right, it sets it to 2. I then have an exit button on each screen, which sets the attribute to 0.

When it's 0, I tell the actor to move to the centre of the middle scrren, 1 for the left, and 2 for the right

When I have the move to speed set reletively low, like 100-300, it seems to work fine.
If I set it to 500, it starts to get a bit flakey, sometimes just not stopping, but maybe 70% working ok.

If I get silly and set the speed to something like 2000, it pretty much just fails every time (

I have tried adding to the rules something like :
when self position x = 140 set linear x to 0....but didn't help.

Anyone tried something similar?

rebump

All I know is that "Move To" is hit-or-miss on a lot of its uses...which makes rebump sad for a few of his game ideas.

QuinnZoneStudios

I created a mad title page with fast "Move To's" all over the place. Yeah sometimes they wouldn't stop and kept going. Testing on the iPhone the whole game collapsed so I had to ditch it lol!

firemaplegames

Updating Stunt Squirrels from v. 070 to 0.83 broke the MoveTos I was using to control the preview camera. I now have to couple the moveTo with an overlaps or collides Rule.

Is there a target Actor you can test for?

Sparkyidr

I have tried sticking an actor around where I want the camera controller to stop, and adding a set linear x to 0 on it. and again, it's really flakey at higher speeds. (

Tbone

I too have experienced this. But I've found it to be hit and miss at any speeds. Sometimes the actors just keep on going.

Sparkyidr

weird... have just added an actor called "stopper" and then said that when my camera move actor overlaps stopper, set the linear-x to 0... I'm then displaying the linear x as txt on the actor to keep check.....and it doesn't change to 0...no matter what speed my moveto command is at.

pretty frustrating

Sparkyidr

ignore that.. I was using move on the example above, rather than move to..... but still, it should set the speed to 0 right?

ORBZ

try using integers or the floor function, i think what happens is that when it moves it moves by fractional values so when it says move to x, suppose x is 3.53 and y is 2.71 yet the actor moves at 1.0 pixels per second. it will always miss.

yet if you tell it to move to floor(x) and floor(y) it should have better odds of hitting the target.

i have messed with this some and this is the best reasoning i could come up with.

basically though the moveTo behavior is broken and you shouldn't need to hack it like this.

btw, no guarantee this will work.

Sparkyidr

thanks guys.
you are right Orbz, it's defo a some kind of timing issue.
on a related note, it seems to be working "most/all" of the time with the speed set to the default 300!

)

Will give the floor x floor y thing a go tomorrow. Thanks for that.

gregr209

I also had to abandon a game due to problems with the 'Move To' behavior. It has been very frustrating. Keep us posted if you come up with another way to use 'Move To'.

JGary321

Yea, I had some nice menu effects using move-to. All the menu's would slide into place. Had to remove it =(

Sparkyidr

more to report. I thought I would try to add a rule, so that when the camera move actor got to where I wanted (or less than that x value) I would add a "linear velocity = 0"...but what it actually does is very different.

Here is what happens :
The camera move actor gets to x=140...that's where I want it to stop.
So I say When self.position.x <or=140 set linear velocity to 0

In theory, if it overshoots the 140 x value, it should stop

When I set the move to speed to say 1000, what actually happens, is at or less than 140, it sets the x velocity to MINUS 1000, so the actor shoots off in the opposite direction.

Seems like a fairly unexpected result.

rebump

The X/Y velocities are directional...as Sparkydir just discovered. "abs()" will clean it up if you don't want to test for a specific direction or both directions (depending on the case).

Tangently related, if you want the overall velocity/speed of the actor, use the velocity X and velocity Y values of an actor for the "x" and "y" values of the "magnitude(x,y)" function.