ID:55160
 
Keywords: bigatom, library
Version 4 of BigAtom implements the bigatom_Overlay() proc, which is a step in the right direction even if it doesn't have all the nifty features I would like it to.

There are two important things to keep in mind if you are using this early version of bigatom_Overlay():

First of all, it only works in BIGATOM_NOOVERLAYS mode. ("NOOVERLAYS" in this case refers to how the BigAtom is displayed. It forces each tile of the BigAtom to have an individual atom.) Since this is the default bigatom_mode there shouldn't be many problems with this.

The other issue is that your overlay should match the base icon in size and icon_states, or it will display the basic 32x32 mini icon on parts that do not satisfy the condition. For instance, if you have a 64x96 person and try to overlay a 64x64 shirt on them, the top left and top right icons will have mini shirt icons on them. If your shirt doesn't have a "punch" state and you flick "punch", every tile will have a mini-shirt until the flick is finished.
I don't know if you knew this or not, but BigAtom has a bug in it (not sure if it is still present in the new version).
It cannot handle icons that are 10x10 (or 320x320 pixels) in size or bigger. I am pretty sure part of it has to do with you checking for the icon stat containing the text "0,0", and an icon state containing "10,0" contains "0,0". Though that seems to be only part of the problem, because I changed that to fix the issue, but it still didn't work!
Well, I never addressed the problem since I didn't know about it (You should have let me know when you noticed it!) but I just verified that BigAtom has no trouble with an 800x800 mob created at runtime.

It does look like it would have a problem with BigAtoms place on the map though, as you indicated. I'll clean that up and get a fix out soon. Thanks for the report, even if it is overdue! :)
Shadowdarke, everybody's still waiting for... IT.

On another note, though, BigAtoms with overlays! Nifty.