Bounds dist.

ID:817800
 
Jun 15 2012, 8:14 pm
(See the best response by Forum_account.)
\What exactly is the shortest (Or most efficient) way of seeing the bounds_dist() between atoms A and B before moving, and what the bounds_dist() between atoms A and B would be after moving?

My reason for asking is that my movement system works well, but if you get snug up against (for example) the EAST side of a dense object and try to go NORTH or SOUTH, it won't let you because it still sees that dense object in your obounds(). I want to be able to tell the code to say "Is this object that they can't enter any closer after they step? Oh, it isn't? Okay, let them move.".

For whatever purpose it may serve, I'll post what little progress I have on this.
mob
    can_move()
        . = TRUE
        if(velocity_x != 0 || velocity_y != 0)
            for(var/atom/a in obounds(src, velocity_x, velocity_y))
                if(a.elevation > src.elevation)
                    . = FALSE
Jun 16 2012, 12:44 am
Have you tried setting bound_x, bound_y, bound_width and bound_height for both mob and density? I don't really understand your question,

"Is this object that they can't enter any closer after they step? Oh, it isn't? Okay, let them move." Do you want it to tell if they are close to each other (too close?) then determine if they should move? If yes, there are many simpler workarounds.
Jun 16 2012, 4:10 am
I can already tell if they are close to each other. However, can_move() blocks movement if it sees an object in your next step that you can't enter. As such, if you get close to that object and then try to go a different direction other than the opposite one (I.e. you approach the object going WEST and then try to go NORTH or SOUTH), it stops you because it sees that object in your step still. In reality, the object isn't getting any closer, you are just sliding along it. I just need to check if the distance between you and the object will be any closer after you step, and if not, then let you step.
Jun 16 2012, 4:22 am
Albro1 wrote:
if you get snug up against (for example) the EAST side of a dense object and try to go NORTH or SOUTH, it won't let you because it still sees that dense object in your obounds()

If there's an object to your right and you're moving up, your call to obounds should exclude the object on your right since you're only shifting the bounding box up, not to the right. If you tried to move up and right it'd have the dense object in your obounds and prevent the move, are you trying to avoid that case?
Jun 16 2012, 4:30 am
well, you could use something like for(var/obj/o in src.step_size)? Then check for density and do whatever. Normally, the next step's covered distance is determined by step_size.

edit1: If you want to check how far it is in two steps, you can use var/step = src.step_size*2, aye? Also, if you plan on calling this proc every step, expect an amazing amount of lag.
Jun 16 2012, 5:14 am
In response to Avainer1
Avainer1 wrote:
Also, if you plan on calling this proc every step, expect an amazing amount of lag.

Why would this lag?

The code isn't doing that much. Assuming you always have a non-zero velocity it'd probably take ~50 microseconds to run (that's 1/20th of a millisecond). If you're running at 30 frames per second, each tick is 16.667 ms. Using 0.05 ms every tick means you're using 0.3% CPU usage.
Jun 16 2012, 5:16 am
my bad.
Jun 16 2012, 9:52 am
In response to Forum_account
Forum_account wrote:
If there's an object to your right and you're moving up, your call to obounds should exclude the object on your right since you're only shifting the bounding box up, not to the right. If you tried to move up and right it'd have the dense object in your obounds and prevent the move, are you trying to avoid that case?

That's what I would think, but it seems to be including it for some reason. I don't have any clue as to why, but being able to check if I'm any closer to it would void this issue.

Also, Avainer, I don't see that loop working. You are basically saying:
for(var/obj/o in 4)
step_size is a numerical value, and it can't contain an object.
Jun 16 2012, 1:32 pm (Edited on Jun 16 2012, 1:39 pm)
Oh my bad. Forgot to add the last part. for(var/obj/o in oview(src.step_size)
Jun 16 2012, 1:51 pm
In response to Albro1
Albro1 wrote:
That's what I would think, but it seems to be including it for some reason. I don't have any clue as to why, but being able to check if I'm any closer to it would void this issue.

Being able to check if you moved closer is a much costlier way to accomplish this. If it's listing objects you're not actually going to hit, that's the problem you should be trying to fix. What are you ultimately trying to accomplish? It seems like this all has been done before.
Jun 16 2012, 6:35 pm
It's a simple elevation system. If the object has a higher elevation, you can't enter it. The game checks what your next step should be via obounds(src, velocity_x, velocity_y) and determines if an object of higher elevation is there. If so, it won't let you move.
Jun 16 2012, 6:40 pm
Can't you do that with just Cross() and Enter()? I'm not sure why you'd need to use velocities to check bounding boxes.
Jun 16 2012, 6:41 pm
Those procs aren't called when directly modifying step_x and step_y.
Jun 16 2012, 6:51 pm
So don't modify them directly. I feel like I'm missing something.
Jun 16 2012, 6:53 pm
If I use step() then the direction is modified, which doesn't work when I do things like jump. I am also looking for the ability to move in ways that aren't in the normal directions - such as when your velocity_x is 10 and your velocity_y is 2. Doing step(src, NORTHEAST) just isn't the same.
Jun 16 2012, 7:04 pm
Best response
You can use Move(), something like this:

mob.Move(loc, dir, step_x + velocity_x, step_y + velocity_y)

Or you can use the Pixel Movement library, which supports diagonal moves and elevation.
Jun 16 2012, 7:49 pm
In response to Forum_account
Forum_account wrote:
You can use Move(), something like this:

> mob.Move(loc, dir, step_x + velocity_x, step_y + velocity_y)
>

Or you can use the Pixel Movement library, which supports diagonal moves and elevation.

Hoo boy, time to start fixing things up. For whatever reason including the library (This mean un-including most of my movement stuff) screwed up the map at runtime. This is why I never liked plugging in libraries mid-way through a project. Oh well, it must be done.
Jun 17 2012, 4:39 am
You should be able to just remove your movement code and change the elevation var to be the pdepth var. You might also need to set the pwidth and pheight of objects, I'm not sure if it'll automatically grab values from other vars for them.

Why didn't you use the library from the start? Did you somehow not know about it?
Jun 23 2012, 11:14 am
In response to Forum_account
Forum_account wrote:
You should be able to just remove your movement code and change the elevation var to be the pdepth var. You might also need to set the pwidth and pheight of objects, I'm not sure if it'll automatically grab values from other vars for them.

Why didn't you use the library from the start? Did you somehow not know about it?

I knew about it, but I was going with a native approach to things. I've pretty much got the code converted to work as it did with your library, I just have to fix some things like landing on sides of buildings (should make you slide down) and a proc to be called when they land so I can execute damage. I also need to work on bigger objects. I have a building with large bounds, and when I run into the bottom and right sides, I go into it and am pushed back, and while not very important, it is very ugly. I also had to convert pixel_y to step_y, because I wanted the camera to follow their mob. A few other things and everything should be as it was.