ID:1989551
 
Problem description:

So I've found, as illustrated below, the in-built walk and step functions count touching the target loc as arriving. As you can see illustrated below





Code:
    var/target = locate(mob.x+2, mob.y+2, mob.z)
walk_to(mob, target)


I expected the mob to end up perfectly within the boundary of 3,3.

Now on investigating the vars, I'm assuming this happens because as soon as the mob overlaps multiple tiles, it has multiple entries in it's loc var. one of these will be the target loc.

The question I have is, is there a simple workaround for ensuring step and walk move to the middle of the tile, or do I have to build my own step/walk functions using step_x and step_y to perform this?
You'll have to semi-build your own. The reason this happens is two-fold, firstly as you said, yes, because of the 'locs' var, the walk_to proc thinks you're already 'on' that tile and halts operations. That's fairly easy to work around, but it gets harder when you remember that step_size will make it relatively difficult to always guarantee you're covering 100% of the area. If you're using a step_size that is a divisor of your world.icon_size, it shouldn't be too hard to manage, otherwise you're going to have to use some trickery with bound_dist on surrounding tiles to step the right amount of pixels.

A very rough rundown of what you need to do in the first scenario is simply walk_to until the desired tile is within your 'locs', and then create a custom centering proc that moves you until your step_x and step_y are equal to zero, but you're still on that loc.

Good luck.
Thankyou for the information rushnut, but as I'd like them to walk in a relatively straight line, I have my own get_dir proc that, instead of making it move diagonally, then horizontally/vertically, will flick between diagonal and horizontal/vertical so the path it follows is linear.

I've decided to move it based on absolute pixel coordinates, from the pixel in the mob's corner closest to the direction it's heading in, and the corresponding pixel on the destination tile.

Was hoping to save some time, but apparently not.

For your information, here's the func I wrote to replace get_dir() in what i consider to be a more sensible way.

I'll be altering this to take into account step_x and step_y as discussed before, so purely for your interest.

proc/fast_dir(mob/S, atom/T)

var/xd = T.x-S.x
var/yd = T.y-S.y

if (yd == 0 && sign(xd) == 1)
return EAST

if (yd == 0 && sign(xd) == -1)
return WEST

if (xd == 0 && sign(yd) == 1)
return NORTH

if (xd == 0 && sign(yd) == -1)
return SOUTH

if (xd == 0 && yd == 0)
return 0


if (sign(xd) == 1 && sign(yd) == 1)
if(xd < yd/2)
return NORTH
else if(yd < xd/2)
return EAST
else
return NORTHEAST


if (sign(xd) == 1 && sign(yd) == -1)
if(xd < abs(yd)/2)
return SOUTH
else if(abs(yd) < xd/2)
return EAST
else
return SOUTHEAST

if (sign(xd) == -1 && sign(yd) == 1)
if(abs(xd) < yd/2)
return NORTH
else if(yd < abs(xd)/2)
return WEST
else
return NORTHWEST


if (sign(xd) == -1 && sign(yd) == -1)
if(abs(xd) < abs(yd)/2)
return SOUTH
else if(abs(yd) < abs(xd)/2)
return WEST
else
return SOUTHWEST
You using xd(elta) and yd(elta) instead of d(elta)x and d(elta)y aboslutely infuriates me. Your programming religion is poo.

Good work though, seems like it'd work pretty well after a brief overlook.
It has a problem, because I was trying to make a lighter version of an old proc. It'll travel NSEW until it reaches an angle divisible by 22.5 degrees, and then perform as expected, so still some work needed.

I'm essentially trying to make a mob step towards a location in a straight line, without slowing the proc down with trig. My older code uses the ratio of the xd and yd to make something move in a linear direction. Looks like I'll be resurrecting that.

xd means x-difference.
yd means y-difference.

The two together create a vector of the T(arget) from the S(ource)

Sure delta x means the same thing. If the "standard" is the other way around then I should get into the habit of that incase I ever feel like collaborating.