This document describes the features of CMUD in more detail. It is a companion to the Comparison Chart showing the differences between our MUD client products.
To help novice users learn how to create simple scripts, a new Script Wizard has been added. It uses a step-by-step GUI to help users create simple scripts, such as coloring text, gagging lines, substituting text, etc. Wizard can be easily turned off for advanced users.
Trigger Pattern Wizard
A new Trigger Pattern Wizard has been added to help novice users create complex trigger patterns with wildcards. The GUI allows you to select a line from the MUD to match, then highlight the parts of the line that might change and convert them to proper wildcards. Help tips for regular expression triggers are also provided, along with a robust pattern tester to determine if your trigger matches text from the server.
An Alias is a shortcut name that contains a list of commands to be executed. In terms of other programming languages, an Alias is like a Procedure or Method call. When the Alias name is entered on the command line, any script assigned to the Alias is executed. You can pass additional data to an alias via command line arguments, and CMUD supports named-argument references.
Unlike in zMUD, any characters can be used in the name of an alias that you want to use on the command line. However, when calling an alias from another script, the alias must just contain letters and no spaces.
A Macro is a script assigned to a specific key on your keyboard. When you press the key, the script assigned to that key is executed. CMUD allows you to assign a macro to *any* key combination on the keyboard, even a key combination that is normally assigned to a Windows or menu shortcut.
A Trigger allows to you execute a script based upon the text received from the MUD. CMUD supports a simple pattern matching syntax, along with powerful regular expression patterns. CMUD also supports multiple trigger states for very advanced scripting. A Trigger Tester is included to make it easier to create trigger patterns and test to see what text from the MUD they match.
Command line triggers
A command line trigger allows you to execute a script based upon what you enter into the command line. This can be similar to an alias, but provides more power via regular expressions to completely change how the command line is parsed. Using a "prompt" command line trigger you can even intercept the command line text before it is parsed and compiled by CMUD.
An MXP Trigger allows you to execute a script when a certain MXP or XML tag is received from the MUD. This allows you to customize how CMUD handles MUD-specific MXP or XML tags, or override how CMUD handles MXP tags internally.
A Telnet Trigger allows you to execute a script when a certain Telnet Option is negotiated or send via telnet sub-option commands. Telnet triggers can be used to handle MUD-specific protocols that are not built into CMUD directly.
An Expression Trigger allows you to execute a script when an expression changes it's value and returns true. In zMUD, expression triggers were unreliable and very slow because they were constantly tested in the background. CMUD optimizes expression triggers so they are only tested and fired when a variable used in the expression changes.
CMUD contains a Tick Timer that can be used to synchronize your scripts with time "ticks" from the MUD. You can also create your own Timers and Alarms to execute scripts at specific time intervals.
An Event is similar to a trigger, but instead of firing when text from the MUD is received, it is fired internally by CMUD when a certain situation occurs. For example, the "onConnect" event is fired when CMUD connects to the MUD.
Variables (persistent in session)
Variables are containers that hold specific values and are saved across sessions. Variables in CMUD are normally "auto-typed" but can also be set to specific types such as string, integer, floating point, etc. Variables can hold entire arrays or databases, or can contain COM objects. Indirect variable access is also possible via zScript.
The #NOSAVE command can be used to prevent a variable from being saved across sessions. Setting the Default value for a variable also accomplishes this task. The advantage of not saving a variable across sessions is that it speeds up changes made to the variable.
A Local Variable is only active within a specific script block and cannot be accessed outside of that block. Local variables are stored in the runtime stack and are extremely fast. They also allow you to create variables for calculations in your scripts without causing these variables to clutter your session settings or get stored in your session. Scripts written to utilize local variables can achieve huge performance increases.
String List variables (string arrays)
A String List is a collection of string values. For example, "a|b|c" is a list containing three strings: "a", "b", and "c". In many ways, string lists act like Arrays in other programming language and can be indexed by number. In CMUD, string lists are stored in a hash table that can be sorted for very fast access.
A variety of commands and functions are available to add, remove, sort, query and convert string lists. These string lists can also be used within trigger patterns to automatically match any value contained within the list.
Database variables (associative arrays)
A Database Variable is similar to an "associative array" in other programming languages. It is a collection of "keys" and "values". For example, "name=Zugg|race=Dwarf" is a database variable with keys "name" and "race" and associated values of "Zugg" and "Dwarf". CMUD stores these variables in a hash table for very fast access compared to older clients such as zMUD. Using the %db function to fetch the value of a key is extremely fast in CMUD. A shortcut syntax of @varname.key can also be used to quickly and easily access the value of a database variable key.
A variety of commands and functions are available to manipulate and query database variables. These same methods can be used to retrieve or store a database variable into the built-in Database Module. Database variables can also be used within trigger patterns to automatically match any key within the variable.
CMUD supports traditional numeric-indexed arrays for compatibility with COM objects that require this data type.
CMUD supports Integers up to 64-bits in size (max 18446744073709552000). zMUD could only handle 32-bit integers (max 4294967295).
Floating point precision
CMUD stores Floating Point values in Double-precision. zMUD only stored floating point values in Single precision.
A Path can store a series of directions to be sent to the MUD to walk from one location to another. CMUD supports customized directions, and places these directions within packages that are easy to modify or override for using CMUD on non-English MUDs. Paths can also be easily reversed or recorded as you walk around the MUD.
An Inline Function is a variable reference that is replaced with a more complex expression.
CMUD adds support for "full" functions, which are similar to aliases except that the scripts can return a value. This is more like functions in other traditional programming languages. Unlike Inline functions that can only contain an expression, a Full function uses normal commands and functions in a script and uses the #RESULT or #RETURN commands to return a result to the calling script.
Buttons (within session window)
A Button is a graphical "button" that will execute a script when you click the mouse on it. This is very similar to a macro except that it is done visually with the mouse. Buttons can contain multiple states which act as a drop-down menu for the button. Simple push buttons and two-state on/off buttons can also be created. Normal session buttons can be placed on one of four pre-defined "button bars". Each button bar can be aligned to the top, bottom, left, or right part of the MUD window.
Within a script, you can also control the caption on the button, as well as the button color and other properties.
Buttons (any toolbar)
Any CMUD Button script can also be assigned to a toolbar button and placed on any toolbar within the main MUD window. This provides even more flexibility of user interface design for your MUD session.
Buttons (drag/drop floating)
CMUD Buttons can be docked to the main session window instead of a specific toolbar, in which case they will float over the MUD text window. Also, CMUD allows you to unlock the button and then drag/drop it to a new location via the mouse.
A Gauge is a special type of a button that can show a graphical progress bar. It might seem strange to think of a graphical gauge as a button, but in CMUD you can click on a gauge to execute a script, just like with a button. Gauges are displayed in the same button bars within the window that buttons are, allowing you to arrange the graphical status gauges next to other button controls.
Menu items (right-click menu)
When you right-click the mouse on the MUD output window, a context menu is displayed. Normally this popup menu just allows you to edit the properties of the window. However, you can also add your own items to this context menu using Menu objects.
Menu items (main menu)
Any Menu object normally created for the right-click menu can also be placed within any menu toolbar. You can control whether a menu is only visible in the right-click menu or if it is only visible in the normal menu bar.
Status bar items
Status bar items are text strings displayed in either the status bar at the bottom of the MUD output window. These strings are evaluated for variable or function references before being displayed. They can also contain color using the %color function, or even MXP/HTML tags.
Status window items
A Status window contains multiple lines of status bar items. The contents of the status window is updated based upon the MUD window with the current focus.
New #SQLDB and %sql commands allow you to script an SQL database directly, without using ADO or other COM methods. CMUD supports SQLite databases, while CMUDPro and TeSSH support other databases such as MySql, Oracle, MS Sql, Postgres, etc.
The new %url function was added to CMUDPro and TeSSH to allow you to fetch data from web sites (via GET or POST). Also supports downloading files via HTTP.
Multiple capture windows
Using the #CAPTURE command, you can extract text from the MUD output and send it to a separate window. For example you can create different capture windows for each chat channel on the MUD. Each window can have it's own triggers and other settings and can be docked in any fashion that you want. Docked windows can also be hidden and set to automatically "fly-out" when the mouse is moved over them. Capture windows can also be set to activate automatically when they receive text, ensuring that you don't miss any important messages.
CMUD has a complete session manager for keeping track of all of your MUD characters. You can also open multiple sessions at the same time for multiplaying (multiple characters on the same MUD, or different MUDs). You can save multiple sessions into a "super session" making it easy to log into multiple characters all at once. Session icons can also be dragged to your desktop to create desktop icons that will immediately connect you to your MUD session, bypassing the normal session selection window.
Each session can have it's own scripts, and scripts can communicate with other sessions to exchange data as needed. Each session can have it's own window layout, and a "super session" of other sessions can have it's own layout.
Sessions can be password protected, and a master password can be set to encrypt all other session passwords to prevent anyone from stealing your MUD login information.
Normally your CMUD scripts are stored within the specific MUD window that you want them to operate. However, you can also store scripts in a module where they can be shared by multiple windows or even other packages.
Your scripts can be stored in packages, which are files containing your aliases, triggers, and other scripts that can be easily shared with friends.
Shared package library
CMUD contains an interactive shared Package Library that allows you to upload your packages, or download packages created by others. The library can be searched and sorted in a variety of ways to find the package that you need for the specific MUD you are playing. Packages can be rated and comments can be added to them. This library makes it very easy to share scripts with other players of the same MUD.
In zMUD you could only create a single "inherited" settings file that contained settings common to multiple MUD characters. In CMUD, the flexible Package system allows you to create as many shared packages as needed. For example, the macros assigned to the keypad by default are stored in a package called "English Keypad" making it even easier to replace with your own package of scripts and key assignments. You can create packages that are used by characters on the same MUD, or characters of the same type. You can download and share packages using the Package Library.
Dockable window layout
When playing MUD games, it's common to create multiple windows for various "chat channels" within the game. To manage and organize all of the windows that you create, CMUD supports a sophisticated Docking system that allows you to combine windows and position them exactly how you want. This system is very similar to the docking system used in professional software development systems such as Microsoft Visual Studio.
Windows can be docked to any edge of any other window, or "tabbed" together, or floated above other windows. Windows can be set to "auto hide" and open when you move the mouse over their tab. zMUD had many restrictions over the types of docked layouts that could be created. CMUD removes all of these restrictions and allows you to dock windows any way you want and saves this layout across sessions. An improved user interface provides a better visual indication of where a window will be docked.
The menu bar and toolbars in CMUD can be completely customized. You can remove commands, add other pre-defined commands, or even add your own user-defined commands. Each button on the toolbar can be set to have it's icon on top or on the left and to display the caption text or not. Toolbars can be moved and docked to any edge of any window, or can remain floating over the rest of the windows. CMUD uses a menu customization system very similar to what is used in Microsoft Office 2003.
CMUD can be set to save any number of lines of text in it's scrollback buffer. Pressing PgUp/PgDn or scrolling the screen with the mouse will reveal this scrollback buffer. The screen will be split to show the scrollback buffer while still showing any incoming MUD text. This prevents you from missing important text while you are viewing the scrollback (or getting your character killed when a mob enters the room while you are browsing the scrollback buffer). You can easily adjust the splitter to show as much or as little of the live text as you want.
The scrollback works much more naturally in CMUD than in did in zMUD and doesn't contain the display bugs that zMUD had when using a very large number of scrollback lines. Scrollback size is only limited by the amount of memory on your computer.
CMUD allows you to add automatic time-stamp values to the beginning of each line. Each window has it's own timestamp settings. You can customize the format in which the time value is displayed and even get very accurate "delta time" values in sub-millisecond precision. Time stamps can also be saved to the log files.
The CMUD command line works as a normal toolbar and can be docked to different locations on the screen and can be customized to contain different command buttons.
CMUD performs "as-you-type" spellchecking in both the command line and the script editor window. You can add words to your own local dictionary and also perform auto-completion to automatically fix common typos.
The CMUD command line can actually contain multiple lines of commands. Press Shift-Enter to insert a "soft" line break and the command line will expand to show an additional line. You can also paste multi-line text to the command line. Pressing Ctrl-Shift-Enter will open a full multiline screen editor that can also be used to enter multiple lines.
Smart (allows special characters)
The CMUD command line has a feature called "Smart" which allows it to decide whether the command you typed is a valid CMUD script or should be sent directly to the MUD. Without this option (and in zMUD), special characters on the command line are parsed as script characters. But with this option enabled in CMUD, the special characters are sent to the MUD if the command line is not a valid script. For example, the : character is usually reserved to send text to a different CMUD window name. However, if : is used without a valid window name, the smart command line will send it to the MUD as a normal MUD command. The need to "escape" special characters is much less in CMUD, making it work much better on MOOs and MUSHes. You can still toggle command line parsing off and on using the Ctrl-R key.
Command history recall
CMUD maintains a history list of commands that you have sent to the MUD. Pressing the up/down arrow allows you to cycle through these past commands. You can also enter the start of a previous command and press the up-arrow to recall the command that starts with those characters from the history.
Tab completion words
You can Tab Completion words to your session. When you type the first few characters of a tab completion word and then press the Tab key, the rest of the word will be completed automatically. CMUD also allows you to set a "value" of a tab completion word, where the value replaces the text on the command line when you press tab after the word.
Tab completion from screen words
In addition to searching your tab completion words, CMUD also searches the current screen of text for any words that start with the characters you have typed. Pressing tab multiple times will cycle between all of the choices. In zMUD you needed to hold down the Shift key and press Tab to activate this function. In CMUD it was integrated with the normal tab completion feature to make it easier to use. This feature really comes in handy when someone on your MUD has a long character name that is hard to type.
Server-assisted tab completion
When pressing the tab key in the command line, the remote server shell is queried for it's own tab completion logic, such as remote file path completion.
Context-sensitive F1 help
If you enter the name of a zScript command or function on the command line and press F1, a Reference window is displayed with quick information about that command or function.
In CMUD you can switch the command line into "Lua mode". In Lua mode, the text that you enter into the command line is sent directly to the internal Lua parser and executed. This allows you to easily interact with Lua functions and scripts and test them from the command line.
The Script Editor is a powerful tool for creating, editing and organizing all of your scripts. In CMUD you can have aliases, triggers, variables, macros, buttons and many more scripts. It can become difficult to manage all of these scripts without a good user interface. CMUD has the best editor interface of any MUD client and is based upon the very popular open-source Scintilla editor core that is used in NotePad++.
Scripts are organized into a single tree-view on the left, just like files and folders in the Windows file explorer. The settings can be filtered and searched by type or name, and you can search for any setting that contains a particular word or phrase. Advanced options for each setting can be hidden and only expanded when the additional properties are needed.
The panel layout of the settings editor can be modified via drag/dock and will be saved across sessions. Then entire toolbar and menu of the settings editor can also be customized and saved.
Pressing Ctrl-K in the script editor will check the current script for any syntax errors and report any problems. The cursor is correctly placed at the location of the syntax error. You can check *all* scripts for syntax errors using the Compatibility Report in the script editor.
CMUD has excellent support for multi-line scripting, whereas zMUD often converted scripts into a single line, making them hard to read. With the multiline script support, indenting blocks within scripts becomes more important and sometimes when you get nested within multiple IF statements it can get hard to determine what indent level to use. The Reformat Script command can be used to "pretty-print" your script into a standard multi-line format. This is a great aid for lazy typers or people who just have a very long and complex script they need to understand.
Syntax color highlighting
CMUD colors your script as you type based upon the syntax of the script. For example, variable references are shown in one color, commands in another color, functions in another color. This helps you find typos in your script as you are typing. The strict parser used in CMUD allows it to be used for very accurate and fast syntax highlighting, unlike other clients that use simple regular expression syntax highlighting.
CMUD also automatically highlights matching parenthesis and braces when you put the cursor next to one. All of the colors used in the editor can be completely customized in the Color Styles Preferences screen.
Syntax highlighting isn't just available for zScript, but is available for most any other scripting language. Built-in highlighting for Lua, XML, VBScript, JScript, Perl, Python, and many other languages is included.
Line numbers are displayed in the gutter to the left of the main script field. This allows you to more easily locate syntax errors that are reported on a specific line and to better handle very large scripts.
Blocks of code can be collapse or expanded by clicking buttons next to the line number gutter. This works in all scripting languages. For example, you can collapse a large #IF statement in zScript, or collapse an XML tag when viewing the XML text of a script. Dotted lines are also used to show the indentation level of code blocks.
All scripts can be exported and imported in a readable XML format. You can click on the XML tab in the script editor to view and edit this XML text. Any changes to the XML are reflected in the editor itself. When viewing a Class or Module you can edit the XML for all scripts stored in that folder or module.
The simple "ascii text" format used to save settings in zMUD can still be entered into the CMUD command line to import text scripts from zMUD. However, CMUD does not support this simple text format for exporting. Too many new options and features are available in CMUD that are not possible to export in this simple text form. The simple text form also cannot handle the full multi-line script format used in CMUD. By creating a human-readable XML format, CMUD is able to create a more advanced text import/export system than zMUD had.
The XML can be easily copied and pasted into the CMUD Discussion Forum (within [code][/code] tags) to share scripts easily with others. CMUD also uses this XML format to store packages into the shared package library. When importing, you can easily import an entire package, or just a few simple scripts into the currently selected folder.
Scripts are shown in the main tree-view on the left side of the editor and can be easily dragged from one class folder into another. If you hold down the Shift key, a copy of a script can be dragged to a different folder. When your session uses multiple packages, these packages are shown along the top of the editor as tabs. You can drag a script from the tree view and drop it onto a package tab to move/copy it to another package.
You can copy and paste scripts from the tree view on the left side of the editor. Right-click to select copy and then right-click and select paste to make a copy of a setting. The XML text format is used with the copy/paste, so you can also copy a script and then paste it into any text editor in the XML text format.
When typing your script into the editor, the editor will suggest words in a popup list that you can auto-complete by selecting and pressing Enter. This works for any word within the current script, and also works for any zScript command or function. For example, if you type #A then all of the commands that start with "A" will be displayed. This makes it faster to enter scripts and helps ensure that you don't make typos in your command or function names.
When you enter the name of a command or function, a mouse-over hint is displayed to show the basic syntax of the command/function and what arguments it takes.
When you move the mouse over a variable reference, a mouse-over hint will show the value of the variable. You can also click on a variable or alias reference to jump to the editor showing that script. A next/prev queue is maintained to make it easy to go back to the previous script (or click the Prev button on your mouse). This next/prev queue works similar to the next/prev in your web browser, making navigating all of your scripts even easier.
Context-sensitive F1 help
When you place the cursor over a zScript command or function in the script editor and press F1, a quick reference panel is displayed giving quick help for that command/function. Clicking the More Help link will open the full help system for that command/function.
Scintilla based (NotePad++)
The CMUD script editor is based upon the popular open-source Scintilla editor component. This is the same editor component used in the popular Notepad++ application. It provides a stable and robust platform for script editing in CMUD, especially compared to the home-grown editor that was used previously in zMUD.
zScript (zMUD scripting language)
zScript is the programming language originally invented for the popular zMUD client. It was based upon the original TinTin++ client language. zScript consists of #commands and %functions to create scripts that are optimized for MUD playing. CMUD implements zScript v2, which is a superset of the v1 language used in zMUD. Various changes were made to the scripting language to better support new features and to improve some of the problems created in older zMUD scripts. A Compatibility Report in CMUD scans all of your scripts to identify and fix potential problems between the v1 and v2 zScript languages. The CMUD zScript v2 is a bit stricter about parsing, especially in placing quotes around string values, and in not expanding any variables or functions within literal string values. This makes it easier to handle text containing special characters that CMUD might otherwise treat as scripting characters, and makes it easier to handle text containing spaces. It also makes zScript more consistent with other standard programming languages.
See the Knowledge Base for a full list of zScript commands and functions and other scripting features.
CMUD was designed to be very compatible with older zMUD scripts. Existing zMUD session files can be directly imported into zMUD. The Compatibility Report can be used to scan your old scripts for potential problems. There is a full list of changes for zMUD users who want to start using CMUD.
In many MUD clients, such as zMUD, the scripting language is "parsed" and "interpreted" at run-time, such as when your script fires in response to text received from the MUD. In CMUD, your scripts are compiled into a "byte-code language" which can then be executed very quickly. Since a script is compiled once and then executed many times, compiling a script results in much faster script execution. This "just-in-time" compilation is the same mechanism used in the Java programming language. CMUD allows you to view the compiled code of a script for debugging purposes, but otherwise you never need to deal with this implementation detail. You still distribute your scripts in text form and type them in text form into the CMUD editor. The compiling happens behind-the-scenes whenever your script is changed. The compiler can handle most zScript v1 scripts from zMUD, resulting in faster script execution with no changes to your original script.
The ability to formally specify the zScript language to develop a compiler also allows CMUD to perform exact syntax highlighting. In most MUD clients and scripting editors, syntax highlighting is performed via basic regular-expression matches. For example, text like @varname is colored as a variable name, regardless of it's context. Additional regular expression rules might override this color if it is contained within quotes, for example. However, the syntax highlighting used in CMUD uses the same parser used by the compiler to color-code the script exactly how it will be compiled. A @varname reference is only colored as a variable if the compiler really sees this as a valid variable reference. This makes the syntax highlighting in CMUD faster and more accurate than past attempts of syntax highlighting in zMUD and other MUD clients.
Other Integrated scripting languages
The Lua programming language has become very popular due to it's high performance, small size, and use in games such as World of Warcraft for making "mods". One unique aspect of Lua is it's ability to be easily embedded in other applications. For scripts that need very fast performance or other specific Lua features, CMUD distributes the Lua code library and provides an extensive and fully integrated API to allow Lua scripts to directly interact with CMUD and other zScript scripts. CMUD does not use COM or the Windows Scripting Host to access Lua. CMUD calls the Lua API directly for high performance. Because Lua is distributed with CMUD, players can freely create their scripts in Lua without needing to worry about whether their friends have it installed or not, allowing easier script sharing.
Other external scripting languages
CMUD implements it's own custom Windows Scripting Host interface which allows multiple different scripting languages to be used within the same CMUD session. Normally you can only select a single language to use for scripting in an application, but CMUD overrides this limitation. Thus, you can have some scripts using zScript, some using VBScript, some using Perl, some using Lua, etc. You can even mix languages within a single script using the #LUA, #MSS and %mss functions.
The Windows Scripting Host is COM-based, which can slow down scripts slightly. CMUD allows these scripts to run in their own thread, but they are not as fast as integrated scripting languages such as Lua.
zScript Trigger Patterns
zScript provides a simple and easy-to-read syntax for specifying trigger patterns. For example, "a*b" matches any text starting with an "a" and ending with a "b". While CMUD also allows full regular expression syntax, the shorter zScript format is preferred by most people because it is easier to understand. The syntax mirrors the simple wildcard syntax used for filenames in Windows. A full set of additional wildcards are available, making zScript triggers very powerful.
Triggers in CMUD can also contain multiple "states" or steps. For example, you can trigger on certain text received from the MUD, then only run the script if the next line from the MUD contains additional matching text. Multistate triggers allow you to create complex "state machines" in CMUD, resulting in very powerful scripts.
Regular Expression Patterns
CMUD allows you to use full "Perl-Compatible Regular Expressions" (PCRE) for trigger patterns. PCRE is the most advanced regular-expression engine available, and is much more advanced than the basic regular expression support in many MUD clients. The PCRE library is also open-source and has been highly optimized for performance. CMUD uses the latest 7.8 version of the PCRE library, which has many more features than the old 3.4 version used in zMUD. The %subregex function uses the PCRE engine to perform very advanced and fast string substitutions.
CMUD also includes a trigger pattern tester that allows you to test your trigger patterns, convert them to regular expressions, and view the results of matching live text from the MUD. All CMUD triggers are internally converted to PCRE patterns for high performance.
Sequential Scripting is a relatively new feature that allows you to use new #WAITxxx commands to wait for various conditions within your script. Normally you would need to use a trigger to wait for certain text to be sent from the MUD, but with the #WAITFOR command you can wait for text within your existing script without creating a temporary trigger. Full support for multiple threads, protected sections, and thread signaling and synchronization is provided.
Starting with v2.0, CMUD has been multi-threaded. This means that each script runs in it's own processor thread, making better use of multi-core processors for greater performance. Full thread synchronization and protected sections are provided to make your code "thread-safe". By default, CMUD still executes your scripts in order and does not create any background threads. But if you need to perform an extended task in a background thread, it is easy to spawn a new thread using the #THREAD command. You can also place an existing script into the background using the #WAIT command.
By properly using Threads, CMUD can implement the #WAIT command without the problems that plagued the wait command in zMUD.
COM object scripting
The Component Object Model (COM) is an interface used in Windows to enable interprocess communication. Objects associated with other applications can be created and manipulated via the zScript scripting language. For example, if you have Microsoft Office installed, you can create a COM object that points to an Excel spreadsheet and then manipulate the spreadsheet data. Many low-level COM interfaces in Windows can also be used, such as creating database connections. While COM has been replaced to some extent by .NET, COM is still used extensively within Windows and provides a powerful way to interact with other COM-enabled applications.
Once a COM object is created via the %comcreate function in CMUD, it can be assigned to a normal CMUD variable, and the properties and methods of the COM object can then be fully used. CMUD and zMUD are the only MUD clients that provide full access to the power of COM programming in Windows. While COM can be a very complex and advanced technology, CMUD makes it very easy to use COM in your scripts. Just keep in mind when calling an external application from your script that when distributing your script to friends, they will need access to the same application.
COM server API
CMUD implements it's own COM-based server API. This allows other applications that use COM to call CMUD to perform any script, command, or function. The ability to manipulate CMUD from external applications provides a powerful mechanism for extending the capabilities of CMUD. You can also directly access the CMUD COM API from within CMUD itself. CMUD uses a similar COM API interface as the zMUD COM API where any reference to zMUD is changed to CMUD.
CMUD and zMUD are the only MUD clients that contain a mapper module capable of automatically creating maps as you walk around the MUD that works on most *any* MUD. Other clients claim to have mappers, but they typically only work on the MUD that they were specifically designed for. CMUD has a complex AI algorithm for configuring the mapper to work on most any MUD. You can also override the normal AI routines via the #TAG command to tell the mapper exactly what the room name, description, and exits are for the current room. CMUD also uses the ATCP protocol on IRE MUDs to provide seamless accurate map creation.
The mapper is one of the most detailed and advanced features of CMUD. Once you get the mapper configured for your MUD, you'll wonder how you ever lived without it. It makes MUD playing a lot more enjoyable.
Dockable map window
The map window can be docked along with the rest of your CMUD windows, preserving your layout across sessions. When you open the session, the mapper will automatically be reopened and positioned exactly where you left it in your previous session.
Map as you explore
Using the Configuration Wizard, you can teach CMUD how to parse the text from the MUD to determine the name of the room, description, and exits from the room. The mapper has a complex AI (artificial intelligence) algorithm to learn how to map almost any MUD. While there are many options you can use to override the AI routines and #TAG lines from the MUD in your own triggers, the configuration wizard handles most of the work for mapping most MUDs and understands many different MUD output formats. No other mapper works on as many different MUDs as CMUD.
Multiple levels visible
In addition to showing the map of the current (vertical) level of the MUD, the mapper also shows the level below and the level above. The colors used for this are completely customizable. You can easily change levels by using the mouse wheel when hovering over the Level indicator.
Interactive map editing
The CMUD mapper contains many different tools for editing your map manually. When in Map mode you can simply drag/drop rooms to different locations, or select multiple rooms to move. You can click on the end of an exit "link" and drag it to the exit of a different room. If the description of a room changes on the MUD and CMUD creates a new room for an existing room you can easily select both rooms and Merge them back into a single room. You can add labels to the map and move them around, and easily add new rooms or new exit links. Rooms can be moved to different levels or different zones. There is also a powerful search tool available to locate a specific room on the map.
Rooms can be added to a "favorites" list for easy access within a zone. You can also simply view a list of "nearby" rooms that are shown in the current map zoom level. A Spreadsheet view provides a raw grid for editing low-level details of a room.
While CMUD allows you to define your own speedwalk directions, especially for non-English MUDs, CMUD also has extensive support for custom portals and exits from a room. For example, a room might have an "in" or "out" direction. Any number of custom directions can be added to a room.
A list of portals allows you to define special words that are used to teleport you within your MUD world. These might be related to items that you are carrying in the game, or global portals such as your clan/guild hall. These portals can be enabled/disabled so that you can control which words are allowed when computing the shortest location to a room.
Custom exits (doors, locked doors, etc)
Customized exit links can be defined in CMUD. Normally an exit is shown as a simple line. An exit with a door is shown with a rectangular box, and a locked door is shown as a solid box. You can define your own exit types in CMUD or in the external zMapper application. Exits are normally centered on the edge of the room, but you can also change the X/Y offset of this link within CMUD.
Custom room types
Rooms in the CMUD mapper are normally shown as simple squares, either with a 3D border or with a specific color. Custom room shapes can be defined in CMUD or using the external zMapper application, allowing you to create any shape for your room, or assign a graphical icon or texture to the room.
Shortest path speedwalking
The most important feature of the CMUD mapper is it's ability to quickly compute the shortest path from one room to another and send those directions to the MUD. Simply double-click on the room you want to move to and CMUD will quickly send the directions to the MUD and then track your progress on the map as your character moves. In Safe movement mode, the mapper will stop if your character gets hung-up in a particular room (such as fighting a monster). CMUD allows you to set the "cost" of each room for MUDs that use a different amount of movement points in different types of terrain. You can also mark dangerous rooms as "do not enter" to prevent it from accidentally sending you through that room.
The shortest path algorithm will also use any portal information that might get you to your location faster (such as recalling back to town and then moving). All of this works across multiple zones and computes the shortest path quickly no matter how far away the destination room might be.
You can easily change the color of a single or multiple rooms on the map to any color you want. Assign blue for water rooms, for example. With zMapper you can also change the exit line colors, the room edge colors, room textures, background images and much more.
You can easily add extra text labels to the map, or enable a specific room to show it's name or short id name and keep it "attached" to the room as you move it around the map. You can also assign a label to an exit link for links that extend across a great distance on your map.
The CMUD mapper supports multiple zones or "areas". This helps you organize your map into the same areas that your MUD uses. Zones can be linked together in any fashion you want, and exits that go to a different zone are clearly labeled.
Multiple map windows
The latest versions of CMUD support multiple map windows. You can have a single map window shared by multiple session, or each session window can have it's own map window. Maps can be multiple views of the same map database file, or completely different files. You can also have multiple room property windows open for each map.
Multiple locations on map
The latest versions of CMUD allow you to define multiple locations to track on the same map display. In addition to the normal "blue dot" that shows your current position, locations can have other colors. For example, you might track guild members or your pet with a different marker color. Location objects are fully scriptable, even when the map window is closed.
Dockable Room Properties
The Room Properties window in CMUD allows you to change the name, descriptions, notes, exits, color, label, and other properties of a room. It can be docked with the mapper or with any other window in your session. Multiple room property windows can be used to track multiple maps or multiple locations.
Graphical compass for movement
The Room Properties window in CMUD contains a graphical compass that shows the valid exits from the current room. You can click on an exit to move your character in that direction. In Map Mode you can right-click on a compass direction to easily add/remove/edit the exit located in that direction. Any custom directions from the room are also shown in a clickable list below the graphical compass.
Map scripting (zScript)
The CMUD mapper is fully scriptable. Many different commands and functions can be used to query and manipulate the map data. You can also assign your own scripts to each room on the map, which are executed when you enter or leave the room. You can also assign scripts to be executed when you enter or leave a map zone.
Map scripting (COM objects)
Using CMUDPro or zMapper, a set of COM-based objects can be used in your scripts. These objects provide more detailed properties and methods for manipulating the map data.
The Database module in CMUD allows you to keep track of all the equipment, monsters, players, and other items on your MUD. This powerful database allows you to find items quickly and add new items easily. It supports multiple databases and data import/export from external applications such as Excel. The database is also fully scriptable so you can even automatically capture the MUD output of an "identify" spell and create a new item in the database based upon the results. The database is also integrated with the CMUD Automapper so you can walk to the location of an object or monster on your MUD automatically.
The Script Debugger can display messages when various events occur within CMUD. For example, the debugger can display a message when one of your triggers fires, along with the text that caused it to fire. The debugger also contains automatic time-stamps to help track down performance bottlenecks in your scripts.
zMUD contained a different sort of debugger that allowed you to set breakpoints and watch variables and single-step through your scripts. After extensive user testing it was determined that this sort of low-level script debugger was less useful than the debugger in CMUD which gives better real-time information about what your script is doing. The CMUD debugger also does a better job handling multiple threads that might be running at the same time.
CMUD uses the MUD Connector to provide the full list of available MUDs on the Internet. The list can be sorted and filtered in a variety of ways. You can also list the MUDs in the order of their creation date to find the oldest MUDs.
Logging (ANSI color)
The #LOG command can be used to create log files of your MUD sessions. The ANSI color of your session can be saved within this file, and the ANSI log file can be opened and viewed in color using the built-in CMUD Editor window.
In addition to normal ANSI color logging, you can also enable MXP/HTML logging which still save the HTML color and other MXP tags to your log file.
Integrated help system
CMUD has an extensive integrated help system with over 14,000 help topics. A quick-help panel can show syntax for zScript commands and functions. The help system can be easily searched, and each topic contains links to other related topics. A next/prev queue makes it easy to navigate the help pages just like using your web browser. An offline Help Viewer application is also available for reading the help file outside of CMUD.
Help sync'd with online web help
The contents of the CMUD help system are synchronized with the online help published in the Knowledge Base on the zuggsoft.com web site. When articles are updated online, you can use the Get Updates button in the CMUD help window to download the latest help topics into CMUD. This keeps the help topics in CMUD up-to-date. The online Knowledge Base can also contain comments added by any CMUD user, providing more examples and help.
CMUD supports more standard MUD protocols than any other MUD client.
Telnet (with option negotiation)
Telnet is the basic networking protocol used for MUD games. While some MUDs simply send raw data over network sockets and do not comply with the actual Telnet protocol standard, CMUD supports these MUDs too. As part of the Telnet protocol, CMUD supports full Telnet option negotiation. This standard allows the MUD server to query the MUD client for various optional feature support. Proper option negotiation is the basis for implementing many other MUD protocols. Most other MUD clients do not support proper telnet option negotiation or are susceptible to option negotiation loops.
MUD games usually use Telnet in "line mode", where each command is sent to the MUD server a line at a time. However, when connecting to a remote server shell account, some programs require using Telnet Character Mode. For example, if you use a remote shell editor such as "vi" or "emacs", you need the keys that you press to be sent to the server after each keypress without waiting for you to press Enter. You can enable Character Mode in the CMUD Preferences. In TeSSH, Character Mode is turned on by default.
When Character Mode is enabled, you can click directly on the MUD output window and press keys to have them send immediately to the server. You can still use "line mode" by entering commands on the separate CMUD command line and pressing Enter. This allows you to take advantage of various CMUD command line features while still using Character Mode.
SSH stands for "Secure Shell". It is basically an encrypted Telnet session (although it actually uses the SSH protocol spec instead of the Telnet protocol). It allows you to connect to a remote server via a secure, encrypted network connection. Normal Telnet sessions are not encrypted, allowing anyone monitoring the network connection to see all of your text commands, including your MUD login username and password. Using SSH prevents this data from being sent in clear-text. However, most MUDs do not support direct SSH connections and SSH is used primarily for remote shell access for system admin purposes.
Most MUDs use ANSI control codes to change the color of text on the screen. The original ANSI specification only allowed for 8 foreground and 8 background colors for text, along with an option-bit for making the text "bold", "underline", or "blink". CMUD has expanded ANSI color support as used in the XTerm application for 16 foreground colors instead of just 8. CMUD also allows you to completely customize how the ANSI option bits are defined. For example, you can select "highlighted color" instead of the normal "bold" option. CMUD also has support for "italic" text.
ANSI Full (cursor)
The full ANSI control code specification includes codes for manipulating the cursor position on the screen. While most MUDs do not use these controls, they are important when connecting to remote shell accounts. CMUD has full support for the entire ANSI specification, including the cursor movement commands.
VT100 (including scrolling regions)
The VT100 was a popular terminal made by the Digital Equipment Corporation. It became the de facto standard used by terminal emulators such as XTerm. Some MUDs use VT100 control codes to manipulate the cursor, or to create separate scrollable regions within the MUD output window. While the basic VT100 control codes overlap and extend the basic ANSI control codes, advanced VT100 features include scrollable region control. Some VT100 emulators do not implement scrolling regions properly and use of this feature has declined over the years. But CMUD fully supports scrolling regions and MUDs that use them for status bars and other MUD-specific features. The VT100 spec also defines how certain keys are sent to the MUD server, such as the function keys and keypad. CMUD fully implements these "application keypad" modes, and also supports most of the extensions used by XTerm for those additional keys.
MXP (MUD eXtension Protocol)
The MUD eXtension Protocol (MXP) is an open specification for enhancing communications between MUD servers and clients. It was developed in conjunction with several MUD servers and other MUD client authors. While it shares many features with the normal web HTML markup language, it extends HTML in a standard way to better fit the scrolling text model used by MUDs. It allows the use of HTML color codes, removing the normal limit of 8/16 ANSI colors. It provides text formatting and hyperlink capabilities, and optional features such as graphical gauges, embedded images, and more. CMUD has a full implementation of the MXP specification, including embedded images (which most other MUD clients do not implement).
CMUD has MXP enabled by default, allowing it to be used by your own scripts or even on MUDs with no MXP support at all. Certain MXP tags are marked as "open" tags, meaning that they can be used on non-MXP MUDs. For example, players can embed safe HTML codes such as <B> and <I> (bold and italic) into their chat messages, and CMUD users will see this text properly rendered. These basic text formatting commands are considered "safe" because they do not have any adverse effect on your MUD session, and players without MXP support can still tell how the chat message was being emphasized. CMUD prevents abuse by limited certain MXP formatting commands, such as changing text height.
zMUD (and early versions of CMUD) was sometimes criticized for how it handled undefined MXP tags (or text that looked like an MXP tag). CMUD later added options for controlling how undefined tags are handled and is now fully compliant with the MXP specification. This and other bug fixes in MXP mark CMUD as MXP v1.2 instead of v1.0, not because of any MXP protocol change, but to indicate the enhancement to the MXP protocol implementation.
MSP (MUD Sound Protocol)
The MUD Sound Protocol (MSP) was developed jointly between many MUD servers and clients. It allows the MUD server to send a trigger message telling the client to play a certain sound or background music. Each MUD distributes it's own sound files, or provides the sounds as downloadable "on-demand". The first time CMUD is asked to play a sound, it automatically downloads the sound from the MUD server and then plays it. With the DirectX support in CMUD, CMUD can play dozens of sounds simultaneously at different volumes. CMUD also supports multiple sound formats, including MP3, which were not supported in zMUD.
MCCP (MUD Client Compression Protocol)
The MUD Client Compression Protocol (MCCP) was developed to reduce bandwidth usage by compressing text sent from the MUD server to the MUD client. The popular zlib compression format is used, providing a roughly 30% reduction in bandwidth usage. There are two versions of MCCP. The first version (MCCP1) specified incorrect telnet option negotiation codes. This was fixed in the MCCP2 specification. CMUD supports both methods of MCCP since the first method is still used by certain MUD servers, even though it violates the Telnet protocol.
MCP (MUD Client Protocol)
The MUD Client Protocol (MCP) was another protocol developed by other MUD authors to improve communication between the client and server. It includes several optional packages for sending extra data between the client and server. The most important package is the "moo-simpleedit" package, which allows the MUD to send a large amount of text to the client, let the client edit the text, and then send the text back to the server. By allowing client-side text editing, CMUD can display the text in a full multi-line text editor, making it much easier to change the text compared to normal MUD text editing commands.
Some MUDs use plain XML tags to send optional data to the MUD client. Typically XML is used when the MUD has it's own proprietary MUD client. Via an extension to MXP, CMUD allows you to define the XML tags sent by the MUD and control how they are handled or displayed. This allows you to customize CMUD to handle the XML tags in whatever way you want.
Simutronics GSL (including login)
Simutronics produces several popular pay-to-play MUDs such as Gemstone IV and DragonRealms. These games require a proprietary login sequence not supported by normal MUD and telnet clients. zMUD and CMUD are the only clients officially sanctioned and allowed to implement their proprietary login protocol. In addition to their login protocol, Simutronics games contain a specification called GSL to send additional data to the MUD client. CMUD supports these GSL codes and allows you to write triggers/scripts attached to specific GSL functions. This allows CMUD to provide all of the features normally only available with Simutronics own MUD clients.
Pueblo was an old MUD client that was eventually made open-source and is still supported by a small number of MUDs and players. CMUD has a basic Pueblo implementation including embedded images and multiple window panes. CMUD supports the most common Pueblo functions, allowing it to be used on most Pueblo-enhanced MUDs.
ATCP is a protocol used by Iron Realms Entertainment (IRE) MUDs such as Achaea, Imperian, Lusternia, and Aetolia. It uses Telnet sub-channel data to send additional information to the MUD client. CMUD fully supports the ATCP protocol and allows you to assign triggers to various ATCP messages. ATCP messages are also fully integrated with the CMUD mapper to provide seamless mapping on IRE MUDs.
GMCP (Generic MUD Communication Protocol)
GMCP is a protocol developed by the MUD community at www.mudstandards.org to send data between the MUD server and MUD client in the background. Full GMCP mapping support is implemented in CMUD, along with full GMCP Scripting to capture this extra data and use it in your packages.
CMUDPro and TeSSH have an integrated FTP client. It supports SFTP to quickly connect using an existing SSH session. Remote files can be downloaded, and local files uploaded. In addition, support for local editing is provided where you simply right-click on a remote file and select "Edit", causing the file to be downloaded in the background and loaded into the CMUD Editor window. When changes are made to the file in the Editor, the saved file is uploaded back to the server.The #FTP command provides scripting access to the FTP window and FTP functions.