Overlays which are generated using Crop() align differently in the stat panel and on an object.
Numbered Steps to Reproduce Problem:
1. Create a new icon.
2. Crop its height - width cropping behaves normally.
3. Add the icon to the overlays of an object, and then add the object to the stat panel.
4. See how the overlay is aligned differently in each. On the object, the overlay is aligned so that its bottom edge meets the bottom of the atom, but in the panel the top edge meets the top of the atom.
Code Snippet (if applicable) to Reproduce Problem:
/obj/example_type
name = "Example"
icon = 'example.dmi'
icon_state = "background"
/obj/example_type/New()
..()
var/icon/new_icon = icon(src.icon, "foreground")
new_icon.Crop(1, 1, new_icon.Width(), new_icon.Height() * 0.5)
overlays += new_icon
overlays += "test1"
overlays += icon(src.icon, "test2")
/mob/Stat()
for(var/obj/example_type/example_obj in world)
stat(example_obj.name, example_obj)
Expected Results:
When the object is added to the stat panel, the cropped foreground overlay should appear aligned with the bottom of the atom, like it does on the object itself.
Actual Results:
The cropped overlay appears aligned with the top of the atom instead.
test1 and test2 align consistently on both, however.
Does the problem occur:
Every time? Or how often?
Every time.
In other games?
As far as I can tell, yes, since the code above has no SS13 elements and was tested on a fresh environment.
In other user accounts?
Yes.
On other computers?
Yes.
When does the problem NOT occur?
If you crop in the horizontal direction, the overlay aligns consistently. Otherwise, this always happens.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Untested.
Workarounds:
Make an image and set its pixel_x and pixel_y manually, I assume, but I haven't tried that yet.
EXAMPLE IMAGE: http://puu.sh/ieMXT/2a94776c3d.png
SECOND EXAMPLE IMAGE (from different user): http://i.imgur.com/yDoPWEp.png
I'm pretty sure the webclient does not have this issue.