immobile

ID:160498
 
Aug 31 2008, 6:00 am
There is probably a very simple answer to this and I'm just missing something very key, but I'm asking just because I can't find the answer anywhere else.

How would I temporarily make the usr immobile without having to re-define all the directions under Client?

And if that's not possible, what do I have to put under the Client definition for each direction to get them to act normally?
Aug 31 2008, 6:05 am
 
mob/var/Cant_Move=0 //Your allowed to move
mob/Move()
    if(src.Cant_Move) return //Dont allow movement
    else .=..() //If they can move, let them

Is that what your talking about?
Aug 31 2008, 6:23 am
In response to DemonSpree
That is what I was talking about. Thanks.

I didn't even think about using the ...() function. I remember having to use it in Zilal's beginner tutorial, but I had no idea what it mean...that was 4+ years ago, and I still don't understand it! I mean, I do now, but it took me long enough!
Aug 31 2008, 6:40 am
In response to DemonSpree
The horror, ugh! Okay, it's not really 'horrible' at all, but I'm just tired of seeing the same issues again and again. >_>

mob/var/move = 1
client /*override the client proc!!! overriding mob/Move() will limit and potentially break not only player-initiated movement, but actions from your code such as 'special' player movements, AI movements etc. overriding client/Move()
only affects movement initiated through movement commands
sent by a player.*/
   Move()
     if(src.mob.move)
        return ..() //no reason at all to use '.' here... and why at the end of the proc?!
     //basically that's all, but you can include an optional\
     line for a tiny weensy more robustness
     return 0
Aug 31 2008, 6:50 am
In response to Powerbraclet
Powerbraclet wrote:
That is what I was talking about. Thanks.

I didn't even think about using the ...() function. I remember having to use it in Zilal's beginner tutorial, but I had no idea what it mean...that was 4+ years ago, and I still don't understand it! I mean, I do now, but it took me long enough!

I completly understand you there, lol I've been away from coding for 3-4 years and i'm super rusty when it comes to coding myself, lol. I forgot about how to do immobile coding also, well anyways, thanks for bring this topic also, becasue I forgot bow to do it also ^.^

well anyways good luck ^.^
Aug 31 2008, 9:15 am (Edited on Aug 31 2008, 9:21 am)
In response to Powerbraclet
Powerbraclet wrote:
That is what I was talking about. Thanks.

I didn't even think about using the ...() function. I remember having to use it in Zilal's beginner tutorial, but I had no idea what it mean...that was 4+ years ago, and I still don't understand it! I mean, I do now, but it took me long enough!

To expand on Kaioken's response, the .. proc calls the datum's parent. In some cases, there is no parent to call; for instance, client/Command and New() (with the exception of client/New) have no predefined action on their lonesome, so calling the datum's parent does nothing in some cases. There are also situations where there isn't a parent to call, as well.

However, as you override and define procs for your own use, you may create your own parent trees that you may want to manipulate. A simple example:

mob
    Move(newloc,direction)
        //there's better ways to do this, but this just an example after all
        if(direction != WEST) ..(newloc,direction) //dont let anyone move due westward!
    player
        var/can_move = 1
        Move(newloc,direction)
            if(src.can_move) ..(newloc,direction) //call the parent, which happens to be mob/Move

In addition to /mob/player having a restriction of being unable to move if can_move is false, we can manipulate the parent, which doesn't let -any- mob move west. The parent of mob/Move is atom/movable/Move, which handles all the fun stuff like calling turf/Entered, which is what mob/Move is calling here. As explained above, there are situations where there is no parent to call -- in the scope of this example, atom/movable/Move has no parent.

The use of . simultaneously is another issue. In the case of the example above, Move() only returns true or false depending on whether or not the movement succeeded, so its' return value isn't particularly useful in most cases. The . variable is basically a way to return a value without explicitly calling return, and I believe . is still returned to the calling proc if src gets destroyed, as well.

There's a lot more to be said on this matter, but I think I've given you enough to mull over for right now.
Aug 31 2008, 12:32 pm
In response to Mobius Evalon
Mobius Evalon wrote:
Powerbraclet wrote:
That is what I was talking about. Thanks.

I didn't even think about using the ...() function. I remember having to use it in Zilal's beginner tutorial, but I had no idea what it mean...that was 4+ years ago, and I still don't understand it! I mean, I do now, but it took me long enough!

To expand on Kaioken's response, the .. proc calls the datum's parent. In some cases, there is no parent to call; for instance, client/Command and New() (with the exception of client/New) have no predefined action on their lonesome, so calling the datum's parent does nothing in some cases. There are also situations where there isn't a parent to call, as well.

However, as you override and define procs for your own use, you may create your own parent trees that you may want to manipulate. A simple example:

mob
>   Move(newloc,direction)
>       //there's better ways to do this, but this just an example after all
>       if(direction != WEST) ..(newloc,direction) //dont let anyone move due westward!
>   player
>       var/can_move = 1
>       Move(newloc,direction)
>           if(src.can_move) ..(newloc,direction) //call the parent, which happens to be mob/Move

In addition to /mob/player having a restriction of being unable to move if can_move is false, we can manipulate the parent, which doesn't let -any- mob move west. The parent of mob/Move is atom/movable/Move, which handles all the fun stuff like calling turf/Entered, which is what mob/Move is calling here. As explained above, there are situations where there is no parent to call -- in the scope of this example, atom/movable/Move has no parent.

The use of . simultaneously is another issue. In the case of the example above, Move() only returns true or false depending on whether or not the movement succeeded, so its' return value isn't particularly useful in most cases. The . variable is basically a way to return a value without explicitly calling return, and I believe . is still returned to the calling proc if src gets destroyed, as well.

There's a lot more to be said on this matter, but I think I've given you enough to mull over for right now.

In my opinion, i Would of put the "if(src.can_move) etc... in a proc, that way if you have to use the can_move in multiple instances, you don't have to clutter up the code.
but that's my opinion ^.^
Sep 1 2008, 3:54 am
In response to ElderKain
? I don't get you, it doesn't make sense. Checking if one variable holds a true value is a simple expression with only a single instruction ( if(Variable) ). It is not cluttered at all, and doing something to make it shorter is quite overboard (and you'd do such things with a #define rather than a proc, as the latter would make that otherwise fast action needlessly slower).

Also, because of what the code does if the check is true, it's actually impossible to farm it out to a proc anyway. But you have no reason to do that... what is bad with repeating if(Var) again? Is there a difference between that and repeating if(Proc) instead?
Both questions rhetorical: the answer to both is no.
Maybe you were referring to the repeated args in the ..() call? In that case, the arguments in ..() are optional anyway, if you include none then it passes all of them automatically. And of course, you can't farm out the ..() call to another proc, because ..() is specific to a given proc... well, if you understand ..() you should get what I mean.