| /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 walk_away() |
|---|
| /datum/move_loop/has_target/move_towards | Used as a alternative to walk_towards |
|---|
| /datum/move_loop/has_target/move_towards_budget | The actual implementation of walk_towards() |
|---|
| /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 |
|---|
| /datum/move_loop/disposal_holder | Disposal 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() |
|---|
