ID:157261
 
To cut a long story short, im having issues with my use of x & y movement by ++ / --

So..

usr.x++
usr.y--

etc...

This is so the player can move up/down/left/right without actually facing that direction. They are on bikes, driving. So this would be the equiv of changing lanes.

The issue is that by using x++ and y++ etc they can pass through dense turfs and objects.

Any thoughts on a possible simple/fast solution?
var/turf/a = locate(x,y++,z)
if(a&&(a.density||(a.loc&&a.loc.density))) return 0
else y++


alternative, just use Move()

Move(locate(x,y++,z))
In response to Emasym
Emasym wrote:
var/turf/a = locate(x,y++,z)
> if(a&&(a.density||(a.loc&&a.loc.density))) return 0
> else y++


Thanks for that, but you will have to give a little explination here i think. I'm not sure i understand.
You have players which are on a bike, and you want them to be able to move in any direction without changing their direction.

The first question I have is if usr is necessary here. Avoid overusing it!

As for your problem I'd recommend using the following code:
mob.Move(get_step(mob, direction), mob.dir)
This should cause mob to move into the direction of direction and not change their existing direction. The second argument supplied to the Move() proc overrides the direction they're going to face.

Tip #1: Always use the Move() proc and don't rely on setting loc. Move() double-checks if a player can be moved somewhere and even in cases where you don't want this it can be helpful to have the appropriate Exit(), Exited(), Enter() and Entered() procs called in succession. I've had problems in the past in projects where I needed to forcibly move someone and ended up setting loc. The result was that every time I did that I started working with area.Entered() or area.Exited() that I had to rework that code. Nothing stops you from overriding Move() at the highest level (/atom/movable) and adding your own parameters to handle forced movement.
In response to Android Data
Android Data wrote:
You have players which are on a bike, and you want them to be able to move in any direction without changing their direction.

The first question I have is if usr is necessary here. Avoid overusing it!

As for your problem I'd recommend using the following code:
mob.Move(get_step(mob, direction), mob.dir)
This should cause mob to move into the direction of direction and not change their existing direction. The second argument supplied to the Move() proc overrides the direction they're going to face.
Tip #1: Always use the Move() proc and don't rely on setting loc. Move() double-checks if a player can be moved somewhere and even in cases where you don't want this it can be helpful to have the appropriate Exit(), Exited(), Enter() and Entered() procs called in succession. I've had problems in the past in projects where I needed to forcibly move someone and ended up setting loc. The result was that every time I did that I started working with area.Entered() or area.Exited() that I had to rework that code. Nothing stops you from overriding Move() at the highest level (/atom/movable) and adding your own parameters to handle forced movement.

Ah ha! that worked perfectly. Thankyou.
In response to EternalDuelistSoul
Another tip: don't "reply with quote" if you're not going to reply directly to anything I said. Just use the "reply" button; it'll still tell us that you've replied to me because the parent ID = my posts' ID. It avoid a whole lot of clutter!