OutGamer

Even if the goal isn’t botting, many people want to record paths they walk manually in MUDs for repetition later. This can apply either to paths for travel between key destinations or to pathing for graph tours of an area.

At a minimum, the script for this must:

• Allow start/reset of the path
• Collect movement commands as they’re issued
• Do at least minimal checking for movement success or failure
• Keep a cumulative list of movements
• Dispay the list upon request

Most of the checking for failed moves can be done implicitly if there’s a reliable way to check for success: the script can store the most recently issued move command then then watch for success. If another move command is issued before a success is seen, in this case it may be assumed that the first move(s) were failures.

It is possible to implement a more sophisticated command stack to track pending commands, but the purpose of this script can generally be served by the user walking the path in a slow and controlled manner.

This sample will use three regexps to recognize user and server data:

• movement commands – simplified to “n”, “e”, “s”, “w”, “u”, and “d”.
• a reliable portion of the room description in the event of a movement- we will use the line which provides a list of exists from the current room. For ROM 2.4, an example is “[Exits: north south]”. For Nukefire, “Obvious Exits:”
• The most common movement failure is when an exit doesn’t exist and is the same in both ROM and Nukefire: “Alas, you cannot go that way[.][.][.]”

Code for both CMUD and tintin++ is provided. The CMUD code takes advantage of CMUD’s class feature to isolate variables and turn the code on and off: the class can simply be enabled/disabled in the GUI or via command line. The trigger lines we’re using are key to many botting functions and Tintin doesn’t allow triggers with duplicate patterns. CMUD’s solution is classes and namespaces. For Tintin, we must force the pattern to be unique in a way other coders won’t inadvertently duplicate.

This code contains the trigger text for ROM 2.4. The one pattern which must be changed for use in Nukefire is the exits line, which for Nukefire is, in regexp form, without the surrounding quotes, “^Obvious exits\:$”.

CMUD, in the form of XML which may be imported:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<cmud>
  <class name="pathrecorder">
    <trigger type="Command Input" priority="30" regex="true">
      <pattern>^(n|e|s|w|u|d)$</pattern>
      <value>#SHOW going: %1
#VAR tmpdir %1</value>
    </trigger>
    <var name="path">e</var>
    <trigger priority="60" regex="true">
      <pattern>^\[Exits</pattern>
      <value>#SHOW see exits
#IF (@tmpdir == "") {
//weren't trying to walk
} {
//it was a walk
#VAR path %concat(@path, @tmpdir)
#VAR tmpdir ""
}</value>
    </trigger>
    <var name="tmpdir" type="Literal"/>
    <alias name="resetpathrecorder">
      <value>#VAR path ""</value>
    </alias>
  </class>
</cmud>

Organization within CMUD:

Tintin++, which may be copied/pasted into a text file and #READ:

#CLASS {pathrecorder} {open};
#VAR pathrecordertmpdir x;
#ALIAS {pathrecorderunload} {
#CLASS {pathrecorder} {kill}
}
#ALIAS {pathrecorderreset} {
#VAR pathrecordertmpdir x;
#VAR pathrecorderpath x;
};
pathrecorderreset
#ALIAS {{^(n|e|s|w|u|d)|(pathrecorderstring)$}} {
#SHOW attempting walk: %1;
#VAR pathrecordertmpdir %1;
#SEND %1;
};
#ALIAS pathrecordershowpath {
#LINE ignore #SHOW cum path: $pathrecorderpath;
};
#ACTION {{Exits.*}} {
#IF {$pathrecordertmpdir == x} {
#NOP a;
} {
#FORMAT {pathrecorderpath} {%s%s} {$pathrecorderpath} {$pathrecordertmpdir};
#VAR pathrecordertmpdir x;
};
};
#ACTION {{^Alas, you cannot go that way[.][.][.]|(pathrecordernonsensewithsecretxyzzy)$}} {
#VAR pathrecoerdertmpdir x;
};
#CLASS {pathrecorder} {close}