It would be nice if there was a feature that allowed you to get information from a list of icons
mob/verb/Test()
overlays+='a.dmi'
overlays+='b.dmi'
for(var/a in overlays)
if(is_icon(a))
world<<get_icon(a)
or maybe
mob/verb/Test()
overlays+='a.dmi'
overlays+='b.dmi'
for(var/icon/a in overlays)
if(is_icon(a))
world<<a.icon
And it would output something like this
a.dmi
b.dmi
ID:133361
Oct 26 2008, 12:05 am
|
|
In response to Lummox JR
|
|
It could be useful if this Appearance [object] was more documented!
Lummox JR wrote: While more direct manipulation of the overlays list would be nice, it wouldn't be able to work as you describe. What he specifically described is getting the name of the icon, which is actually already possible. Not all too robust to rely upon though, since it is somewhat similar to identifying atoms by their name. Once an item is added to the overlays list, the information on whether it was an icon, an icon_state, an /image, or an atom is lost. This would also be nice to have more documented. This info alone doesn't make much sense, since an overlay often takes a specific value in Remove() etc and as such to be removed (namely the same value used to add it, minus special cases) and other values don't remove it, even if they have an identical appearance (same vars). So how this whole deal operates is somewhat cloudy. For example, if you execute this testing code: proc/copy_appearance(atom/A,atom/b) //takes images, icon objects... You'll find all of the lines with the -= operator, except the commented out one, will fail to remove the overlay. Is that supposed to happen? It doesn't seem to tie in too much with this Appearance thing - and even if you change a non-appearance var on O such as name,suffix,text,gender before using -= with it, it will also fail to remove the overlay. |
In response to Kaioken
|
|
Kaioken wrote:
It could be useful if this Appearance [object] was more documented! Not really, since it's not DM-accessible. It's an internal object only. Once an item is added to the overlays list, the information on whether it was an icon, an icon_state, an /image, or an atom is lost. I agree this proces could stand for a little more light to be shed on it. Basically though just as Add() adds an appearance and not an actual icon/state/atom/image, Remove() does the same. So if you subtract an icon from an overlays list, you're really subtracting the equivalent of a basic Appearance with that icon. Likewise if you subtract an atom from the list, you're subtracting that atom's Appearance. For example, if you execute this testing code: Probably the right question to ask then would be which vars you're not copying, and which ones you're copying but shouldn't (like the tag, x/y/z, etc.). I can tell you for sure that loc does not impact the appearance at all. Lummox JR |
In response to Lummox JR
|
|
Lummox JR wrote:
Not really, since it's not DM-accessible. It's an internal object only. Something like at least a specific list of the vars it uses would be useful, though. Probably the right question to ask then would be which vars you're not copying, and which ones you're copying but shouldn't (like the tag, x/y/z, etc.). I can tell you for sure that loc does not impact the appearance at all. Dunno, it seems like there's a little more to it, or I'm missing something. Subtracting an identical /obj works, but not an /image or even a subtype of /obj (or the type path of it). Is type a counted variable? O_o |
In response to Kaioken
|
|
But if you cant make it get the names out of overlays then how does this work o.o?
overlays-='blah.dmi'? If its using something to identify it and its garbage information couldn't you make it like a list of vars that can only be removed by another identical list of vars and when you ask for something from overlays like this for(var/list/a in overlays) it returns the list of vars used to define the overlay. You could also make it a special type that has image related vars like for(var/app/a in overlays) world<<a.icon <br/> I mean if its using something to figure out which one to remove why not make it something the game and the game maker can use o.o? |
Lummox JR