Client scripts are mini-programs used to configure the client. The language they use is called DM Script. As of this writing, DM Script is in its early stages and will undoubtedly expand in the future. Currently, client scripts can be used to define style sheets, command aliases, and keyboard macros. When executed directly by a player, they can also be used to specify an initial URL to open and a password trigger (for some ancient telnet worlds that don't suppress password echo).
Most designers will only make use of the style sheets and macros, since the other elements of DM Script are more relevant to client-side scripts. The syntax of Cascading Style Sheets (CSS) was covered in section 11.5. The other components of DM Script will be documented briefly in the following sections.
The client.script variable may be assigned to script code in a text
string (double quotes) or in a file (single quotes). Files containing DM
Script should have the extension .dms. If you simply include a
single script file in your project, it will automatically be assigned to
client.script for you.
When the player connects to the world, the script specified in
client.script is executed by the client. This is known as a
server-side script since it originated from the server.
The following example uses a server-side script containing a style sheet.
This style sheet selects a default monospace font for all output to the
terminal. In a proportionally spaced font, each character has a different
width. If you depend on characters lining up in adjacent lines of output,
you might need to use a monospace font instead.
Note that the syntax for including a style sheet is a special case of a more
general feature of DM Script. Any text contained in HTML tags is sent to
the terminal. You could display a welcome message by enclosing it inside
<P> and </P> tags, for example.
In addition to scripts loaded via client.script, the player may have
client-side scripts. These are either called connection scripts or
post-connection scripts depending on whether they are used to
automatically connect to a world or whether they are executed
after connecting to a world. In either case, the player's scripts are
always executed before the designer's client.script script, so style
sheets from the designer have higher precedence by default.
There are three post-connection client-side scripts for the three types of
worlds the client can connect to: byond.dms, telnet.dms,
and irc.dms. The appropriate one of these is automatically
executed when the player connects directly to a world without using a
connection script to do so.
The intention of post-connection scripts is to load any standard
configurations such as style sheets and command aliases. The
telnet.dms script, for example, selects a monospace font, since
many telnet worlds depend on text characters having a uniform width. It also
makes some useful definitions so that arrow keys output standard MUD
direction commands.
Since many client-side scripts are tailored specifically for a world, it is
convenient to have the script automatically connect to that world. This is
done by defining an initial URL in the script like this:
DM Script uses the same pre-processor as DM code, so this #define
statement is identical in syntax to the one used in DM. It is permissible
to make a URL definition in a post-connection or server-side script but it
would have no effect. Only a script executed before the player has
connected pays any attention to the URL.
Taking advantage of the preprocessor, it is possible to make a new script
(like the one above) include everything from a previously defined script.
This should only be done in a client-side script, since the included file
needs to be accessible when the client looks for it.
Since telnet and IRC worlds do not use your BYOND key login information,
they require that you log in manually after connecting. Some telnet worlds
do not correctly suppress password echo when you log in. If you find that
to be the case, you can attempt to suppress it by defining a password
trigger. That is simply a sequence of text used to recognize when
the world is prompting you for a password.
Command aliases appear as verbs to the player. In a BYOND world, the alias
is ultimately used to execute another verb (hence the name alias).
In a telnet or IRC world, the alias is used to generate a command which is
sent directly to the world server as though the player had typed it.
The syntax for defining an alias is best illustrated by an example:
This is the simplest sort of alias. It depends on the existence of a
command called `emote' in order to work. The return value of an alias is
simply another command to be executed. The only restriction is that the new
command cannot be another alias (or an infinite loop might result).
Aliases have all the same properties as verbs (such as desc). See
section 4.2 for a complete list.
Just like verbs, aliases can take arguments. The following example could be
useful if you do a lot of talking to the same person.
The arguments can simply be embedded in the command text using the same
syntax as DM.
The examples so far all generated new commands. In a telnet MUD, however,
you might just want the alias to pass the same command on to the server.
Since the client doesn't know what commands the server accepts, aliases can
be defined to stand for them. That gives the player verb panels, command
expansion, and syntax help--just like verbs in a BYOND world. Of course,
not as much help can be provided in expanding arguments to the alias, but it
is better than nothing.
The following example, adds a `tell' alias to a telnet world which presumably
handles such a command.
Notice that a return value was not even defined. That is because the
default return value is the alias name followed by each argument separated
by spaces. In this case, that is probably the correct syntax.
Also notice that no input type was specified for the first argument. This
simply accepts a single word from the player. No help can be provided about
the possible values of that argument, but at least it provides some syntax
help to the player.
Keyboard macros are just like aliases except that the name of the macro is a
single key that will activate it. The following example illustrates the
basic syntax.
As demonstrated, multiple commands may be generated by a single macro. It
is also possible to leave a command unfinished so that it simply appears on
the command line. The same syntax applies to aliases.
Normally, macros are entered by pressing a toggle key (such as alt). The
macro_mode client variable may be used to treat keys as macros by
default. In macro mode, commands must be preceded by a command toggle
(which is normally `/').
The following example defines some macros and turns on macro mode.
macros.dms:
Server-Side Scripts
client/script = ""
Client-Side Scripts
Post-Connection Scripts
Pre-Connection Scripts
#define URL "telnet://themud.byond.com:6005"
#include
Password Echo
#define PASSWORD_TRIGGER "assword:"
//Crude but effective.
//Some worlds capitalize the `p' and some don't...
Command Aliases
alias/hyena()
set desc = "laugh like a hyena"
return "emote laughs like a hyena!"
alias/Dan(msg as text)
set desc = "tell Dan off"
return "tell Dan [msg]"
alias/tell(trg,msg as text)
set desc = "(recipient,message) speak to someone"
Keyboard Macros
macro
e return "eat"
i return "inventory"
f return "chicken\nflee" //multiple commands
s return "say \"\..." //command to be edited
Macro Toggles
client
script = 'macros.dms'
macro_mode = 1
macro
Q return "quit"
q return "quaff"