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..?
ID:2061483
 Mar 29 2016, 12:26 pm
|
|
|
Mar 29 2016, 2:30 pm
|
|
GreatPirateEra
 |
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
|
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() | |
Rotem12 wrote:
You can try to use get_step_to() instead. Same difference; the same pathfinding code is used for both. | |