ID:2149218
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
I've always had some problems with Move(). One of them is that BYOND lacks the ability to test for collisions, lacks the ability to force a movement to succeed, and another is that there is no good way to force a multi-tile, smooth gliding movement to occur.

I propose a minor overhaul to how the system works by adding a new argument to atom/movable/Move(): flags.

movement flags would be as follows:

MOVE_FORCE = 1 //forces the movement to succeed. Does not call Enter()/Exit()/Cross()/or Uncross(). Only Entered()/Exited()/Crossed()/Uncrossed() are called. If null is supplied as the loc, the mob will move to null space and Exited()/Uncrossed() will be called on all objects no longer being overlapped.
MOVE_TEST = 2 //checks whether this movement can happen, but does not actually move the mob.
MOVE_GLIDE = 4 //forces this movement to animate a glide regardless of the distance moved so long as the move is on the same z-layer.
MOVE_SLIDE = 8 //forces this movement to be a slide regardless of the step size.
MOVE_INSTANT = 16 //this movement will not glide regardless of the distance moved.
MOVE_TELEPORT = 32 //Do not break this movement up into multiple smaller movements if the step distance is greater than the step size. Only test the endpoints of the movement and do not call testing or notifier functions for anything in between.


It's currently much harder than it should be to use BYOND's movement system. With a few tweaks, lots of feature gap just closes right up.
I say just throw out all of byond's procs, manage that yourself, and while you're at it, you can throw out pixel movement and just manually manage bound checking and pixelxy =P

hell, toss out gliding and just animate() pixelxy

I already do most of that. The real trouble is that this behavior is incredibly useful and generic to the point of needing to be built in.

Overriding the default Move()/Enter()/Exit()/Uncross()/Cross() behavior is exceedingly difficult owing to the fact that the implementations are botched in the first place.
In response to Ter13
Ter13 wrote:
I already do most of that. The real trouble is that this behavior is incredibly useful and generic to the point of needing to be built in.

Overriding the default Move()/Enter()/Exit()/Uncross()/Cross() behavior is exceedingly difficult owing to the fact that the implementations are botched in the first place.

This is true
Turning glides on and off might be problematic, because gliding is a client-side phenomenon that merely happens in response to a movement. It might be doable, though it'd be important to establish how this should behave when a glide is followed by a non-gide, or vice-versa, if two movements happen before the client gets its update.