code/controllers/subsystem/movement/movement_types.dm 
| /datum/move_loop | Template class of the movement datums, handles the timing portion of the loops |
|---|---|
| /datum/move_loop/move | Replacement for walk() |
| /datum/move_loop/has_target/force_move | Used for force-move loops |
| /datum/move_loop/has_target/dist_bound | Base class of move_to and move_away, deals with the distance and target aspect of things |
| /datum/move_loop/has_target/dist_bound/move_to | Wrapper around walk_to() |
| /datum/move_loop/has_target/dist_bound/move_away | Wrapper around GLOB.move_manager.move_away() |
| /datum/move_loop/has_target/move_towards | Used as a alternative to GLOB.move_manager.home_onto |
| /datum/move_loop/has_target/move_towards_budget | The actual implementation of GLOB.move_manager.home_onto() |
| /datum/move_loop/freeze | As 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_rand | This 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_rand | Wrapper around step_rand |