ID:159319
 
After I save and load
How do I remove Overlays
mine doesnt work
mob/proc/removeAllOverlays()
overlays = null


Overlays are a list, so this resets the list in its entirety.

Should you wish to remove something to update the overlay list and how your character looks, you'd have to cycle through the list, find it, remove it, and then update it. Gimme a couple minutes, I think can whip up something.

Last I knew, when an object was written to a savefile, its overlays were first blended with the object's icon, all merged into one image, and that image is saved as the object's icon. When you then load the object back up, the overlays list is empty since all the overlays are now permanently part of the icon itself.

You need to manage the saving and loading yourself if you want to keep overlays in the equation.

One way to do it is to copy all the overlays to a different list, save that list along with the object, and make sure you save a copy of the icon that is not merged with the overlays, then, when you load the object back up, you could loop through all the images in the list and re-add them to the overlays list.
In response to Loduwijk
About saying That overlays become 1merged with icon is apparently wrong
When i put overlays = null after loading it workd but the problem is the whole overlay goes
In response to Getenks
Getenks wrote:
About saying That overlays become 1merged with icon is apparently wrong

Yes, it is. Something more accurate might be that all the overlays get merged into one overlay, but I don't remember if that's the exact case at the moment.

When i put overlays = null after loading it workd but the problem is the whole overlay goes

Of course all the overlays go, since you're scrapping the entire overlays list. Anyway, saving overlays kind of screws up removing overlays individually somewhat, what you need to do here is not save overlays and rather rebuild them when the mob is loaded. For example, if your overlays are of hair and some equipment the mob has on which are stored in his equipment list, you could do something like this to recreate them:
mob
Write(savefile/F)
//Write() is the proc that saves objects into savefiles
..() //do its thing (..saving..)
F.dir -= "overlays" //remove the overlays dir from the savefile, deleting the saved overlays list
Read(savefile/F)
//likewise, Read() would be called for our mob to load it
..() //load saved vars...
//then, populate the overlays list for the newly-restored,\
overlay-less mob

src.RebuildOverlays()

var/list/equipment
var/hair = 'long_hair.dmi'
proc/RebuildOverlays()
src.overlays = null
src.overlays += src.hair
for(var/obj/O in src.equipment)
//loop through all equipped items, add their overlay
src.overlays += O
//you can also instead of looping explicitly do this,\
provided you want to add all the items in the list.

src.overlays += src.equipment

EDIT: I suppose it'll be somewhat better to really put the call on New() instead of Read() in most cases.
In response to Kaioken
Hmmm...
But I dont know how
But in my Name Add proc means that name added to the bottom of the player in most MMORPG . I saved it and when I use change name or change name colour the Name underlay goes without nulling the whole list ? Why is that ?
In response to Kaioken
Kaioken wrote:
Getenks wrote:
About saying That overlays become 1merged with icon is apparently wrong

Yes, it is. Something more accurate might be that all the overlays get merged into one overlay,

Yes, that is the case. I misspoke when I said they get merged with the object's icon; they simply get merged together and the resulting icon is saved as one, but not as one with the icon represented by the icon variable as well.
In response to Getenks
That depends on how the naming thing you mention is done.
In response to Loduwijk
"Disclaimer": Not all of this post is of course exclusively directed at you Lodu, I'm simply being informative for the general surfers so I added some stuff to this post along the way. :P Well, mainly the notes at the end.

Loduwijk wrote:
Yes, that is the case. I misspoke when I said they get merged with the object's icon; they simply get merged together and the resulting icon is saved as one, but not as one with the icon represented by the icon variable as well.

