/tg/ Station 13 - Modules - Types

code/controllers/subsystem/movement/movement_types.dm

/datum/move_loopTemplate class of the movement datums, handles the timing portion of the loops
/datum/move_loop/moveReplacement for walk()
/datum/move_loop/has_target/force_moveUsed for force-move loops
/datum/move_loop/has_target/dist_boundBase class of move_to and move_away, deals with the distance and target aspect of things
/datum/move_loop/has_target/dist_bound/move_toWrapper around walk_to()
/datum/move_loop/has_target/dist_bound/move_awayWrapper around walk_away()
/datum/move_loop/has_target/move_towardsUsed as a alternative to walk_towards
/datum/move_loop/has_target/move_towards_budgetThe actual implementation of walk_towards()
/datum/move_loop/freezeAs close as you can get to a "do-nothing" move loop, the pure intention of this is to absolutely resist all and any automated movement until the move loop times out.
/datum/move_loop/move_randThis isn't actually the same as walk_rand Because walk_rand is really more like walk_to_rand It appears to pick a spot outside of range, and move towards it, then pick a new spot, etc. I can't actually replicate this on our side, because of how bad our pathfinding is, and cause I'm not totally sure I know what it's doing. I can just implement a random-walk though
/datum/move_loop/move_to_randWrapper around step_rand
/datum/move_loop/disposal_holderDisposal holders need to move through a chain of pipes Rather then through the world. This supports this If this ever changes, get rid of this, add drift component like logic to the holder And move them to move()