DM Script

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.

Server-Side Scripts

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.

client/script = ""

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.

Client-Side Scripts

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.

Post-Connection Scripts

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.

Pre-Connection Scripts

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:

#define URL "telnet://themud.byond.com:6005"

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.

#include
#define URL "telnet://themud.byond.com:6005"

Password Echo

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.

#define PASSWORD_TRIGGER "assword:"
//Crude but effective.
//Some worlds capitalize the `p' and some don't...

Command Aliases

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:

alias/hyena()
   set desc = "laugh like a hyena"
   return "emote laughs like a hyena!"

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.

alias/Dan(msg as text)
   set desc = "tell Dan off"
   return "tell Dan [msg]"

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.

alias/tell(trg,msg as text)
   set desc = "(recipient,message) speak to someone"

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

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.

macro
   e return "eat"
   i return "inventory"
   f return "chicken\nflee" //multiple commands
   s return "say \"\..."    //command to be edited

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.

Macro Toggles

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.

client
   script = 'macros.dms'
   macro_mode = 1

macros.dms:

macro
   Q return "quit"
   q return "quaff"