Dynamic Bounding Boxes

ID:1493550
 
Feb 9 2014, 5:05 pm
(See the best response by Ter13.)
Code:
        switch(Ref.dir)
            if(NORTH)
                Ref.bound_x = initial(Ref.bound_x)
                Ref.bound_width = initial(Ref.bound_width)
                Ref.bound_y = world.icon_size - initial(Ref.bound_y)
                Ref.bound_height = - (initial(Ref.bound_height))
                return
            if(EAST)
                Ref.bound_x = initial(Ref.bound_x)
                Ref.bound_width = initial(Ref.bound_height)
                Ref.bound_y = initial(Ref.bound_y)
                Ref.bound_height = initial(Ref.bound_width)
                return
            if(SOUTH)
                // South moving objects will get their bounds reset to default values
                Ref.bound_x = initial(Ref.bound_x)
                Ref.bound_width = initial(Ref.bound_width)
                Ref.bound_y = initial(Ref.bound_y)
                Ref.bound_height = initial(Ref.bound_height) 
                return
            if(WEST)
                Ref.bound_x = world.icon_size - initial(Ref.bound_x)
                Ref.bound_width = - initial(Ref.bound_height)
                Ref.bound_y = initial(Ref.bound_y)
                Ref.bound_height = -initial(Ref.bound_width)
                return


Problem description:
Started this as a test run for my dynamic bounding boxes. When used on the player, the player can skip through things and the client eye jumps all over the place. Is there anything logically wrong with this?
Feb 9 2014, 5:22 pm
Best response
you can use a shorthand to assign bounds:

Ref.bounds = initial(Ref.bounds)


It's a somewhat undocumented usage of the bounding data.

And yeah, for dynamic bounding boxes you are going to run into some problems with the eye positioning and collision. Unfortunately, changing bound data is somewhat... Well, buggy.
Feb 9 2014, 5:24 pm
That's nice. Guess I'll just have to handle it the old fashioned way for reliability :/
Feb 9 2014, 7:39 pm
Actually, forget what I wrote before. That was a terrible way to do it.

Here is a proc that should make it easy to change the bounds var directly:
atom/movable
    proc
        set_bounds(bx, bw, by, bh)
            if(!(isnum(bx) && isnum(bw) && isnum(by) && isnum(bh))) return
            src.bounds = "[min(bx, bx + bw)],\
            [min(by, by + bh)] to \
            [max(bx + bw, bx)],\
            [max(by + bh, by)]"

The arguments for set_bounds() correspond to the same format as the individual built-in vars, so it works with the code you wrote:
        switch(Ref.dir)
            if(NORTH) 
                Ref.set_bounds(
                bx = initial(Ref.bound_x),
                bw = initial(Ref.bound_width),
                by = world.icon_size - initial(Ref.bound_y),
                bh = -initial(Ref.bound_height))
                return
            if(EAST)
                Ref.set_bounds(
                bx = initial(Ref.bound_x),
                bw = initial(Ref.bound_height),
                by = initial(Ref.bound_y),
                bh = initial(Ref.bound_width))
                return
            if(SOUTH)
                // South moving objects will get their bounds reset to default values
                Ref.bounds = initial(Ref.bounds)
                return
            if(WEST)
                Ref.set_bounds(
                bx = world.icon_size - initial(Ref.bound_x),
                bw = -initial(Ref.bound_height),
                by = initial(Ref.bound_y),
                bh = -initial(Ref.bound_width))
                return

Now you can change all four vars simultaneously, so it should be less buggy.

However, I suspect the reason this kind of thing might be buggy is because of the default behavior of procs such as Cross() and/or Uncross(). Anything that makes use of density might be an issue.

Either way, it would be interesting to see if something like this could be made to work.
Feb 10 2014, 6:41 am
Why would you be changing bounds if you didn't want to fiddle with density? I'm having an issue thinking of some other time that bounds comes into play than with density. Unless you're fiddling with say a large non-dense object (perhaps a box) that people can "stand inside" (occupy the same turfs) and use the bounds to return that list. But other than that, I can't imagine why bounds makes a difference.
Feb 10 2014, 7:52 am
In response to Lugia319
Bounds define where the object physically exists. This can be useful for triggers (as they're called in Unity), which detect when objects enter (Crossed) to do something. Like a pressure plate that doesn't occupy exactly one tile (could be smaller or larger). So you have the idea, but it's more useful than you might think.