SIDE_MAP bounds() and obounds() malfunction

ID:1332371
 
Jul 23 2013, 5:44 am
BYOND Version:499
Operating System:Windows 7 Ultimate
Web Browser:Chrome 27.0.1453.116
Applies to:DM Language
Status: Unverified
Thus far we've been unable to verify or reproduce this bug. Or, it has been observed but it cannot be triggered with a reliable test case. You can help us out by editing your report or adding a comment with more information.
Descriptive Problem Summary:
When world.map_format is set to SIDE_MAP any attempt to use bounds() or obounds() will only return the turf tiles the objects are on. The world.icon_size is set to "48x36".

Numbered Steps to Reproduce Problem:
Set world.map_format to SIDE_MAP.
Set world.icon_size to "48x36".
Try to get bounds() or obounds(), with any atom.

Expected Results:
Return the objects in the bounds.

Actual Results:
Returns the turf locations they are on.

Does the problem occur:
Every time? Or how often? Everytime.
In other games? Yes.
In other user accounts? Yes.
On other computers? Yes.

When does the problem NOT occur?
When world.map_format=TOPDOWN_MAP

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.)

Workarounds:
Set world.map_format to TOPDOWN_MAP, but is not ideal, causes layering issues.
Jul 23 2013, 6:05 am
I don't fully understand what you mean here. Do you mean obounds() would normally pick up other mobs but is just returning their turfs? Or do you mean that obounds() is failing to include anything that the mob visually covers, even if the mob itself is only standing on one turf?

My feeling on this is that you're probably not looking at a bug at all, and this is just a misunderstanding of how the proc works. The reason I think this is that obounds() works strictly on the logical position of the atom, not its visual position. In a 48x36 SIDE_MAP environment, a mob without modified bounds has a logical size of 48x48, and all the tiles have a 48x48 logical size. When displayed, pixel_y and step_y are scaled down to 3/4 to fit the 48x36 tile size for visual purposes. TOPDOWN_MAP will take your given tile size as the logical size, and is the only format that allows logical tiles to be non-square.

The upshot of this is that if you have a mob icon that's 48x48, but the world is SIDE_MAP with 48x36, visually the mob will obviously cover more than one tile because it's too tall; but unless it has a step_y positioning it between two tiles, or it has a bound size such that its bound_height is greater than 48, it is in fact only covering a single tile. The icon's "overflow" is strictly visual and does not impact obounds() in any way, nor should it.

If I'm wrong in my thinking and there is some actual buggy behavior going on, a test case would be helpful to narrow it down. However I'm quite confident there isn't a bug here, since the foreshortening doesn't happen until it's time to display the icon.
Jul 23 2013, 6:10 am (Edited on Jul 23 2013, 6:17 am)
The problem is not visual at all, I am aware of the differences between TOPDOWN_MAP and SIDE_MAP, and the visual implications.
mob
    bound_x=15
    bound_y=6
    bound_width=18
    bound_height=18
    var
        attackRange=16
    proc
        melee()
            var
                px=0
                py=0
            if(dir&NORTH)py=attackRange
            if(dir&SOUTH)py=-attackRange
            if(dir&EAST)px=attackRange
            if(dir&WEST)px=-attackRange
            var/L[]=obounds(src,px,py)
            for(var/mob/m in L)
                m.takeDamage(strength.val+1,src)

When I run this in TOPDOWN_MAP it works perfectly, (I'm facing the target and am in range). If I were to use it in SIDE_MAP format, list L would only contain the turf elements, while TOPDOWN_MAP would return the enemy mob and the other objects, which are in the vicinity.
Jul 23 2013, 7:02 am (Edited on Jul 23 2013, 7:08 am)
Again though, are you certain you're in range? TOPDOWN_MAP will behave differently only because of the fact that the logical tile size there is 48x36, which must be taken into account. Your north/south attacks will appear to extend about 11 pixels rather than 16. East and west should work as expected.

I ran tests on this, and obounds() behaves exactly as I expect when I switch my debug project between topdown and side mode.

Based on what I see of your code, I think you've merely set the atom's bounds incorrectly. The bound_y and bount_height values are based on logical position, not physical position, and must be set accordingly. The width and height you're using say you have an 18x18 icon within the 48x48 tile (logical size), but bound_y says it's standing well south of the tile's center. If you were attempting to center the icon visually, then bound_y has been miscalculated.

[edit]
A test case would go a long way toward confirming or resolving this, but screenshots might be a good idea too. In screenshots you can show me exactly which cases are coming up.
Jul 23 2013, 7:22 am
Well, the bumping works perfectly, I have no problems with it, the object is well within range. The bound box is supposed to be south that much. You can get the feeling in http://www.byond.com/games/Taitz/Resurrection probably, I encountered that problem in the middle of the contest so I didn't report and resorted to using TOPDOWN_MAP.

Even if I use bounds(src,48) it returned the mob in the list when they were north from me. When increased to bounds(src,64) it will return the mob in the list when east or west, plus when they are north from the src.

Edit: Everything below 48 (used 16 increments) didn't even display the src in the returned list.
Jul 23 2013, 8:56 am
I really need a screenshot or test case. The code says there's no issue here. My tests say the same. So there's something else going on.
Jul 23 2013, 8:56 am
Lummox JR changed status to 'Unverified'