WAIT

Syntax: #WA

Delays processing of further commands on the line until text is received from the MUD. Sometimes commands from zMUD can be executed too fast for the MUD. This command is used to slow them down.
If the time parameter is specified, the processing of further commands on the line is delayed the amount of time specified. Time is in units of milliseconds - e.g. 1000 is 1 second. Note that the commands remaining on the line are queued up for this time. You can still enter other commands on the command line while waiting.

NOTE: The WAIT command can cause processing of any other active WAIT command to halt. Do not use nested WAIT commands. Do not use the WAIT command in a trigger if the same trigger might fire again before the WAIT is complete. In general, you should try to use the #ALARM command instead of using #WAIT.

WAIT examples

west;#WA;kill citizen

sends the west command to the MUD, then waits for some output from the MUD, then sends the kill citizen command. Without the #WA command, on some MUDs the kill citizen would be sent before you actually moved west.

#WA 2000;kill citizen

wait for 2 seconds, then send the kill citizen command to the MUD


#LOOP 10 {kill %{i}.bear;#WAIT 5000}

sends the commands "kill 1.bear", "kill 2.bear", "kill 3.bear", etc, but with a 5 second delay between each "kill" command.

ALARM

Syntax: #ALA pattern
Related: #TRIGGER #SUSPEND #RESUME

Allows you to set up a trigger based upon the time, rather than what is received from the MUD. The timepattern can contain a specific time, or can include wildcards as shown below. If preceded with a minus (-), the connection time is used rather than the current time.
Typically, the timepattern has the format hours:minutes:seconds, although the hours and minutes are optional. If missing, the hours or minute parameter is assumed to be an asterisk wildcard. In place of a specific numeric value, you can use an asterisk to match any value. You can also use the special wildcard *value which will match when the time MOD the value is zero. E.g. *10 matches 10, 20, 30, etc. The smallest period of time that can be matched by an alarm is half a second.

You can also define a temporary, one-time alarm by specifying a plus (+) in front of the time. The command is executed when the alarm goes off and the alarm is then deleted.
Using options with alarm type triggers is useless as they are ignored but the command syntax supports them.
When used with only id and pattern parameters it changes the pattern of the specified alarm.
Note: #ALARM does not preform any expansion on it parameters at the time of creation. If you need a parameter expanded use a syntax similar to the #EXEC example below.

ALARM examples

#ALARM -30:00 {save}

The hour isn’t specified, so it defaults to *. Thus, this trigger saves your game every 30 minutes of connect time.

#ALARM 3:00:00 {gossip "Why aren’t you sleeping?"}

This triggers at 3am local time.

#ALARM +5 {save}

Executes the "save" command in 5 seconds. This is a one-time alarm that deletes itself once it has executed.

#ALARM example {*5} {#ECHO example}
#ALARM example {+3}

Creates an alarm that will fire every 5 seconds then changes the time pattern for that alarm.

#VAR temp 5
#ALARM +@temp {@spell}

Executes the command stored in @spell in @temp seconds. This is a one-time alarm that deletes itself once it has executed. Note that @temp is not expanded in the display of the pattern but is expanded internally, so changing temp will not affect when the alarm triggers. In order to change when an alarm triggers try %alarm.

#EXEC {%concat(":Tells:#ALARM +",@temp," {#CLR}")}

A contrived example. This demonstrates how to create an alarm in another window, with a variable from this window.

The #WAIT Command

Ahh, the dreaded #WAIT command. This is probably the most heavily abused command in zMUD, and the cause of many scripting problems. Early versions of zMUD did not have the #ALARM command, so only the #WAIT command could be used. The general rule of thumb now is: DO NOT USE #WAIT UNLESS YOU MUST! Repeat this to yourself 10 times.

OK, if you promise not to use the #WAIT command, I'll go ahead and tell you how it works and what it is really used for. The #WAIT command is used for adding delays to loops in zMUD. That's all. Any other time delay can be accomplished using the #ALARM and Trigger Wait condition.

So, if you wanted to send the numbers 1-5 to the MUD with a one-second delay between each number, you would do this:

#LOOP 1,10 {%i;#WAIT 1000}

There is no easy way to do this using the #ALARM command, so you are allowed to use #WAIT for this. Do NOT use #WAIT within a trigger!!

Repeat: DO NOT USE #WAIT WITHIN A TRIGGER! Why? Here is a simple example:

#TRIGGER {You lose concentration} {#WAIT 5000;recast spell}

Now, we all know you can do this using a Wait condition like this:

#TRIGGER {You lose concentration}
#CONDITION {} {recast spell} {Wait|Param=5000}

or you could use an alarm like this:

#TRIGGER {You lose concentration} {#ALARM +5 {recast spell}}

But, since we are talking about the evils of the #WAIT command, lets look at the #WAIT example. If you run it, it seems to work. So what is the problem? What happens if you get the text twice before the 5 seconds is over. For example:

You lose concentration
<3 seconds later>
You lose concentration

Perhaps you tried to execute a spell twice? Now, if Windows was a perfect system, what we expect to happen is that the command "recast spell" is sent 5 seconds after the first text, then sent again 5 seconds after the second text. But this isn't what happens. Because of how Windows works (as we'll see in a minute), you get the command "recast spell" sent twice, 8 seconds after the initial text (the 3 second delay between the text plus the 5 second delay in the #WAIT command).

So what happened? Why did the #WAIT command from the first text get displayed 8 seconds later along with the second one? Well, the #WAIT command tells Windows to pause for the given amount of time. But Windows continues to process messages (to avoid freezing the application). 3 seconds later you get the second message, and this causes the #WAIT command to run again, pausing Windows for 5 seconds. But Windows only has a single execution thread by default. So, while that second command is waiting for 5 seconds, the original wait command is also waiting. When the second command is done, it then returns to the first command, which notices that more than 5 seconds is up and executes. So, both triggers wait the full 8 seconds.

If zMUD was multi-threaded, this wouldn't be a problem. Each #WAIT command could run in a separate thread and then they wouldn't interfere. But multi-threaded programs are *very* complex to write, and zMUD was originally written before threads were available. In particular, different threads cannot access the same resource without complex locking and synchronization, and the screen output is one of these resources. Trying to resolve the synchronization problem so that each thread could write to the screen would be enormously difficult.

So, just don't worry about any of this technical jargon. Just stop using the #WAIT command and start using #ALARM and Trigger Wait states instead. You're scripts will work a lot better then!