Well, actually, with a quick test to verify using some testing code, I see it is not the case either. Here's what happens: after being loaded from a savefile, the overlays do remain separated <small>(this can also be verified very quickly by checking the overlays list's len var)</small>. It seems, like I've said, that the overlays simply become impossible to remove individually by traditional means for an unknown(?) reason (attempting to remove the overlay with the exact value used to add it simply has no effect), this is apparently not a bug as it's basically acknowledged by the staff for being how it works. Do note this actually only happens to some of the overlays<font color=black>*</font>, and not all - for example, I've found that after a reload, you can still remove overlays added by icon file (overlays += 'icon.dmi') as normally, but not overlays added by atom type path or object reference (even if you use the same object); those become 'stuck' as known with this occurrence. Although those cannot be removed by conventional means, all overlays (so including stuck ones) can be 'forcefully' individually removed by looping through the overlays list and using its elements to remove them. The possibility of methods like that is somewhat known, but they seemingly remain unused because of the unconventionality of them, and the fact the overlays list's elements are an internal format not available in DM (though still readable, at least partially) and the warning about that (e.g. in the DM Ref). Perhaps eventually someone <small>(ugh, maybe me)</small> will take the time to divulge some more about this and write a library that uses this to manage overlays, which may remove the need for workarounds like keeping additional "Overlays" lists or whatever. In any case, looping through overlays is useful anyway and it has had its uses for me as well.
________________
Notes:
  • <font color=black>*</font> I haven't tested all possible value types to add overlays to see which can be removed after reloading, just the ones I've stated: icon file, atom (obj) and atom type paths. There are some more value types that can be used like /image and /icon objects and text strings (icon states), which may have varying results.
  • It is, of course, still preferable not to save overlays in a savefile (as with any icon data) as they take a lot of space, and when possible instead save data to be used in reproducing those overlays after the atom is loaded, if it's not already saved regardless.
  • Just so this stays clear, you can of course remove all overlays (including 'stuck' ones) by changing or clearing the overlays list (ie overlays.Cut() or overlays = null).
  • Everything discussed and said should of course also apply to the underlays list, let's not forget about that fella. :P I haven't specifically verified it for that list too this time, but everything with it should be completely identical to overlays other than the default layering stuff (do correct me if I'm wrong or inaccurate).
In response to Kaioken
Hmm.
But u guys say that overlays become 1 image
But Y save them in 1 association
y can twe save them as
for(var/O in src.overlays)
F["[O:name]"] << O
// this was the saving part
i m not quite sure with the loading part..

In response to Getenks
Because overlays isn't a list your can loop through. When you add an image to overlays, internal formatting blends that image to your icon.
In response to Kaiochao
Really? Then how come you can remove certain overlays through the -= operator, not affecting the other overlays at all?
In response to Spunky_Girl
Because of that internal formatting that overlays "list" has that I may have sort of mentioned before.
In response to Kaiochao
Kaiochao wrote:
Because overlays isn't a list your can loop through.

You can loop through it and do various stuff with the contents (which is what's special, ofc) , as I've said. The list itself is quite normal and can also be replaced with a list of you own so you can do to it whatever you can to most lists.
In response to Kaioken
Kaioken wrote:
Well, actually, with a quick test to verify using some testing code, I see it is not the case either. Here's what happens:...

That is odd. The knowledge I was using was stuff I was trying to pull up from a long time ago, but, nonetheless, I had thought that the behavior I mentioned was originated from one of the staff members.

I have never actually had any dealings with the matter myself, so the knowledge that I thought I had was not from personal experience.

Oh well.
In response to Kaioken
Kaioken wrote:
Kaiochao wrote:
Because overlays isn't a list your can loop through.

You can loop through it and do various stuff with the contents (which is what's special, ofc) , as I've said. The list itself is quite normal and can also be replaced with a list of you own so you can do to it whatever you can to most lists.

I was messing with this the other day, and I'm pretty sure that you can't loop through the overlays list. The DM Reference states: "The individual items in the list may not be directly accessed, since they are stored in a special internal format. However, the list operators +=, -=, and the procedures Add, Remove, and Cut work normally. "
I'm assuming that "directly accessing" includes for loops.
In response to Chessmaster_19
Chessmaster_19 wrote:
I'm assuming that "directly accessing" includes for loops.

Looping through the list is directly accessing the list, not the individual items in its contents. You can loop through overlays and read vars of the special internal type objects stored inside with the . and : operators (even though there is no DM type to correspond to them), I've done it many times and it's known to be possible. The objects inside essentially have vars similar to an /image. You can also use their reference to reassuringly remove them from the overlays list [even if they're "stuck"].
Try this verb if you want, after you put some overlays on your mob:
mob/verb/LoopOverlays()
/*loop through everything in overlays, though typecast
the var as /image for easy access, even though what's inside
isn't really images*/

for(var/image/X as anything in src.overlays)
src << "Overlay: ([X.icon])([X.icon_state])"
if(alert(src,"Remove this overlay?",,"Yes","No") == "Yes")
src.overlays -= X
In response to Kaioken
Better U Build Them
Hmm - Should Byond be Blamed for this or is it just impossible ?

In response to Getenks
Uh... context please? What are you referring to? Should BYOND be blamed for *what*? I think your problem in this thread should've been solved already.
In response to Kaioken
Thnx and take back my words
sorry
:-)