Descriptive Problem Summary:
When bound_y is greater than or equal to 0, it does not weigh in on the calculation for SIDE_MAP at all. Instead, it appears that the iconSortFuncSide() function only considers what the visual bound_y may be.

---

EDIT: Seems that it is simply miscalculating bound_y when it's positive as seen by the test cast provided below. I've updated my link to reflect the change.


I've proven this is inconsistent behavior, because bound_x works perfectly fine.

---

Numbered Steps to Reproduce Problem:


1) First, observe the current values that are all related to SIDE_MAP ordering. You can do this by using the "PrintValue" verb.

2) Note that the blue overlay is a representation of the character's bounding boxes, that way we can record their position with our eyes.

3) In this basic state, when you go at least one pixel behind the monster, the monster is still drawn first. By observing the print statement, you can see that the bound_y value is not calculated correctly, particularly when it's POSITIVE.

EDIT: Instead, it only changes once your visual_bound is one pixel behind the visual_bounds of the enemy.

4) Before moving on, you can use ChangeDensity to turn off density after proving collision work, and moving into the monster. You'll notice it makes no difference.

5) Next, use Adjust_Bounds(). This will set your bound_y to a negative value, and just your pixel_y to keep it center at the new location of your bounds.

6) Use PrintValue again to see the changes.

7) Now observe as your bounds are calculated correctly!

8) You can also turn density back on to confirm that collision is also working correctly.

Code Snippet (if applicable) to Reproduce Problem:
Test Case: https://cdn.discordapp.com/attachments/725458744711839873/ 1185194703948349531/Y_SortTest.zip

Ter's Test Case:
https://cdn.discordapp.com/attachments/725458744711839873/ 1185471321887473684/SidemapBugs_src.zip?ex=658fbb34&is=657d4 634&hm=23f4c16c34acbc0a52dce8895fd95281bab80f4ca4a7c1074c87b 2e07b673725

Expected Results:
The moment an atom is at least one pixel behind another atom, it should be drawn first in the drawing order. This is supposed to happen no matter what your bounds are set to.

Actual Results:
The atom is not drawn first until after it's visual bound is behind the visual bounds of the other atom when bound_y is 0 or greater. It only works when you set bound_y to negative values.

Does the problem occur:
Everytime.

When does the problem NOT occur?
It occurs every single time.


Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? This is an ancient BYOND bug, and seems to have caused mass confusion with how SIDE_MAP actually works.

Workarounds:

The only way around this problem is when you set your bound_y to a negative value. To do so, what I've done is provided each atom with a "physical_bound_x/y" variable. From there, I simply subtract it from a high negative value, then offset the image with pixel_y to make sure that it's centered with the bounding box.