Latest revision as of 14:51, 10 September 2008

Outline of future autopilot development

Aims

Information and automation

The original goal of the first autopilot was to provide some necessary feaures which weren't present in the OpenTTD dedicated server at that time, such that the server's admin did not have to be at or near the console at all times to keep things on track. An autopilot in the sense of not having to sit at the yoke of your aeroplane all the time. The first features implemented were as follows:

• Set some game parameters which weren't in the game's config file (such as net_frame_freq)
• Keep a count of connected players, and pause the game if there weren't any
• Greet each player and show the location of a web page giving the rules, etc

All of these are now possible without autopilot. This is a good thing; it shows that the features are widely desirable. Now it falls to autopilot to provide additional features. They're more of a luxury than a necessity now, but should include the following:

• Saving the game regularly; specifically, when people leave or join, or when somebody requests it by command from within the game.
• Periodically change the server's password
• Storing information in a database, so that a web page can query this information and display it (including the password)
  • Including a log of in-game chat
• Restarting the game from a new scenario or random game once it gets old enough, and nobody's still playing
• OpenTTD itself can send an MOTD when a client joins, however this is sent into global chat. provide a way to greet / send the MOTD to the new client in private
• (optional) log openttd's stderr in case it crashes and the admin should be eager to know why / report a bug

Bridge to IRC / IRC bot

Chat bridging

The main reason for being connected to IRC is so that users connected to IRC can converse with players connected to the game, and vice-versa. Chat should be relayed from IRC into the game, and from the game into IRC, without feeding back or being unclear as to the origin of any message.

It should also relay to the IRC channel when players join, leave or change name in the game. For traffic reasons (the game only has a few lines to display chat) joins and parts from IRC do not need to be relayed into the game.

IRC bot

The IRC connection can also be used in channel to provide information about the game to the IRC channel. Users on IRC should be able to query the bot for the number of players and companies, a list of their names and colours, and other pertinent information such as the current game password.

It's also envisaged that console commands can be sent to the game server directly from IRC. in ragrad to the rcon possibility, it would be useful to 'catch' the console output from the command and return it to the user on irc.

If the game should crash, dump the last lines to irc (of course configurable by autopilot config) as this may contain details on an assert ;-)

Modular / Customizable (without the need of editing autopilot source directly)

Most of the initialisation variables in autopilot 2.0 are read from openttd.cfg. It might be necessary to separate this out, though, especially in the event that autopilot will be manipulating different configuration files in order to start a new game with new settings.

The configuration of autopilot should, from the user's perspective, be a matter of providing settings in an "Windows INI" style configuration file (similar to openttd.cfg) and perhaps the modification of auxiliary scripts kept separate from the canonical source files. These scripts might contain Tcl commands, but it's worth considering writing a parser for something a little simpler.

include a method to (safely) implement custom !commands and define callbacks (sourced tcl files - using catch around source will prevent the tcl files from crashing ap)

Security

autopilot should implement all of these features without leaving the game, the database, the IRC channel or any third parties vulnerable to the malicious activities of a few.

using interp for custom commands / callbacks might be helpful

distributed ban system: bans may only be uploaded to the central server with user credentials (requires registration), download publicly available

Code Notes

autopilot should entirely run in it's own namespace, everything that 'adds' to autopilot (such as any additional libraries) should have their namespace within the main autopilot namespace.

use tcl 8.5

use dictionaries for player and company lists

IRC bot

RFC compliance

• use irc package (0.6 or later) from tcllib (1.10 or later)
• standard eol-style: crlf (handled by irc package, however allow this to be configured as some networks are not rfc conform e.g. euirc.net)
• ping reply asap (handeld by irc package)
• join channel only after /end of MOTD received

Important callbacks

• 376 /end of MOTD (code to join channel in this callback)
• 332 joined channel (send /NAMES to keep internal nick list of channel)
• 353 reply from /NAMES (/NAMES response can appear multiple times depending on the number of clients in the channel, accumulate them)
• 366 /end of NAMES (process the accumulated list of channel nicks)
• MODE a mode change occured, send /NAMES to update the internal list
• NICK nickchange, send /NAMES
• QUIT a user from our channel quit, send /NAMES
• PART a user from our channel left, send /NAMES
• KICK we were kicked from the channel
• INVITE we have been invited to a channel
• PRIVMSG a channel or private message (detect private message by comparing [target] with the bot's irc nick name, do this case insensitive)