Space Station 13 - Modules - TypesVar Details - Proc Details

pathfind

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

Vars

avoidA 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
callerThe thing that we're actually trying to path for
diagonal_safetyEnsures diagonal moves won't use invalid midstep turfs by splitting them into two orthogonal moves if necessary
endThe turf we're trying to path to (note that this won't track a moving target)
idAn ID card representing what access we have and what doors we can open. Its location relative to the pathing atom is irrelevant
max_distanceI don't know what this does vs , but they limit how far we can search before giving up on a path
mintargetdistHow far away we have to get to the end target before we can call it quits
openThe open list/stack we pop nodes out from (TODO: make this a normal list and macro-ize the heap operations to reduce proc overhead)
pathThe list we compile at the end if successful to pass back
simulated_onlySpace is big and empty, if this is TRUE then we ignore pathing through unsimulated tiles
sourcesAn 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
startThe turf where we started at

Procs

diag_scan_specFor performing diagonal scans from a given starting turf.
lateral_scan_specFor performing lateral scans from a given starting turf.
searchsearch() is the proc you call to kick off and handle the actual pathfinding, and kills the pathfind datum instance when it's done.
unwind_pathCalled 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

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

diagonal_safety

Ensures diagonal moves won't use invalid midstep turfs by splitting them into two orthogonal moves if necessary

end

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

id

An ID card representing what access we have and what doors we can open. Its location relative to the pathing atom is irrelevant

max_distance

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

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

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

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:

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:

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)

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