pathfind

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

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

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:

• 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.

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