step_to is wonking up

ID:1990523
 
Nov 29 2015, 11:00 am
Not a bug
BYOND Version:509
Operating System:Windows 10 Enterprise 64-bit
Web Browser:Chrome 46.0.2490.86
Applies to:Dream Seeker
Status: Not a bug
This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
There seems to be a lot of issues with the pathfinding of step_to that didn't previously exist. See the gif.



Here's a gif of it properly managing to pathfind around that bottom section



Sometimes he pathfinds, sometimes he doesn't. It gets even worse if you use step_size, and it's very inconsistent. step_size 4 seems to be fairly "alright", though it still breaks occasionally, whereas step_size 5 or 1 are almost completely broken always.

Source for reference:
turf
    icon = 'Turf.dmi'
    dense
        density = 1
        icon = 'Turf.dmi'
        icon_state = "Wall"

mob
    icon = 'Icon.dmi'
    //step_size = 5

world
    fps = 30
    view = 8
    mob = /mob/player

mob/player
    density = 0


mob/ai
    var/mob/target = null
    New()
        ..()
        spawn(1)
        //  step_size = 4
            target = locate(/mob/player)
            spawn for()
                step_to(src,target)
                sleep(2)
Nov 29 2015, 1:47 pm
Step_to will eventually bail out, and odd sizes may cause situationx where it bails out sooner, so I'm not sure anything is wrong there. If you have a demo though I can take a look.
Nov 29 2015, 1:50 pm
Better pathfinding ftw que??!?!?
Nov 30 2015, 2:59 am
What I'm saying Lummox is that it's inconsistent even within the same environment. I posted all the code used in the two gifs, and both were recorded within the same session. In the second gif, the block successfully paths around the bottom "leg", this was recorded before the first gif, where he's no longer able to do that for some reason.


Also it'd be nice if we could define the bail out-distance ourselves.
Nov 30 2015, 8:18 am
If anyone's interested, I copy pasted his code and added a similar map for testing

https://dl.dropboxusercontent.com/u/51176364/scratch.zip

It is very consistent, there's nothing inconsistent about it, as soon as you hit a certain range it stops pathfinding and takes partial path towards the target which is more similar to step_towards.

The only thing that would annoy me is that it continues to behave like that even when the target got close enough but it resolves itself soon enough.

As for your request for bail out handling, you already have it, you're just not handling it.
var/success = step_to(src,target)
if(!success) world << "FAILED"


step_to returns 0 or 1 depending on success, that info can be used for such cases, in your example it'll return "FAILED" quite a bit when it fails. I hope this helps, I use something similar a lot.



Nov 30 2015, 8:42 am
Their request for bailout handing is referring to them wanting a way to configure when it bails out, not know if it did.
Nov 30 2015, 10:11 am
The heart of this problem is that A* is limted. For pixel movement it's way less than ideal, but a mesh approach isn't exactly tenable.
Nov 30 2015, 11:30 am
I'm not very good at pathfinding and the general theory behind it, but is it feasible to switch to a different type when you move to pixel movement, which may be more intensive but functionally will allow a similar pathfinding?
Nov 30 2015, 12:18 pm
For objects smaller than one tile, probably a cleaner approach would be to map out a rough tile-by-tile approach and then fine-tune it at the small scale. It's something I haven't looked into because it wouldn't be a quick thing to undertake.
Nov 30 2015, 12:19 pm
Lummox JR resolved issue (Not a bug)