About bbox

O Ilusionista

Captain 100K
Today, an old post by uTunnels got my attention:

utunnels said:
bbox is not a 2d box, it has its thinkness, so instead of the default setting, you can change it manually.

bbox  x y width height z1 z2

So BBOX accepts 6 values, not 5? If so, its wrong in every manual:

bbox {x} {y} {right} {down} {z}

~Determines where the entity can be hit.
~{x} and {y} are the x and y coordinates of the top left corner of the box, starting from the top left corner of the frame and moving right/down. {right} is how far to the right of {x} the box extends. {down} is how far down from {y} the box extends.
~{z} determines how wide the hit area in z axis. It extends to back and front. For instance, setting z to 20 means, the attackbox can hit 20 pixel away to back and front. NOTE: the axis of this z is not same with levels' z axis.
~You can use negative numbers or numbers outside of the frame's edges. This can save a bit of memory by shaving a few excess rows or columns of pixels off an animation.
~Can be used multiple times in one animation to change hittable areas mid-animation.
~To give an entity frames where they cannot be hit, use 'bbox 0 0 0 0 0'. Be sure to add a new bbox when the entity is vulnerable again.
~For items, this determines where the object can be picked up from.

Someone can explain it to me?
 
I looked in the source code and found that the answer is...both!  The function of the fifth parameter changes based on whether there is a sixth parameter.  A bbox defined with five parameters will treat the fifth parameter as described in the manual.  A bbox defined with 6 parameters will treat the fifth and sixth values as min and max values of a range, as utunnels described.

Well, technically, what the engine really checks here is whether the value of the 6th parameter is greater than the value of the 5th.  It works out for correct usages, since unspecified parameters default to zero and the 5th value in the 5-parameter usage is supposed to be non-negative.  If someone were to misunderstand the manual and use a negative z value with the 5-parameter usage, they would be in for a nasty surprise!

Relevant code snippet from the source code (keep in mind that arrays start at 0, so coords2[4] is the 5th value from the bbox command):

Code:
if(coords2[5] > coords2[4])
{
    z2 += coords2[4] + (coords2[5] - coords2[4]) / 2;
    zdist += (coords2[5] - coords2[4]) / 2;
}
else if(coords2[4])
{
    zdist += coords2[4];
}

 
Plombo, did you happen to see this? IMO it would help immensely, especially when it comes time to decipher code for questions like this.

DC
 
Damon Caskey said:
Plombo, did you happen to see this? IMO it would help immensely, especially when it comes time to decipher code for questions like this.

I did!  The amount of effort it took to decipher that code directly inspired me to start working on your suggestion.  In fact, as coincidence would have it, I was working on it as you posted, and it's committed to SVN now. :)

EDIT: Apparently I was too hasty in committing it, because I accidentally broke the build.  Sorry, fixing now.

EDIT 2: Now fixed.  I didn't really test the changes aside from a quick sanity check, though; hopefully I didn't break anything.
 
so I assume the first z is extending symmetrically? If set to 10 then the width in z is 20, +/-10?
I did not know that you can use a second z too. that will be handy :)
 
Back
Top Bottom