Installation Guide 5.2 (Shell Account)

From BotHouse MediaWiki

Welcome to the StormBot.TCL installation guide. This is a very simple guide to follow in order to get you from the tarball to a running bot.

Contents 1 Downloading the script 2 Unpacking your script 3 Editing your configuration file 4 Starting up the bot 5 Verifying StormBot.TCL is loaded 6 Using the 'permsettings' file

[edit] Downloading the script

The easiest way to get StormBot.TCL ("SB" for short) is:

http://www.stormbot.net/ 

There are 5 versions of the script online, based on the different combinations of beads (commands) available:

• Core Only Edition (the very basic of SB's functions, handles a bare minimum of channel functions and only exists to be a skeleton upon which to build a custom distribution for use)

• Minimum Edition (handles the minimum of functions that you need to have your bot properly administer your channel, best for personal channels of 1 ~ 10 users)

• Standard Edition (This will be the most-useful version for "high-traffic" chat channels, with basic commands to handle USERLISTs, mass-op / mass-halfop / mass-voice, specialty-mode BANning, and other room maintenance functions)

• Bot Service Edition (Rather self-ex(planatory), this edition is the Standard Edition with additional administrative commands specifically written for use in for-lending bot services (which are found on most networks nowadays))

• Zenkai (全開) edition (Zenkai, which is colloquial Japanese for "Full-throttle," is simply all publicly-releasable beads that I've written. The Zenkai Edition currently has, in the private CVS collection, 215 total commands! Zenkai has everything in the Bot Service Edition, plus a few fun tools, functions, games, and other bits to amuse someone who may be alone in the channel and be waiting for someone to come visit them :)

[edit] Unpacking your script

Once you've chosen the version best suited to your needs, download the tarball (something.TAR.GZ file format), and put it in your bot's scripts directory. Use any method available to you: LYNX / WGET / FTP.

After you've put the tarball in your scripts directory, telnet / SSH to your scripts directory (if you haven't done so already), and enter this command:

tar zxvf (full tarball name)
(example: tar zxvf stormbot5.2.release.001.core_only.tar.gz)
(shortcut: type "tar zxvf storm" then hit the TAB key)

You'll start to see a feast of text display as each component starts to unpack itself from the tarball file and land in its appropriate target directory.

[edit] Editing your configuration file

When you finish with the TAR command, you will be looking at a bunch of files starting with "sb5_" for file names. The only one you need to consider is: sb5.tcl itself.

Open sb5.tcl in your favourite editor (for Windows users, I do not recommend NOTEPAD since CR/LF translation issues in Cygwin can play havoc with getting your bot online). You'll see various lines explaining each value, and your options for the settings. Scroll down to the line that says "SET THESE VALUES" and read-along with me ....

A walk-through:

• config set shortcut ""
  • This allows you to set the shortcut, or simple command trigger, that your bot will respond-to. For example, if your bot is named "Dumbledore" then plausible shortcuts could be "DD" or "DE" or even "AD" (Albus Dumbledore). If you leave this value blank, the script will automatically use the first and last characters of the bot's nick (in this case, "DumbledorE" --> "DE"). If you want more than one trigger to be registered, list them space-delimited (example: "AE DD DE")

• config set triggers_globaltwo ""
  • This sets-up another trigger that's usable on multiple bots, and can be used by any global tech (+t flag), master (+m), or owner (+n). Like the shortcut above, you may enter more than one, space-delimited. Common examples include "*Michelle* *Dave* -1- %Zbots%" and allow you a common BIND to use on multiple bots (to make more than one bot answer a shared trigger)

• config set triggers_globalthree ""
  • This sets-up another trigger that's usable on multiple bots, and can be used by any global-access user: voice (+v), halfop (+l*), op (+o), tech (+t), master (+m), or owner (+n). Like the triggers_globaltwo above, you may enter more than one, space-delimited

• config set home ""
  • This sets the home channel. The "home" channel is the channel that receives all "information messages" displayed by certain commands being used. This option is most useful to bot loaning services who like to monitor things like when users are banned from channels or when users log in. This is an OPTIONAL setting; leave it blank ("") if you don't want to use this feature.

• config set name_*
  • These settings are used to describe global admins' levels in a bot service-like hierarchy. The values are displayed in the outputs of various commands, such as: WHOIS, USERLIST and VERIFY (amongst others). These are completely optional, set them all to blank ("") if you don't want to use them.

• config set default_channel_options
• config set default_channel_modes
  • These two settings are the default channel settings for whenever you add a channel to the bot via the SB's JOIN command. (This has no effect on channels added via TCL's CHANNEL ADD command, nor the DCC / party line's ".+CHAN #<channel>" command.) This allows you to set default flood settings, need-* scripts, and default chanmodes for any channel you add to your bot, so that you don't have to add the settings manually, every time you JOIN your bot somewhere.

• config set cycle_time 60
  • For logged-in users, when you part a channel that the bot is on, (and you're not on any other common channels), the bot will log you out, since it can't "see" you anymore. (Think of someone seeing you part the channel, and wanting to steal your access, so they quickly disconnect, change their IDENT and HOST, then return on your nick, pretending to be you!) A "maximum security" setting would be to make the bot log you out immediately, forcing you to re-auth when you join the channel. However, if you're just cycling the channel to test your new GREET or COMMENT, it can be quite annoying. Therefore, this setting is a timer, in seconds, that the bot will wait for you to return (on the exact same nick, ident, and host) before logging you out. If you return BEFORE the timer expires, the bot does nothing (leaves you logged-in). If you're gone past that time frame, then you are logged-out automatically. I recommend that you set this to 0 (zero), but it seems most common to set it to 30 or 60 for most people.

• config set triggers_globalzero ***
  • This is just another trigger, that's usually made the same on every bot in a given channel (for bot services' HOME channels). When you have a bot service with 50 bots, having to add a server to each bots list, one-at-a-time, is very aggravating! This trigger is meant to be set on all bots in a given HOME channel, to be used as such (which will work on all bots who have this same setting):

*** servers add myserver.mynetwork.com

• config default cserv ""
• config default cserv_onchan 0
  • These two settings work together. If your network has a channel services bot (a CHANSERV, X, Q, K9, or the like), you can tell your bot who that services bot is, and whether or not is sits on channels visible (like Q / X / K9), or floats off channel (like ChanServ). Certain commands need to know if your chanserv bot can be found on the channel normally, which then lets it test: is the bot available for commands (by being present if it's supposed to be) or not. Set the first value to the nick your chanserv uses, and the second value (cserv_onchan) to 0 (floats off channels) or 1 (is visible on channels).

• config set dcc_support 1
  • The original way to run the EGGDROP core commands was to do a DCC CHAT, then issue commands in the PARTY LINE, stating with a full stop / period, as in: ".say #BotHouse Welcome, new user, to #BotHouse!" Well, people behind certain firewall configurations, internet café's, and LAN's can't use DCC CHAT properly / normally, which is why StormBot.TCL and other scripts like it became popular: to control the bot outside of the party line. The natural consequence is that some people, who like using DCC CHAT to run commands, liked StormBot.TCL's command method and wanted it in DCC CHAT usage as well. This setting, 0 (off) / 1 (on), activates StormBot.TCL's command binds in DCC CHAT so you may use them much in the same way in, or out of, DCC CHAT. You still have to use the period, instead of the bot's nick, as the trigger; other than that, the command syntax is the same either way.
    • Please note: if you use this setting, two things happen:
      • All the original EGGDROP core commands are rebound so they are still usable: ".channel" becomes "./channel" (just add a slash before the command name)
      • Once you activate this setting, there are only 2 ways to restore the original DCC CHAT binds:
        • (1) remove the call to StormBot.TCL in our bot's configuration file, then RESTART your bot (REHASH WILL NOT RESTORE THE BINDS)
        • (2) Use StormBot.TCL's UNLOAD command, which will restore all original binds, because it stores them for this purpose before taking-over DCC CHAT binds

• config set default_output "notice"
  • By default (and design), EGGDROP core, and all chanservs, output responses to users via the /NOTICE format. Generally speaking, IRC netiquette insists that you do not respond to information /NOTICEd to you. However, WebTV users, for some damned reason, have a chat client that does NOT process /NOTICE messages at all; they're never seen. This setting allows you to change the output method to the more-commonly used method between users: /MSG. Valid settings: NOTICE, MSG, and CHAN.

• config set default_language "English"
  • This is an unused setting that I put in place for future language-pack use. For now, the value is ignored; leave it set to the default.

• config set hidden_host ""
  • For networks that use UnReal IRCd, or similar IRCds, user mode +x sets a hidden (masked) host for you, changing your host from "4C73CE1F.ipt.aol.com" to "net-11662.ipt.aol.com" to keep your real IP private. This is an anti-hacker measure to prevent your computer's IP address from being revealed. (There are ways around it, but that's another lesson for another day.) Set this value to wildcard-match the hidden host portion of your network's host mechanism. For the above example, "net-11662.ipt.aol.com," you would set this value to "net-*"

• config set rehash_lag 0
  • This setting is, in seconds, how much time to delay from the time you use the "*** REHASH / RESTART / SAVE / BACKUP" command, and the time it executes. For those who run many bots from one machine (even under one account), having 50 bots trying to SAVE their userfile at the same time, then REHASH afterwards (REHASH and RESTART both perform an internal SAVE first), causes a ferret-load of system lag. In more extreme cases (with slower machines), 10 bots can lag almost 3 minutes behind in a mass-REHASH. Using this setting, on a bot-per-bot basis], allows you for make each bot trigger after a different delay, staggering the activity, so that there are only 1 or 2 bots performing the REHASH, et al, at any given second. Spacing bots 5 seconds apart, each, usually is sufficient. If you're running 5 bots, or less, from the same machine, you can safely set this to 0 (perform immediate REHASH, et al).

