Args:
NewLoc: The new location.
Dir: The direction of movement (or 0).
step_x: The new step_x value, relative to NewLoc
step_y: The new step_y value, relative to NewLoc
Note that NewLoc is a required argument - you cannot call Move() without supplying a new location. Consider that you want to move in an arbitrary direction without changing the mob's direction. If you were moving a whole tile, you'd do this: mob.Move(NewLoc, mob.dir). How do you do this if you only want to move an arbitrary number of tiles?:
mob
proc/push(push_direction, push_distance)
var/push_x = 0
var/push_y = 0
switch(push_direction)
if(NORTH ){ push_y = push_distance}
if(WEST ){ push_x = push_distance}
if(NORTHWEST){ push_x = push_distance; push_y = push_distance}
Move(????, dir, push_x, push_y)
See the problem? What do you put in place of ???? in the above example? Don't say "mob.loc", because that isn't always true. Just try it and you'll see why (you'll be unable to be pushed outside of your current turf). We could do a ton of calculations to determine exactly where we're moving to... but then why are we using the built in system, anyway? Does anyone know if an easy way to do this exists?
[Hint: it's not the step() or walk() procs. If you read carefully, you'll see that the I need to do this without changing the mob's direction to that of the movement, which is impossible with step or walk. No, I can't just change the mob's direction immediately after movement, as this interrupts the gliding animation when moving in whole tile amounts.]
That's all there is to it. That won't change the mob's direction.
The final lcc where the mob ends up may not in fact be the loc you supplied due to the step offsets. The Move() proc will always try to "normalize" the loc and step offsets so that you don't end up with wacky offsets like -128. But this normalization process isn't really relevant to your example.