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?
ID:157261
Apr 13 2010, 6:52 am
|
|
In response to Emasym
|
|
Emasym wrote:
var/turf/a = locate(x,y++,z) 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) 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. mob.Move(get_step(mob, direction), mob.dir) 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!
|
alternative, just use Move()