• config set bot_data_file ${nick}.data
• config set bot_data_file_log_command ${nick}.command.log
• config set bot_data_file_log_mode ${nick}.mode.log
• config set bot_data_file_log_command_admin ${nick}.admin.command.log
  • These 4 settings are for the file names for the various log files StormBot.TCL keeps (for the commands: LOGFILE, LASTCMDS, and a few others). I recommend that you leave the default names in place. Only if the file name conflicts with you operating system's valid character set should you change these values.

• config set check_cpu_stress 0
  • This setting does an every-minute check of your bot's MEM% and CPU% usage, based on the PS & TOP command replies. If you set this on (1), the bot will constantly check its MEM% / CPU% usage and warn you if either number hits 50%, or kill itself if it hits 75%. Default is 0 (off); only turn this on if you REALLY need it.

• config set user_dat_table {several lines of text}
  • This is a composite, nested-level setting. These names, numbers, and number-ranges are use to calculate the difference between the internal access level settings. If you're not familiar with nesting bracing, DON'T TOUCH THE DAMN THING !! If you do, then: be careful.

[edit] Starting up the bot

• If your bot isn't running yet (it's not online), but it has a USERFILE already, type:
  • cd <bot's home directory>
    • (if bot has a userfile already) ./eggdrop <configuration file>
    • (if it's your first time running the bot) ./eggdrop -m <configuration file>

• If your bot is already up and running (and it's NEVER had StormBot.TCL loaded before), then do:
  • /msg <botnick> REHASH <your_password>

• If your bot already had StormBot.TCL loaded, and you're just updating the script, then do:
  • /msg <botnick> REHASH
  • (or, in any of the bot's channels) <botnick> REHASH

The normal, EGGDROP core sequence for commands is to use your password with each and every command (don't worry, it's safe to do so). However, since StormBot.TCL keeps track of your LOGIN, you don't have to do that any more. But, before StormBot.tcl is loaded, you have to use that syntax. Once you do this command, then StormBot.TCL will be loaded, and you just have to do the LOGIN once, as will become the norm, and you'll be set.

[edit] Verifying StormBot.TCL is loaded

Once you've loaded StormBot.TCL onto your bot and gotten your bot online, there's an easy way to verify that the script is loaded:

<bot> version

The bot, if it has StormBot.TCL loaded, will tell you some version information.

<Tonks> I am Tonks :: EGGDROP v1.6.18 :: TCL v8.4.14 :: Stormbot 5.2.release.001i.zenkai

[edit] Using the 'permsettings' file

(Need to add the info)