/tg/ 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
on_finishThe callback to invoke when we're done working, passing in the completed var/list/path
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
skip_firstIf we should delete the first step in the path or not. Used often because it is just the starting tile
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.
early_exitearly_exit() is called when something goes wrong in processing, and we need to halt the pathfinding NOW
finishedCleanup pass for the pathfinder. This tidies up the path, and fufills the pathfind's obligations
lateral_scan_specFor performing lateral scans from a given starting turf.
search_stepsearch_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_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

on_finish

The callback to invoke when we're done working, passing in the completed var/list/path

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

skip_first

If we should delete the first step in the path or not. Used often because it is just the starting tile

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:

early_exit

early_exit() is called when something goes wrong in processing, and we need to halt the pathfinding NOW

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:

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]