/datum/pathfind

The datum used to handle the JPS pathfinding, completely self-contained

Vars
avoid	A specific turf we're avoiding, like if a mulebot is being blocked by someone t-posing in a doorway we're trying to get through
caller	The thing that we're actually trying to path for
cardinal_only	Whether we only want cardinal steps
ends	The turf we're trying to path to (note that this won't track a moving target)
max_distance	I don't know what this does vs , but they limit how far we can search before giving up on a path
max_seen	Max number of tiles seen, null skips the check
mintargetdist	How far away we have to get to the end target before we can call it quits
n_target_goals	The number of goals we need to find to succeed
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)
options	Raw associative list of options passed from get_path_to.
paths	The list we compile at the end if successful to pass back
simulated_only	Space is big and empty, if this is TRUE then we ignore pathing through unsimulated tiles
sources	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
start	The turf where we started at
total_seen	The total number of tiles seen so far
Procs
cardinal_scan_spec	For performing cardinal scans from a given starting turf.
diag_scan_spec	For performing diagonal scans from a given starting turf.
search	search() is the proc you call to kick off and handle the actual pathfinding, and kills the pathfind datum instance when it's done.
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

var
avoid
– /turf

A specific turf we're avoiding, like if a mulebot is being blocked by someone t-posing in a doorway we're trying to get through

var
caller
– /atom/movable

The thing that we're actually trying to path for

var
cardinal_only
–

Whether we only want cardinal steps

var
ends
– /list/turf

The turf we're trying to path to (note that this won't track a moving target)

var
max_distance
–

I don't know what this does vs , but they limit how far we can search before giving up on a path

var
max_seen
–

Max number of tiles seen, null skips the check

var
mintargetdist
–

How far away we have to get to the end target before we can call it quits

var
n_target_goals
–

The number of goals we need to find to succeed

var
open
– /datum/heap

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)

var
options
– /list

Raw associative list of options passed from get_path_to.

var
paths
– /list/list/turf

The list we compile at the end if successful to pass back

var
simulated_only
–

Space is big and empty, if this is TRUE then we ignore pathing through unsimulated tiles

var
sources
– /list

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

var
start
– /turf

The turf where we started at

var
total_seen
–

The total number of tiles seen so far

Proc Details

proc
cardinal_scan_spec
(/turf/original_turf, heading, /datum/jps_node/parent_node)

For performing cardinal 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 cardinal 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 cardinal scans, if we don't have one, we're a diagonal subscan.

proc
diag_scan_spec
(/turf/original_turf, heading, /datum/jps_node/parent_node)

For performing diagonal scans from a given starting turf.

Unlike cardinal 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 cardinal 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

proc
search
()

search() is the proc you call to kick off and handle the actual pathfinding, and kills the pathfind datum instance when it's done.

If a valid path was found, it's returned as a list. If invalid or cross-z-level params are entered, or if there's no valid path found, we return null, which /proc/get_path_to translates to an empty list (notable for simple bots, who need empty lists)

proc
unwind_path
(/datum/jps_node/unwind_node)

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

/datum/pathfind

Vars

Procs

Var Details

var avoid – /turf

var caller – /atom/movable

var cardinal_only –

var ends – /list/turf

var max_distance –

var max_seen –

var mintargetdist –

var n_target_goals –

var open – /datum/heap

var options – /list

var paths – /list/list/turf

var simulated_only –

var sources – /list

var start – /turf

var total_seen –