jps
Vars | |
caller | The movable we are pathing |
---|---|
diagonal_handling | Defines how we handle diagonal moves. See __DEFINES/path.dm |
end | The turf we're trying to path to (note that this won't track a moving target) |
found_turfs | An assoc list that serves as the closed list. Key is the turf, points to true if we've seen it before |
mintargetdist | How far away we have to get to the end target before we can call it quits |
open | The open list/stack we pop nodes out from (TODO: make this a normal list and macro-ize the heap operations to reduce proc overhead) |
path | The list we compile at the end if successful to pass back |
skip_first | If we should delete the first step in the path or not. Used often because it is just the starting tile |
Procs | |
diag_scan_spec | For performing diagonal scans from a given starting turf. |
lateral_scan_spec | For performing lateral scans from a given starting turf. |
unwind_path | Called when we've hit the goal with the node that represents the last tile, then sets the path var to that path so it can be returned by [datum/pathfind/proc/search] |
Var Details
caller
The movable we are pathing
diagonal_handling
Defines how we handle diagonal moves. See __DEFINES/path.dm
end
The turf we're trying to path to (note that this won't track a moving target)
found_turfs
An assoc list that serves as the closed list. Key is the turf, points to true if we've seen it before
mintargetdist
How far away we have to get to the end target before we can call it quits
open
The open list/stack we pop nodes out from (TODO: make this a normal list and macro-ize the heap operations to reduce proc overhead)
path
The list we compile at the end if successful to pass back
skip_first
If we should delete the first step in the path or not. Used often because it is just the starting tile
Proc Details
diag_scan_spec
For performing diagonal scans from a given starting turf.
Unlike lateral scans, these only are called from the main search loop, so we don't need to worry about returning anything, though we do need to handle the return values of our lateral subscans of course.
Arguments:
- original_turf: What turf did we start this scan at?
- heading: What direction are we going in? Obviously, should be diagonal
- parent_node: We should always have a parent node for diagonals
lateral_scan_spec
For performing lateral scans from a given starting turf.
These scans are called from both the main search loop, as well as subscans for diagonal scans, and they treat finding interesting turfs slightly differently. If we're doing a normal lateral scan, we already have a parent node supplied, so we just create the new node and immediately insert it into the heap, ezpz. If we're part of a subscan, we still need for the diagonal scan to generate a parent node, so we return a node datum with just the turf and let the diag scan proc handle transferring the values and inserting them into the heap.
Arguments:
- original_turf: What turf did we start this scan at?
- heading: What direction are we going in? Obviously, should be cardinal
- parent_node: Only given for normal lateral scans, if we don't have one, we're a diagonal subscan.
unwind_path
Called when we've hit the goal with the node that represents the last tile, then sets the path var to that path so it can be returned by [datum/pathfind/proc/search]