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
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

var
active_offset
–

The visual offset we are currently using

var
key
–

Our key in the group list on /datum/hud Should be unique for any group of plane masters in the world

var
map
–

What, if any, submap we render onto

var
our_hud
– /datum/hud

Our parent hud

var
plane_masters
– /list/atom/movable/screen/plane_master

List in the form "[plane]" = object, the plane masters we own

var
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

proc
attach_to
(/datum/hud/viewing_hud)

Display a plane master group to some viewer, so show all our planes to it

proc
build_plane_masters
(starting_offset, ending_offset)

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)

proc
get_plane
(plane)

Nice wrapper for the "[]"ing

proc
get_plane_types
()

Returns a list of all the plane master types we want to create

proc
prep_plane_instance
(/atom/movable/screen/plane_master/instance)

Similarly, exists so subtypes can do unique behavior to planes on creation

proc
rebuild_hud
()

Fully regenerate our group, resetting our planes to their compile time values

proc
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

proc
refresh_hud
()

Well, refresh our group, mostly useful for plane specific updates

proc
show_plane
(/atom/movable/screen/plane_master/plane)

This is mostly a proc so it can be overriden by popups, since they have unique behavior they want to do

plane_master_group /datum/plane_master_group

Vars

Procs

Var Details

var active_offset –

var key –

var map –

var our_hud – /datum/hud

var plane_masters – /list/atom/movable/screen/plane_master

var relay_loc –

Proc Details

proc attach_to(/datum/hud/viewing_hud)

proc build_plane_masters(starting_offset, ending_offset)

proc get_plane(plane)

proc get_plane_types()

proc prep_plane_instance(/atom/movable/screen/plane_master/instance)

proc rebuild_hud()

proc rebuild_plane_masters()

proc refresh_hud()

proc show_plane(/atom/movable/screen/plane_master/plane)