Um, I want the user not to move when he presses the directional keys. When var/train=1.

I know it has something to do with client.Move() because i did this before but i forgot. Please post a little to help me remember.
In response to A.T.H.K
That will fail always.
if(train) return 0
return ..()
In response to Popisfizzy
Right, Thanks for both of your responses.
In response to Lcooper
Perhaps you'd like a little explanation of how that works, though?
..() means "call the parent procedure" (if there is no actual DM parent, and the proc is a built-in one, it will call the original built-in version of the proc). It's used in an override to call the actual "main" proc itself (of course, it has no effect in an initial proc definition). Pop's code stops the procedure and returns false (0) if train is true, this is to notify the caller of the proc (Move()) that the movement failed, as per the original proc that also does this. This allows the caller to easily know if the Move() failed or not. If train is false, though, it returns the value of the parent proc (which is also an indicator of whether the move succeeded or not of course), carrying out the actual movement in the process (since the code under the if() has return which stops the code, the code under it will only run if the if() failed).

It would probably be a good idea to override client/Move() instead of mob/Move() for this, because the former is only called when a player attempts to move through a movement command, but the latter is called whenever any mob ever tries to move, which might cause some code in your game to fail, so bear that in mind if you stay with mob/Move().
In response to Kaioken
Also, I'm guessing this is for when a mob is training (or on a train XD), you should implement a lock var instead of a new var for every single thing in your game that blocks a player's movement.
(use client like he said.)
if(src.mob.locked)//instead of train
return 0
In response to Naokohiro
Sure, but, this isn't really rocket-science to figure out, or any difference in the current code apart from the variable name. =P
And pay attention to return ..(), it is important to have, otherwise the return value is lost and the caller will falsely think the movement failed even if it may have succeeded (if you don't return anything, null, which is false, is returned by default).
In response to Kaioken
You don't need to return it, my code works fine like this:
return 0

Unless you had something like if(client.Move()) for some reason...
In response to Naokohiro
Naokohiro wrote:
You don't need to return it, my code works fine like this:

You don't need to do it for that proc itself to work. But you possibly need to do it for other procs to work, properly that is.

Unless you had something like if(client.Move()) for some reason...

The fact the original client/Move() procedure returns the success (or lack of it) is enough for you to make your code robust and pass it on as well. Code should be flexible, sturdy and avoid potential problems or inconsistencies.
Also, calling client/Move() 'for some reason' whatever it may be can be perfectly valid, like calling the mob/obj version is. It would probably be the better choice if you're making a "custom" movement command (verb) of some kind, and as such.
In response to Kaioken
Alright, I understand, I just had no use for it.
Guess, I'll add that to my code as well...