Forums » Impact Engine » CollisionMap trace result (res): bug?

I happened across what seems to be an issue while I was trying to get the coordinates of the tile my entity was colliding with. I searched the forums and it was previously mentioned here: http://impactjs.com/forums/help/res-parameter-of-handlemovementtrace.

The issue is that res.tile.x and res.tile.y are set to the value of the tile instead of the coords of the tile. It seems like inside of _traceStep, res.tile.x should get tileX and res.tile.y should get tileY. Am I misunderstanding what these properties are supposed to represent?

I agree it&039;s a bit odd, but it's intended this way. The trace result's #tile.x/y reports the tile number for the collision in either direction. E.g. if you hit a bottom right corner, tile.x will have the tile number to the right of the resolved position, tile.y the tile number to the bottom.

Of course you can still "hack" the collision-map.js and include new .tilePos property in the result.

Thanks for replying Dominic. I'm sorry, I think I was not very clear in my initial post. Hopefully some code will help. This is from inside CollisionMap._traceStep:

t = this.data[tileY][tileX];

So here, t is 1 for a solid (non-slope) tile. Then, if there is a horizontal collision, res.tile.x gets assigned as:

res.tile.x = t;

res.tile.y is not assigned at all, so it retains the default of 0. So (if you have no slopes) you always end up with either 1 or 0 for res.tile.x and res.tile.y.

If I am reading your response correctly, then I would expect to get some kind of tile coordinates in res.tile, not the value of the tile from the layer data.

Hopefully this illustrates the point I am trying to make. Based on your description (and my assumption about how it would work), I think that res.tile.x should be assigned tileX.

I did go ahead and hack collision-map.js so that I could do the debugging I wanted to, so this is not holding me up. I just wanted to bring this bug to your attention.

Sorry for not being clear. I agree that getting the tile position may be useful as well. But the behavior you describe is by design. res.tile.x/y reports the tile number (or 0 if there was no collision on this axis), not the tile position.