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:
http://www.byond.com/members/Schnitzelnagler/files/ Goosehead_src.zip
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 http://www.byond.com/download/build 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.
Workarounds:
So far, none. Or, at least, no -effective- workaroudn has been found...
</<>
ID:97054
 Jun 17 2010, 7:54 pm
|
|||||||||||||||
Resolved
| |||||||||||||||
|
Jun 24 2010, 1:26 pm
|
|
Falacy
 |
http://www.byond.com/members/ DreamMakers?command=view_tracker_issue&tracker_issue=1198
|
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*. | |