OutGamer

It’s not a hard task, but logging our bot in to the game demonstrates running actions and maintaining state between them.

Creating and configuring a new account on a typical server can be fairly complicated and specific, yet only needs to be done once and often involves specific choices the player would like to make which would be more complicated than it’s worth to automate.

Therefore, we’ll look at the process as three steps:

1. Establishing a connection to the server
2. Responding to the server’s query for a username
3. Responding to the server’s query for a password
4. Responding to the server’s query about a requested action with the command to enter the game
5. Cleaning up the bot’s state so that other players can’t exploit the triggers/reflexes to do something like send the password again.

To do that, as a minimum we need to include the following minimal information as part of the bot’s configuration data:

• the address and port number of the server
• the username of the bot on the server
• the password of the bot on the server
• the text messages that the server sends to ask for:
  • the bot’s username
  • the bot’s password
  • the immediate followup action once logged in

Ideally, we will also include the possible responses for both success and failure to each thing sent to the server. An alternative would be to time out if the expected success message is not received.

The first part is a simple action for the bot: make a connection attempt. The others are preconfigured responses to expected events.

For CMUD and the mud tdome.nukefire.org, this will suffice (as of Jul 2024), substituting the name and password for {BOTNAME} and {BOTPASSWORD}:

#TRIGGER {^What’s your name, Freejack?} {BOTNAME} “” “logintrigs” “prompt”

#TRIGGER {^Password:} {BOTPASSWORD} “logintrigs” “prompt”

#TRIGGER {Make your choice:} {1;#T- loginclass} “logintrigs” “prompt”

#TRIGGER {^Reconnecting.} {#T- loginclass}

#ALIAS {login} {#T+ loginclass;#connect}

The actual connection attempt is triggered externally by the user when the bot is started up after configuration.

login

For non-cmud users: the two strings at the end of the TRIGGER command specify a class and can also specify that the trigger is to fire on a prompt line (without carriage return line feed, such as is common when the server asks a question and expects to wait for a response). These triggers are easy to adapt for use in other common clients such as Tintin derivatives and Mudlet.

The possible failure conditions and appropriate responses are:

• Connection to server fails – no further action. State will be reset next time we attempt a connection.
• Username already exists – most likely a misconfiguration of the bot.
• Password incorrect – most likely a misconfiguration of the bot.
• Session reconnection (already live, we just took over the old connection) – not necessarily an error as the end result is what was expected: a live connection to that character.

From a security perspective, this is also reasonably safe. In mid-game, the class is turned off so the triggers won’t fire. Only when the user specifically tells the client to log in (through an alias, not a trigger) do the triggers become active. They deactivate upon completion.

Later trigger setups in this series will demonstrate how to also deactivate sets of triggers based on a timer to handle cases in which they were incorrectly turned on or in which something interrupted their proper completion.