mirror of
https://github.com/yogstation13/Yogstation.git
synced 2025-02-26 09:04:50 +00:00
ff3f84ab81
In cases where you're creating an image to use as an overlay, it makes more sense to use a mutable_appearance if you can. The image will create a static appearance for not just the image but also each intermediate step if you change vars along the way. The mutable appearance avoids this unnecessary and expensive process. The only situation that requires an image instead of a mutable_appearance is if the overlay is supposed to be directional. MA's ignore direction while images don't. I dunno why, probably another BYOND-ism. I added a convenience function, mutable_appearance(), designed to emulate image(). Also went ahead and set the default plane of /mutable_appearance to FLOAT_PLANE because it's fucking 0 by default. Several overlays that were image() calls were changed to just text strings when I could. overlays += "string" has the same result as overlays += image(icon, "string") and saves a proc call.
18 lines
888 B
Plaintext
18 lines
888 B
Plaintext
// Mutable appearances are an inbuilt byond datastructure. Read the documentation on them by hitting F1 in DM.
|
|
// Basically use them instead of images for overlays/underlays and when changing an object's appearance if you're doing so with any regularity.
|
|
// Unless you need the overlay/underlay to have a different direction than the base object. Then you have to use an image due to a bug.
|
|
|
|
// Mutable appearances are children of images, just so you know.
|
|
|
|
/mutable_appearance/New()
|
|
..()
|
|
plane = FLOAT_PLANE // No clue why this is 0 by default yet images are on FLOAT_PLANE
|
|
// And yes this does have to be in the constructor, BYOND ignores it if you set it as a normal var
|
|
|
|
// Helper similar to image()
|
|
/proc/mutable_appearance(icon, icon_state = "", layer = FLOAT_LAYER)
|
|
var/mutable_appearance/MA = new()
|
|
MA.icon = icon
|
|
MA.icon_state = icon_state
|
|
MA.layer = layer
|
|
return MA |