Revision as of 11:24, 22 August 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

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.

modular / customizable (without the need of editing ap source directly)

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.

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)