/tg/ Station 13 - Modules - TypesProc Details

move_manager

Acts as a namespace for movement packet/type related procs

Exists to provide an in code implementation of movement looping Replaces things like walk() or walk_to(), among others

Because we're doing things in engine, we have a lot more control over how different operations are performed We also get more say in when things happen, so we can subject movements to the whims of the master controller Rather then using a fuck ton of cpu just moving mobs or meteors

The goal is to keep the loops themselves reasonably barebone, and implement more advanced behavior and control via the signals

This may be bypassed in cases where snowflakes are nessesary, or where performance is important. S not a hard and fast thing

Every atom can have a movement packet, which contains information and behavior about currently active loops, and queuing info Loops control how movement actually happens. So there's a "move in this direction" loop, a "move randomly" loop

You can find the logic for this control in this file

Specifics of how different loops operate can be found in the movement_types.dm file, alongside the add to loop helper procs that use them

Procs

add_to_loopAdds a movable thing to a movement subsystem. Returns TRUE if it all worked, FALSE if it failed somehow
force_moveUsed for force-move loops, similar to move_towards_legacy() but not quite the same
force_move_dirLike move(), but we don't care about collision at all
freezeAssigns a target to a move loop that immediately freezes for a set duration of time.
home_ontoHelper proc for homing onto something with move_towards
jps_moveUsed for following jps defined paths. The proc signature here's a bit long, I'm sorry
moveReplacement for walk()
move_awayWrapper around walk_away()
move_disposalsSnowflake disposal movement. Moves a disposal holder along a chain of disposal pipes
move_randHelper proc for the move_rand datum
move_toWrapper around walk_to()
move_to_randWrapper around walk_rand(), doesn't actually result in a random walk, it's more like moving to random places in viewish
move_towardsHelper proc for the move_towards datum
move_towards_legacyWrapper for walk_towards, not reccomended, as its movement ends up being a bit stilted
processing_onReturns the subsystem's loop if we're processing on it, null otherwise
smooth_moveHelper proc for the smooth_move datum
stop_loopingRemoves the atom from some movement subsystem. Defaults to SSmovement

Proc Details

add_to_loop

Adds a movable thing to a movement subsystem. Returns TRUE if it all worked, FALSE if it failed somehow

force_move

Used for force-move loops, similar to move_towards_legacy() but not quite the same

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move chasing - The atom we want to move towards delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 timeout - Time in deci-seconds until the moveloop self expires. Defaults to infinity subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

force_move_dir

Like move(), but we don't care about collision at all

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move direction - The direction we want to move in delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 timeout - Time in deci-seconds until the moveloop self expires. Defaults to infinity subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

freeze

Assigns a target to a move loop that immediately freezes for a set duration of time.

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move halted_turf - The turf we want to freeze on. This should typically be the loc of moving. delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 timeout - Time in deci-seconds until the moveloop self expires. This should be considered extremely non-optional as it will completely stun out the movement loop forever if unset. subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

home_onto

Helper proc for homing onto something with move_towards

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move chasing - The atom we want to move towards delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 home - Should we move towards the object at all times? Or launch towards them, but allow walls and such to take us off track. Defaults to FALSE timeout - Time in deci-seconds until the moveloop self expires. Defaults to INFINITY subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

jps_move

Used for following jps defined paths. The proc signature here's a bit long, I'm sorry

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move chasing - The atom we want to move towards delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 repath_delay - How often we're allowed to recalculate our path max_path_length - The maximum number of steps we can take in a given path to search (default: 30, 0 = infinite) miminum_distance - Minimum distance to the target before path returns, could be used to get near a target, but not right to it - for an AI mob with a gun, for example access - A list representing what access we have and what doors we can open simulated_only - Whether we consider turfs without atmos simulation (AKA do we want to ignore space) avoid - If we want to avoid a specific turf, like if we're a mulebot who already got blocked by some turf skip_first - Whether or not to delete the first item in the path. This would be done because the first item is the starting tile, which can break things timeout - Time in deci-seconds until the moveloop self expires. Defaults to infinity subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

move

Replacement for walk()

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move direction - The direction we want to move in delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 timeout - Time in deci-seconds until the moveloop self expires. Defaults to infinity subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

move_away

Wrapper around walk_away()

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move chasing - The atom we want to move towards max_dist - the furthest away from the target we're allowed to get delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 timeout - Time in deci-seconds until the moveloop self expires. Defaults to infinity subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

move_disposals

Snowflake disposal movement. Moves a disposal holder along a chain of disposal pipes

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 timeout - Time in deci-seconds until the moveloop self expires. Defaults to infinity subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

move_rand

Helper proc for the move_rand datum

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move directions - A list of acceptable directions to try and move in. Defaults to GLOB.alldirs delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 timeout - Time in deci-seconds until the moveloop self expires. Defaults to infinity subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

move_to

Wrapper around walk_to()

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move chasing - The atom we want to move towards min_dist - the closest we're allower to get to the target delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 timeout - Time in deci-seconds until the moveloop self expires. Defaults to infinity subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

move_to_rand

Wrapper around walk_rand(), doesn't actually result in a random walk, it's more like moving to random places in viewish

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 timeout - Time in deci-seconds until the moveloop self expires. Defaults to infinity subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

move_towards

Helper proc for the move_towards datum

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move chasing - The atom we want to move towards delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 home - Should we move towards the object at all times? Or launch towards them, but allow walls and such to take us off track. Defaults to FALSE timeout - Time in deci-seconds until the moveloop self expires. Defaults to INFINITY subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

move_towards_legacy

Wrapper for walk_towards, not reccomended, as its movement ends up being a bit stilted

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move chasing - The atom we want to move towards delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 timeout - Time in deci-seconds until the moveloop self expires. Defaults to infinity subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

processing_on

Returns the subsystem's loop if we're processing on it, null otherwise

smooth_move

Helper proc for the smooth_move datum

Returns TRUE if the loop sucessfully started, or FALSE if it failed

Arguments: moving - The atom we want to move angle - Angle at which we want to move delay - How many deci-seconds to wait between fires. Defaults to the lowest value, 0.1 timeout - Time in deci-seconds until the moveloop self expires. Defaults to INFINITY subsystem - The movement subsystem to use. Defaults to SSmovement. Only one loop can exist for any one subsystem priority - Defines how different move loops override each other. Lower numbers beat higher numbers, equal defaults to what currently exists. Defaults to MOVEMENT_DEFAULT_PRIORITY flags - Set of bitflags that effect move loop behavior in some way. Check _DEFINES/movement.dm

stop_looping

Removes the atom from some movement subsystem. Defaults to SSmovement