Calling get_step_to() with a turf as the Ref argument (the starting point) returned null instead of calculating a path. Now it will calculate a path as if Ref was a generic dense mob.
BYOND Version:469
Operating System:Windows XP Pro
Web Browser:Firefox 3.6.3
Applies to:Dream Daemon
Status: Resolved (480)

This issue has been resolved.
Descriptive Problem Summary:
I'm creating a proc that runs get_step_to() multiple times (I'm calling the new proc get_steps_to()), since I haven't found a pathfinding code that I'm comfortable using yet. Whenever I use the get_step_to() (even if it's just once, or if it's in a loop), it returns null, regardless of the arguments I use, or where or how I use it.

Numbered Steps to Reproduce Problem:
1) Assign a variable to get_step_to().
2) 'Debug' the variable (world << variable)
3) Result is null.
Code Snippet (if applicable) to Reproduce Problem:

Expected Results:
Getting a list of all the path from point 'a' to 'b' , using get_step_to() multiple times.
Actual Results:
The proc always returns null.

Does the problem occur:
Every time? Or how often? Always.
In other games? Yes.
In other user accounts? Yes.
On other computers? Yes.

When does the problem NOT occur?
As far as I know, it's always happening.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit to download old versions for testing.)
I can't remember the last time it was working, I don't use this proc too often. It was working in the past, however.

So far, none. Or, at least, no -effective- workaroudn has been found...

I forgot to weigh in on this. I found the issue but I wasn't sure how to resolve it, and no changes are in the 471 build. The issue is that the source cannot be a turf in this proc, even though the reference says otherwise. We may simply update the reference.

If this is for a library of some kind, I strongly recommend you use your own pathing anyway. Calling get_step_to() repeatedly to get the whole path is processor-intensive and won't really serve you that well.

(This isn't really related to issue 1198. 1198 was a compiler problem and it affected a different function.)
As a workaround if the first argument you're passing to get_step_to is a turf you can create an invisible mob on that turf, then pass the mob as an argument.

Built-in search functions should be able to massacre any DM implementation in terms of performance. It would be nice if the built-in functions were more functional.

Calling get_step_to() repeatedly to get the whole path is processor-intensive and won't really serve you that well.

It would also be nice if there was a built-in function that returned a list of turfs along the whole path to avoid that problem. There's already a built-in search routine, it's just a matter of returning a list of tiles instead of just one, but that's probably asking for too much.
I agree a way of returning the whole path would help. The routine that does this actually does calculate a whole path, so that would work fine if we came up with a way to differentiate between the different ways of calling it.

In terms of performance these routines could all be better. step_to() and get_step_to() actually are O(n^3) algorithms instead of a much more efficient A*.