Immovable

ID:273636
 
Nov 14 2010, 8:53 am
Is there anyway to prevent a player from being able to move at certain times, without making the areas around it dense? I am trying to make it so that the player cant move when a part of the storyline comes up, but i don't know how. Can anyone help?
Nov 14 2010, 9:26 am
I've commented the code so you can better understand it. You'll have to set the variable yourself whenever you want a mob to be frozen.

mob

    var/frozen = 0 // frozen variable

    Move() // movement proc (called anytime a mob moves)

        if(src.frozen) return // if they're frozen, they can't move

        else ..() // otherwise, let them move freely
Nov 14 2010, 9:38 am
In response to The Unknown Ninja From Hell
Ah. I thought that that was how it would be implemented, but i wasn't sure which proc/s it should change.
Nov 14 2010, 10:40 pm
In response to The Unknown Ninja From Hell
Given that the OP asked for restricting 'player initiated movement', wouldn't it be a a better idea to override client.Move() instead and thus leave the ability to handle 'default server initiated movement'?
Nov 14 2010, 11:25 pm
In response to The Unknown Ninja From Hell
In addition to Schnitzelnagler's criticism, Move() (both the movable atom and client versions) has a return value and it's important to actually return it, or you can subtly break a wide variety of procedures. So an improved version of your code:

client
    var
        tmp/frozen = 0 // 'tmp' makes sure this can't get saved with the client

    Move(loc, dir) // Move takes arguments
        if(frozen) return 0 // If we're frozen, return a value indicating movement failure
        
        return ..(loc, dir) // Call the parent and return it
Nov 18 2010, 10:14 am
In response to Jp
While we're adding in general improvements... ;)

Jp wrote:
>         return ..(loc, dir) // Call the parent and return it


For robustness, you should avoid manually specifying the arguments to ..() when possible. See here: [link]

Of course, it's not particularly problematic here, but it's still potentially problematic, thus less robust, thus less desirable.