mob/New()
..()
src.overlays += image('spades.dmi',"K")
src.overlays += icon('gold.dmi')
mob/verb/test_overlays()
var/X = overlays[1]
if(istype(X,/image)) usr << "Image!"
else if(istype(X,/icon)) usr << "Icon!"
else if(istype(X,/datum)) usr << "Datum!"
else if(istype(X,/atom)) usr << "Atom!"
else if(isnum(X)) usr << "Num!"
else if(istext(X)) usr << "Text!"
else if(isfile(X)) usr << "File!"
else if(isnull(X)) usr << "Null!"
else if(ispath(X)) usr << "Type!"
...and got no output whatsoever.
This was the code Maz tried:
who()
set hidden = 1
var/layout
layout += {"<font color = blue"><center><I><B>Users Online</i></center></b></font>"}
for (var/mob/pc/M in world)
var/icon/picture
picture = icon(M.icon)
for(var/K in M.overlays) picture.Blend(K,ICON_OVERLAY)
layout += "<BR>\icon[picture][src.ckey] - <font color=[rgb(src.Red,src.Green,src.Blue)]>[src]</font>"
src << layout
...but since overlays are inaccessible types as far as BYOND is concerned, it is impossible to generate an icon based on the overlays an object has.
So, if possible, it'd be peachy if we could implement that.
Maz could keep around a list of the objects used to generate the overlays, or their types or whatever. It's a doable workaround.
In general you usually need a way to reconstruct an object's display from scratch, including overlays. It's usually bad programming practice to have state for an object that you can't recreate from data on hand.
If you take an approach where you can always generate an object's display from scratch, you'll find it makes the code much more flexible. For example, in L&D the player might have drunk color potions, added tattoos, be riding a jetboard (well whenever the next release can come out they might, anyway)...data has to be kept for all that to make it realistic for the player's multi-turf mob to be regenerated as necessary (for example, when they drink a new color potion their icons are all redone).