/datum/plane_master_group
Datum that represents one "group" of plane masters So all the main window planes would be in one, all the spyglass planes in another Etc
Vars | |
active_offset | The visual offset we are currently using |
---|---|
key | Our key in the group list on /datum/hud Should be unique for any group of plane masters in the world |
map | What, if any, submap we render onto |
our_hud | Our parent hud |
plane_masters | List in the form "[plane]" = object, the plane masters we own |
relay_loc | Controls the screen_loc that owned plane masters will use when generating relays. Due to a Byond bug, relays using the CENTER positional loc Will be improperly offset |
Procs | |
attach_to | Display a plane master group to some viewer, so show all our planes to it |
build_plane_masters | Actually generate our plane masters, in some offset range (where offset is the z layers to render to, because each "layer" in a multiz stack gets its own plane master cube) |
get_plane | Nice wrapper for the "[]"ing |
get_plane_types | Returns a list of all the plane master types we want to create |
orphan_hud | Hide the plane master from its current hud, fully clear it out |
prep_plane_instance | Similarly, exists so subtypes can do unique behavior to planes on creation |
rebuild_hud | Fully regenerate our group, resetting our planes to their compile time values |
rebuild_plane_masters | Regenerate our plane masters, this is useful if we don't have a mob but still want to rebuild. Such in the case of changing the screen_loc of relays |
refresh_hud | Well, refresh our group, mostly useful for plane specific updates |
show_plane | This is mostly a proc so it can be overriden by popups, since they have unique behavior they want to do |
Var Details
active_offset
The visual offset we are currently using
key
Our key in the group list on /datum/hud Should be unique for any group of plane masters in the world
map
What, if any, submap we render onto
our_hud
Our parent hud
plane_masters
List in the form "[plane]" = object, the plane masters we own
relay_loc
Controls the screen_loc that owned plane masters will use when generating relays. Due to a Byond bug, relays using the CENTER positional loc Will be improperly offset
Proc Details
attach_to
Display a plane master group to some viewer, so show all our planes to it
build_plane_masters
Actually generate our plane masters, in some offset range (where offset is the z layers to render to, because each "layer" in a multiz stack gets its own plane master cube)
get_plane
Nice wrapper for the "[]"ing
get_plane_types
Returns a list of all the plane master types we want to create
orphan_hud
Hide the plane master from its current hud, fully clear it out
prep_plane_instance
Similarly, exists so subtypes can do unique behavior to planes on creation
rebuild_hud
Fully regenerate our group, resetting our planes to their compile time values
rebuild_plane_masters
Regenerate our plane masters, this is useful if we don't have a mob but still want to rebuild. Such in the case of changing the screen_loc of relays
refresh_hud
Well, refresh our group, mostly useful for plane specific updates
show_plane
This is mostly a proc so it can be overriden by popups, since they have unique behavior they want to do