bounds(): Really confusing

ID:273935
 
Sep 5 2011, 3:08 pm
Alright, so I understand that bounds in the format of
bounds(ref,x,y,width,height)

would produce a bounding box the size of the player's and add additional width and height, what I don't understand is how to make a bounding box that simply attacks in a line forward, regardless of the x and y

for instance, if the mob's bounding box is 8x8 yet I want it to poke stuff with a rod 16 pixelsin front, it'll leave a gap between the player and the end of the hitbox.
bounds(src,16,0)//the person is facing east, so 16 pixels to the right

^
|
that doesn't work, and I can see why, now here's what I really don't get

bounds(src,16,0,8,0)//now the bounding box is 8 pixels longer

this still doesn't work.

My questions:
is that 8 pixels going even further east, or should it fill in the 8 pixel-gap between the hit box and the player.

What if I want it to be wider than the player, evenly, i.e: an arc-shaped swing, would adding to the height of the hitbox only make it extend upwards?

do I have to use the other format for the bounds proc to get what I desire? (bounds(x,y,width,height,z)

Do the x and y of that format represent tiles or pixels?

If it represents tiles, how do I make that location pixel offset to my mob?
Sep 5 2011, 4:23 pm
Ill Im wrote:
My questions:
is that 8 pixels going even further east, or should it fill in the 8 pixel-gap between the hit box and the player.

It's going farther east. Positive values will always travel East on the X axis, and North on the Y axis. Set the value to a -8 for proper closure.

What if I want it to be wider than the player, evenly, i.e: an arc-shaped swing, would adding to the height of the hitbox only make it extend upwards?

This is a 2:1 ratio. You must expand the box by at least 2. Expand by the width if facing East or West. Expand by the height if facing North or South.

This means that you must add 2 pixels onto the height or width or a box minimum, and for every 2 to expand it, you have to adjust it's position by 1 pixel. This will make it properly centered.

do I have to use the other format for the bounds proc to get what I desire? (bounds(x,y,width,height,z)

Not unless you plan on attacking potential mobs on higher or lower layers.

Do the x and y of that format represent tiles or pixels?

Pixels. Pixels can be calculated within a tile using the step_x and step_y variables.

If it represents tiles, how do I make that location pixel offset to my mob?

See above.
Sep 6 2011, 10:25 am
In response to Danbriggs
Danbriggs wrote:
This means that you must add 2 pixels onto the height or width or a box minimum, and for every 2 to expand it, you have to adjust it's position by 1 pixel. This will make it properly centered.

That's just it, I can't do that, you can't adjust the position of a box using the bounds(ref,x,y,width,height) format, only with bounds(x,y,width,height,z) format, I already know how to the properties of a centered arc work.
Sep 6 2011, 12:02 pm
In response to Ill Im
Try using the variables: bound_x; bound_y; bound_height; bound_width. Look them up in the News Post by Lummox if you're unfamiliar with them.
Sep 6 2011, 12:07 pm
In response to Danbriggs
So I have to change the player's bounding box just to get a functioning hitbox?
Sep 6 2011, 12:20 pm
In response to Ill Im
Yes, if not it will be a 32x32 box, which is probably not as accurate as you would like it.
Sep 6 2011, 1:06 pm
To find the bounds for a swing from one cardinal direction to another:

var/r = 16  // rod length
var/d = dir1 | dir2 // find the diagonal
var/dx=0, dy=0, dw=0, dh=0
if(d & (NORTH|SOUTH)) dh += r
if(d & (EAST|WEST)) dw += r
if(d & WEST) dx -= r
if(d & SOUTH) dy -= r

var/list/targets = obounds(src,dx,dy,dw,dh) - obounds(src)


That won't give you an actual circular arc, but it will give you a 24x24 box (minus the 8x8 where your character stands) for the hit. That also should give you the appropriate hit area when you aren't swinging in an arc. Note that dir1 and dir2 are expected to be cardinal directions, and dir1 and dir2 must not be opposite each other.
Sep 6 2011, 1:13 pm
In response to Lummox JR
Gawd, I was trying to write up a detailed description and you just gave it away.