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.
* Overlay queuing
* Fix SS flags
* Don't copy on assignment
* Flags processing
* Fix icon_smoothing
* MSO's helper proc
* Legacy detection
* Make it work
* Fixes shitcode
* Fix the flag
* |= -> +=
* OK, how did I fuck that up?
* shitcode
* Conditional assoc queue while initializing
* Cleanup everything
* Orange meme
* This isn't perfect, but its the best byond will give us.
* forgot about dir
* oh ya
* This was litterally the last thing i did last night before heading to bed
You can tell can't you?
* Fixes various shit
* Let's not ever pause
* Fix the flag
* Cleaned up some missing shit. Added image dummys
* Remove the one usage of FPRINT
* Jesus get rid of this
Added priority overlays to atoms, which will not be removed when overlays are cut and will always remain on top when new overlays are added. This requires everyone to use add_overlay() and cut_overlays() instead of overlays += and overlays.Cut(). These procs are found in __HELPERS/icons.dm, and the priority overlay list is found in game/atoms.dm. Everything else is replacing deprecated overlay manipulation.