macros and stoping movement

ID:165630
 
Nov 20 2006, 11:51 pm
I need help on setting macros and stopping people from moving.


Please help
Nov 22 2006, 12:38 am
bump
Nov 22 2006, 1:06 am
In response to Jatyu
For locking a player's movement you would create a var such as "frozen" and make it so if they are frozen, they can't move. Like this: 
mob
    Move()
        if(src.frozen==1)
            src<<"You are frozen in place!"
            return
        else
            ..()
This is a very simplified code, I'm sure there are more flashy ways of locking movement, but that's the basic code to lock all of a player's movement. By the way, that's only arrow keys it locks, if there's an alternative movement, you'll have to lock that too. By seeing this you should be able to figure that out.
Nov 22 2006, 3:56 am
In response to Muyoine Guyinne
Two words for you: Boolean Shortcuts. You're advice is easy to break, and will do so at the soonest moment.

That said, a Boolean shortcut is simply an easier and more robust way to utilize Boolean vars.

!bool is translated as 'NOT bool'. This will evaluate to 1 if bool is 0, "". or null.
bool is translatec as 'bool'. This will evaluate to 1 if bool is non-zero, a non-empty string, or non-null.
Nov 22 2006, 5:01 am
Macros are set with DM scripts. You can choose to either set client.script directly to text, or to set it to a .dms file you create in the sourcecode. Either way, macros go like this:

macro
    s return "say \"\..."
    q return ".logout"
    space return "fire"


In this case, you can press "s" to use the "say" verb. It will change the text on the pink textbox and will allow you to type your message. Pressing "q" should log you out (I haven't tried this myself, otherwise you'll have to make it a hidden verb). Pressing the spacebar uses the "fire" verb (if any).

In order for these macros to work without having to hold the ALT key, you'll have to set client.command_text to .alt.



To prevent a player from moving, you may override the client.Move() proc. This proc is executed whenever a player uses one of the movement commands (.north, .west, etc.). These commands are usually bound to the arrow keys.

Override mob.Move() if you want to prevent the players' character from moving no matter what. You probably only want to override client.Move() to just block the player from moving his/her character.

client/var/move=1
client/Move()
    if(!move)return 0
    return ..()


In this case, one may set client.move to 0 to prevent the player from moving.
Nov 22 2006, 5:04 am (Edited on Nov 22 2006, 5:10 am)
In response to Muyoine Guyinne
Muyoine Guyinne wrote:
... 
>   Move()
>       if(src.frozen==1)
>           src<<"You are frozen in place!"
>           return
>       else
>           ..()

--------------------
That code can be shortened a bit. Get rid of the "==1", it will still check if the var is TRUE. You don't need the else statement, since if frozen IS true then the proc would have returned and never reached the 'else' statement anyway. And swap "..()" with "return ..()", so the return value will be the right one in case the caller wishes to check it.

Also, by the way, actually, it doesn't lock ONLY the arrow keys. It locks all movement (except when manually setting the 'loc' variable, which usually isn't adviced). To specifically block the movement commands only (called by arrow key macros) use client/Move() (note that firstly the direction procs are called, such as client/Southwest(), and they call client/Move() with the appropriate dir, which does eventually, by default, call atom/movable/Move(). If you wanted you could specifically override the direction procs like Southwest(), but in my opinion it's easier to get things done with the Move() procs).

EDIT: Heh, Android was quicker. :P
EDIT2: We even commented on EDIT1 on the same time. o.O
To correct you a bit though, to force/turn macro mode on, command_text needs to be set to ".alt ". If you don't have the extra space on the end then it won't work, for some reason it was apparently designed like that.
Nov 22 2006, 5:05 am
In response to Kaioken
Kaioken wrote the same as I wrote but in a different way.

:(