ID:2061483
 
Prior to BYOND 490, step_to() used to return 0 if the target was obstructed by obstacles.

However, after 490, using either tile or pixel movement, it seems to in most cases cause the ref to step once towards the target, returning 1 even if the target is surrounded by dense turfs/objs. This causes whatever you didn't want to happen if the ref couldn't reach the target to happen anyway.

Am I incorrect in thinking that step_to() should return 0 if ref can't reach the target due to obstacles? The reference says step_to() will return 0 when failed, and obstacles should cause it to fail..?
That's intended behavior included when pixel movement was added. This is actually documented too. Not sure why you're comparing something from so long ago tho
In response to GreatPirateEra
GreatPirateEra wrote:
That's intended behavior included when pixel movement was added. This is actually documented too. Not sure why you're comparing something from so long ago tho

490 Release Notes
The only thing noting a change is
The step and walk procs have been updated to take a speed argument as well, but default to the mover's step_size.

The step_to() reference was updated to include the additional argument, but other than that nothing about it changed. Is the documentation for this somewhere else..?

Also, disregarding pixel movement for the sake of an argument, wouldn't preserving old behavior of a built-in proc that acts/ed as a sort of "can ref actually reach target?" be something to preserve? Removing that seems like a step backwards.

I'm ignorant on how pixel movement works internally in the engine, so I'm unsure if the change needed to happen or what, but it seems odd to remove such behavior.
I'm not familiar with how step_to() is supposed to work. I agree with your reasoning however; it sounds like incorrect behavior.

Lummox can either pop up here, or you could post a bug report and get a verdict there. The latter usually leads to detailed information on these things.

Best of luck.
Probably what's happening is that because the path is blocked, the pathfinding is bailing out and going with a best-guess try, rather than simply saying "Oh well, there's no path."

The sad part is, pathfinding in pixel movement situations is really a crapshoot. I'm using a modified A* setup, but A* tends to break down outside of tile situations. What it really needs is a navmesh. (Also, it really needs a way to query a whole path so you can call it less often.)
You can try to use get_step_to() instead.

var/turf/t = get_step_to()
if(t)
Move(t)
else
// failed
In response to Rotem12
Rotem12 wrote:
You can try to use get_step_to() instead.

Same difference; the same pathfinding code is used for both.
In response to Rotem12
As Lummox JR said, same difference; I already tried that too. Thanks for the suggestion though.

As a question, Lummox, you said on a bail-out it returns its best guess, would it be detrimental to simply return 0 on a bail-out, or would that cause issues?