Actually, it is pretty simple, if you take a closer look at the equations and forget about wait(1) as tool for the timing.

The actor has a certain speed which you apply in the inside view each frame by adding/subtracting speed * time_step. Since a tick is a 1/16th of a second (16 ticks = 1 second), and time_step is just the inverse of the passed time since last frame in ticks, "speed" is actually the distance walked by the actor in 1/16th of a second, no matter what fps you have. E.g. if speed is = 5, the actor walks 5 * 16 = 80 quants in one second.

Now, consider the following: if the distance between the actor and the destination is distance = abs(my.y - destination.y), the actor has to walk "distance" quants to reach the next tile. If "speed" describes how much quants he walks in one tick, "distance" : "speed" equals the number of ticks the walk consumes; divided by 16 you have the number of seconds you have to wait. Here a bit code to demonstrate this:

Code:
var speed = 5; // walked quants per ticks
var distance = absv(my.y - destination.y); // walking distance in quants
var waitTicks = distance / speed; // ticks to wait for walk
var waitSecs = waitTicks / 16; // seconds to wait for walk


So, when and how do you trigger the tile change? Well, I would calculate 1) the walking time and 2) the walking destination in two fields per actor. Then, in a loop with wait(1) statement, I would iterate over all outside view actors and count the walking time down by time_step, thus the walking time field means actually the -remaining- walking time. If the walking time counter is 0 or less, the actor has reached the walking destination - in that case you do the change.

Last edited by HeelX; 06/10/12 22:22.