jps
The datum used to handle the JPS pathfinding, completely self-contained
Vars | |
| caller | The thing that we're actually trying to path for |
|---|---|
| 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 & tracks what turfs came from where. Key is the turf, and the value is what turf it came from |
| 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. |
| finished | Cleanup pass for the pathfinder. This tidies up the path, and fufills the pathfind's obligations |
| lateral_scan_spec | For performing lateral scans from a given starting turf. |
| search_step | search_step() is the workhorse of pathfinding. It'll do the searching logic, and will slowly build up a path returns TRUE if everything is stable, FALSE if the pathfinding logic has failed, and we need to abort |
| start | "starts" off the pathfinding, by storing the values this datum will need to work later on returns FALSE if it fails to setup properly, TRUE otherwise |
| 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 thing that we're actually trying to path for
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 & tracks what turfs came from where. Key is the turf, and the value is what turf it came from
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
finished
Cleanup pass for the pathfinder. This tidies up the path, and fufills the pathfind's obligations
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.
search_step
search_step() is the workhorse of pathfinding. It'll do the searching logic, and will slowly build up a path returns TRUE if everything is stable, FALSE if the pathfinding logic has failed, and we need to abort
start
"starts" off the pathfinding, by storing the values this datum will need to work later on returns FALSE if it fails to setup properly, TRUE otherwise
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]