ID:118051
 
Not Feasible
Applies to:Dream Maker
Status: Not Feasible

Implementing this feature is not possible now or in the foreseeable future
If you use step(src,NORTH,-10) it acts in the same way as step(src,NORTH,10).

I suggest that using step(src,NORTH,-10) would result in the same as step(src,SOUTH,10) however it would keep it's DIR variable, allowing it to face north whole moving south.

Basically, this would just cause you to move in the opposite direction without changing the iconsdirection, it would also help for those who use vel_y and vel_y as they often result in negative values. (ex: gravity)
This isn't exactly necessary (you can always use some if()'s to handle direction), but it would still be convenient.
src.Move(loc, dir, step_x + vel_x, step_y + vel_y)
Kaiochao wrote:
src.Move(loc, dir, step_x + vel_x, step_y + vel_y)

The problem with this is that you'll never be moved out of the tile.
Oh, it works. You just can't move greater than world.icon_size pixels, which really doesn't make angled projectiles work very well. Aside from the inaccuracy of rounding decimal values, calling Move() multiple times per tick seems to be a workaround.
Kaiochao wrote:
src.Move(loc, dir, step_x + vel_x, step_y + vel_y)

I tried this out and the issue is not being able to get the right loc for the argument in Move() as there's no way to find out what turf you're entering when adjusting by pixels.

In which case, an expansion to get_step that allows a pixel offset to be entered instead of a direction would solve this and allow Move() to be used in the way shown. I think there may be a feature request for that already though. I have to check.
Kaiochao wrote:
Oh, it works. You just can't move greater than world.icon_size pixels, which really doesn't make angled projectiles work very well. Aside from the inaccuracy of rounding decimal values, calling Move() multiple times per tick seems to be a workaround.

Like Bravo mentioned, the main problem is the loc variable in Move(), and the only workarounds are kind of annoying. Another annoying thing is that you cannot slide more than your atom's step size, as well, which means you have to make sure to change it. Also, there's a bug in the sliding I've noticed that has to do with movement sometimes failing for no reason.

EDIT: Nevermind, there was no bug, just a little oversight on my part.
I made a few procs to get around stuff like this, you can check it out here