Frequently Asked Questions

For a quick start, edit the eggdrop-basic.conf file. To take advantage of all Eggdrop’s features, we recommend using eggdrop.conf instead. It is also a good idea to rename the file to something easy to remember and specific to your bot, like botnick.conf.

Type ./eggdrop -m for the first time ever starting your bot, after the botfile.user is created, use just ./eggdrop

How do I make the bot auto-op people?

Remember that auto-op is a potential security risk.

To make the bot auto-op all +o users who join the channel, set the channel settings to +autoop by typing .chanset #channel +autoop. If you have the channel defined in the config file, make sure you also change the autoop setting there.

You can also make the bot give auto-ops to specific +o users (instead of all +o users) using the a flag, without the need to enable autoop. Use .chattr <handle> +a #channel to make the bot auto-op that particular user when they join the channel.

How do I make the bot auto-voice people?

To make the bot auto-voice all +v users who join the channel, set the channel settings to +autovoice by typing .chanset #channel +autovoice. If you have the channel defined in the config file, make sure you also change the autovoice setting there.

You can also make the bot give auto-voice to specific +v users (instead of all +v users) using the g flag, without the need to enable autovoice. Use .chattr <handle> +g #channel to make the bot auto-voice that particular user when they join the channel.

To make the bot give voice to everyone who joins, you will need to use a Tcl script. Visit the Tcl Scripts section to find an autovoice script.

How do I convert a 1.1.5 userfile to 1.3/1.4/1.6?

Upgrading the userfile from 1.1.5 to 1.3/1.4/1.6 format is relatively painless. First, make sure you backup the userfile by downloading it to your system, just in case something goes wrong. After installing your new 1.3, 1.4, or 1.6 bot, place the old 1.1.5 userfile in the directory you installed Eggdrop to (i.e. in the same directory as eggdrop.conf.dist) then type tclsh scripts/weed <userfile> c, where <userfile> is the name of the userfile to convert.

Where can I get a free shell to run an Eggdrop?

At any given time, there are typically no shell providers I'm familiar with that offer Eggdrop shell accounts for free that you'd reasonably expect to get an account from on application. Eggdrops are a relatively resource-intensive, and they often attract denial of service attacks. A provider offering free shells for Eggdrop users would also attract a large number of abusive users. Therefore, offering free shells which allow Eggdrop would be detrimental any provider. A provider that does offer Eggdrop shells for free is either going to be very hard to get an account with, or will otherwise likely be unreliable, insecure, and probably won't be offering free accounts for long.

Although there are rarely providers offering free accounts, there are several ways people do get a shell account without paying a commercial shell provider - many have a friend with their own shell box and are given an account for free, and some people are involved in referral programs for shell providers and are rewarded with an account in return. Unfortunately, there are also more malicious users who break into servers and run their bots illegally or steal other peoples' credit card info and use it to buy a shell (giving Eggdrop an undeserved reputation as a malicious program).

My hostmask has changed - how can I add it to the bot?

Your bot recognises you by the hostname you have on IRC (e.g. cooldude@ppp42.fastisp.net). It compares this hostname with the hostmasks contained within your user record (e.g. *!cooldude@*.fastisp.net) and will recognise you if they match. If you change your ident or get a new ISP, your bot will not recognise you and will not respond to your DCC chat requests.

Eggdrop has a built in msg command called ident that is used to make the bot recognise you after your hostname has changed. The syntax is /msg <botnick> ident <password> [nickname]. The nickname portion is only required if you're using a different nick from the one your bot knows you by (e.g. if your user record on the bot is 'CoolDude' but you're using 'CoolDude2' on IRC, you'll need to specify 'CoolDude' as the nickname).

Note that if you used the advanced or complete example config file that's included with Eggdrop to create your config file, your bot may have disabled the ident command, or you may have changed it to something different. Look for the following section in your bot's config file:

# Many takeover attempts occur due to lame users blindly /msg ident'ing to # the bot and attempting to guess passwords. We now unbind this command by # default to discourage them. You can enable these commands by commenting the # following two lines. unbind msg - ident *msg:ident unbind msg - addhost *msg:addhost

To reactivate the ident command, add the following line just below the above lines:

bind msg - ident *msg:ident

If you'd like to set your ident command to something different, you can replace ident with another word (note that you don't change the *msg:ident bit - that stays the same).

The ident function isn't the only way to add new hostmasks. You can add, remove and modify your hosts using the .+host and .-host DCC commands. Type .help +host and .help -host for more info on using these commands. Of course, to use these DCC commands, you must already be logged into the bot, so you'd have to add any new hostmasks before your ident and/or host changes.

How do I kill the bot from the shell?

First, you need to find its pid number by typing ps x. You will see a display similar to the following:

PID TTY STAT TIME COMMAND 5127 ? S 2:55 ./eggdrop coolbot 28033 pts/0 S 0:00 -bash 28764 pts/0 R 0:00 ps x

Once you have the pid number, you need to type kill <pid>. In the above case, you would use kill 5127. If that doesn't work, try using kill -9 (e.g. kill -9 5127).

How do I telnet to my bot?

Opening a telnet session directly to your bot is similar to opening a DCC chat session - you will be placed in the command console and can control your bot with DCC commands. The difference is that telnet is not dependant on IRC, so you don't need to be on IRC to telnet to the bot.

To telnet to your bot, you must specify its hostname and port in your telnet client. The hostname is the same as your bot's vhost - e.g. if your bot's host on IRC is cooldude@cool.niceshell.com, you would telnet to cool.niceshell.com. The port you need to specify depends on the listen port you have set in the bot's config file, e.g. if you have listen 4941 all, you need to telnet to port 4941.

If you have enabled protect-telnet in the bot's config file and are having trouble opening a telnet session with your bot, you'll need to check that you've created a telnet mask for yourself. A telnet mask looks like -telnet!*@host.goes.here. If you want to telnet from *.yourisp.com for example, you'll need to add that as a telnet host by typing .+host YourNick -telnet!*@*.yourisp.com.

I lost my bot password! How do I get it back?

There's no simple way to recover the original password you set on the bot. You need to edit the bot's userfile directly and reset the password. The userfile is usually in your bot's main directory and has the .user file extension, e.g. NiceBot.user. There are two ways you can do this - either telnet to the shell and edit the userfile in the shell's text editor (e.g. pico), or FTP to the shell, download the userfile, edit it on your system, then upload it to overwrite the existing one.

First, kill the bot from the shell (if you don't do this, the bot may overwrite any changes you make to the userfile). Then find your entry in the userfile. The example below shows a user entry for "sisrv":

CoolDude - p ! #pigs 910669920 fo ! #cows 952889739 fo --HOSTS *!sisrv@*.sisrv.net --PASS +vGjzQ0zcBbK/

Delete the password line, e.g. --PASS +vGjzQ0zcBbK/. This will delete the your password.

You can now restart your bot. When your bot appears on IRC, you will need to set your password again using the msg command, i.e. /msg botnick pass <password>.

How do I make a NO_IRC (or limbo) bot?

Many users like to create a 'limbo' or 'offline' bot to use as a hub bot. A limbo bot can make a more reliable hub as it devotes its resources to bot linking - it doesn't have to deal with servers and channels. It is also more secure and less prone to attacks. The main downside of a limbo bot is that it's less convenient to access (you need to telnet directly or 'relay' to them - you can't DCC), and it does count as a background process on your shell.

Making a noirc or limbo bot with Eggdrop 1.3, 1.4 and 1.6 is reasonably simple - look for the lines loadmodule server, loadmodule ctcp, loadmodule irc and loadmodule uptime (for 1.6.7 and later) in the bot's config file. Comment out these lines by placing a # (hash) character in front of them. Shut down and restart the bot, and it will be ready for noirc or limbo purposes.

The main problem you may encounter with a limbo bot is errors when you try to start it. These are generally caused by Tcl scripts that are designed for server and channel interaction (e.g. a 'seen' script). Check the bot's config file and make sure you're not trying to load these types of scripts. Also be sure to set a botnet-nick in the config file, and comment out or remove any unbind msg lines that you may have used from the example config.

Is it possible to link different versions of Eggdrop together?

Yes. Linking and sharing will work between different versions of Eggdrop 1.3, 1.4 and 1.6 bots. Older bots, such as the 1.0 and 1.1 series, will be able to link to 1.3, 1.4 and 1.6 bots but will not be able to share userfiles with the newer versions.

How can I run multiple bots from one installation?

Some people run more than one bot from one installation to save disk space. All you need to do is make sure each bot has its own config file and different botchk files (e.g. Horse.conf and Horse.botchk, and Donkey.conf and Donkey.botchk would be one way to organise the files), and in each config file, make sure the bot has its own userfile, channel file, and log files defined in those configs. To start the two bots separately, all you'd need to do is type ./eggdrop Horse.conf and ./eggdrop Donkey.conf.

How can I add public commands?

Eggdrop has no built-in public commands (except for 'seen' if you load the seen module). You will need a third-party Tcl script to add public commands. You can find several public command scripts in the Tcl Scripts section. Note that public commands are less secure than msg and DCC commands - even scripts that contain some form of authorisation can be vulnerable to abuse.

How do I backup the userfile?

It is important to make regular backups of your bot's userfile on your system, instead of relying on the backup file on the shell. To make a backup, all you need to do is FTP to the shell and download the bot's *.user file (e.g. Donkey.user) to your system. If something goes wrong, and the userfile is lost, you can then upload your backup file to the bot's directory and type .reload in DCC to restore it.

How do I make my bot restart automatically using crontab?

You can either use the autobotchk script, or you can edit the botchk file and crontab manually. You can find info on how to do this in the setup guide.

How can I view all users who have been added to the bot?

Simply type .match * 999 in DCC. Note that if you have a large userfile, this command may flood you with a lot of text.

How can I make my bot join a keyed (+k) channel?

The simplest way to do this is to set the channel's key in the enforced modes by using the chanset command, e.g. .chanset #channel chanmode +nstk <key> (you can view the current enforced modes using .chaninfo #channel). The bot will then automatically use that key to join.

Alternatively, if you don't want +k to be enforced by the bot for whatever reason, you might want to try a script for making the bot join keyed channels.

How do I update / upgrade my Eggdrop to the latest version?

If you're upgrading within the 1.6 series, this is reasonably simple. It basically involves following the usual steps when setting up Eggdrop, but when you get to the "make install" step, you specify the directory your existing bot is in. Let's assume your existing bot is a 1.6 series bot in the directory /home/nicedude/coolbot and you are upgrading to 1.6.21:

1) Download the latest eggdrop source (e.g. eggdrop1.9.1.tar.gz).
2) Telnet and FTP to your shell.
3) Upload eggdrop1.9.1.tar.gz via FTP.
4) In telnet type tar zxvf eggdrop1.9.1.tar.gz
5) Type cd eggdrop1.9.1
6) Type ./configure
7) Type make config (compiles all modules) or make iconfig (allows you to select the modules to compile).
8) Type make
9) Type make install DEST=/home/sisrv/bot

The existing bot that's in /home/nicedude/coolbot will be updated, and you'll just need to shut down and restart the bot to complete the upgrade. Note that the old Eggdrop executable and modules directory will be renamed with a trailing version number (e.g. eggdrop-1.6.17 and modules-1.6.17) rather than deleted. You can safely delete these if you wish.

Where can I find an encrypted Eggdrop to prevent my bot from being cracked?

You probably won't find a publicly available Eggdrop with functions for encrypting its userfile, scripts, and other files. The methods that are used to make encrypted bots rely on the source code being kept secret from attackers if they are to provide a worthwhile level of security. Petersen offers a more detailed answer to this question:

you won't get one easily. the reason being is that such encryption schemes almost always rely on statically compiled encryption keys. thus if the source was given out it would be trivial to decrypt anything crypted with them. only real way to encrypt your userfiles is to write the crypto routines yourself (or employ someone to write them for you).

let me elaborate. There are 2 ways to make an ecryption module. Either you statically compile the full encryption keys into it somewhere (or into a file readable by it), or you make it read a commandline option for the keys.
If you have the source for the module, you can (with enough knowledge) work out exactly where the encryption keys are stored in the module binary if they are linked into it. Even if they aren't linked into it, with the source you can work out where the keys are stored in a mem dump of a running eggdrop process. Thus the only way to make it in any way useful is to use your own code, so that the keys are stored in the binary/ram in a completly unique place compared with everybody elses egg. Combined with stack encryption routines, and automatic fork() if the process gets traced, it makes it very difficult to get the routines out of the binary at all. Even saying all this, as long as someone gets a shell with your UID, there isnt anything you can do that can make it impossible for them to get the crypt routines from a running bot. For most ppl this isnt gonna be a problem, because most script kiddies wouldnt know how to do this anyway. But if a widely avaliable open source crypto module was made avaliable as part of the eggdrop source, it would not be long before someone releases some util to crack that particular module (or worse, not release it and have lotsa ppl in a false sense of security).
Unfortunatly, security through obscurity is the only way if you don't trust the security of the box the egg is running from.

I want to learn to create my own Tcl scripts. Are there any tutorials?

By far the best tutorial on writing Tcl scripts for Eggdrop is SUNiNet's Guide to TCL scripting for Eggdrop. You can also download the Beginners Guide to TCL, which is quite old (written in the 1.1.5 era) but still useful. A must-read is Peterre's How to write eggdrop scripts that won't choke on brackets and other special characters.

You'll need a couple of references when scripting. The first is the doc/tcl-commands.doc file included with your Eggdrop, which explains Eggdrop's built-in Tcl commands. The second is the Tcl Manual itself, which contains an indispensable reference of Tcl's own commands which can be used in your scripts.

Examining scripts written by others is important to see how things are done. You can refer to scripts written by myself and others in the Tcl Archive.

Once you're somewhat comfortable with Tcl, you might want to check out the sprawling resource known as the Tcler's Wiki, which contains lots of useful info to improve your scripting.

How do I install Tcl on my shell account and point the bot to it during compile?

It's rarely necessary to install Tcl yourself, as it's usually already on the system. However, if the bot can't find Tcl, or you want to use a version that isn't present on the system, you may want to install your own copy. KuNgFo0 has written a nice little three-step guide at his Egg FAQ site explaining how to do this. Visit the How to Compile Eggdrop page and scroll down to the bottom section on installing Tcl and telling the bot where it is.

Can I connect a single Eggdrop to more than one IRC network/server?

No. Nor will such functionality be added to Eggdrop, because it creates a significant problem for commercial shell providers as well as administrators of private shells.

The number of IRC connections a bot has is a major factor in determining how taxing the process is on the provider. Additional IRC connections do two things - take up valuable I:lines on major IRC networks (which can prevent others on the same shell from connecting) and increase the risk of DoS attack against the shell by creating additional targets. Allowing a single process to have a single IRC connection keeps things manageable.

There is a bot, EnergyMech, which does have the ability to connect to multiple servers, but some shell providers have banned this bot because of this capability.

Does Eggdrop support SSL and IPv6?

Support for SSL and IPv6 are two commonly requested features that are unfortunately not implemented in Eggdrop 1.6. Third-party patches that add SSL or IPv6 support are available, but they are known to cause crashes for some users, and these issues should not be reported to Eggdrop development. Official support for both SSL and IPv6 is coming in Eggdrop 1.8, and you can download the development version from Eggheads.

Whenever a nick is opped on #channel, my bot deops them!

Run through the following possible causes:

a) If the nick is being opped by a special user that doesn't appear on the channel (e.g. ChanServ), you will need to make sure the allow-desync option is set to 1 in your bot's config file.
b) Check the channel's bitch settings. Type .chaninfo #channel in the bot's console to do this. If the channel is in +bitch mode, type .chanset #channel -bitch to switch it off. Bitch mode allows only +o users to receive op.
c) Check the channel's revenge settings. Type .chaninfo #channel to do this. If the channel is +revenge, type .chanset #channel -revenge to switch it off. Revenge can cause your bot to give someone the +d (deop) flag if they do something naughty (e.g. deop a bot).
d) Make sure the bot hasn't added the +d flag to the user. Type .whois <user> to check for this. If the +d flag is there, use .chattr <user> -d #channel to remove it. Users are often added with the +d flag if your bot is in revenge mode.

My bot keeps changing the channel modes. How do I stop it?

You need to change the enforced channel modes in the channel settings. If the enforced modes are set to something like "+nst-ik", the bot will force the channel to have +nst, and remove +i and +k if either is set on the channel. Type .chaninfo #channel in the console to view the current enforced modes (it is the first item, listed next to Protect modes).

To change the enforced modes, type .chanset #channel chanmode <modes>. Setting .chanset #donkey chanmode +nt, for example, will force the channel to have +n and +t active, but won't interfere with any other modes.

I have enabled +greet and added an info line to a user, but the bot isn't greeting them when they join. Why not?

By default, the bot will not greet a user when they join a channel unless that specific channel exists in their user record. Use .whois <user> to check if they have one, and if not use .+chrec (type .help +chrec for more info) to add one.

Alternatively, you can add the no-chanrec-info setting to the config file, as shown in the example in eggdrop.complete.conf, and set it to 1. The bot will then greet users without the need to set a channel record.

Note that the bot may not greet you until you've been off the channel for a few minutes (this is set by wait-info in the config file, and defaults to 180 seconds), so cycling to test the greet may not work. Try leaving the channel for about five minutes then rejoin and see if the bot greets you then.

I'm changing channel settings in my bot's config file, but the bot is ignoring them, even after I restart it. Why?

The settings in your bot's 'chanfile' are overriding those in the config file. You need to use the .chanset DCC command to modify the chanfile's settings (e.g. to change +dynamicbans to -dynamicbans on #donkey, use .chanset #donkey -dynamicbans). Type .help chanset for more info on using this command. Remember to change the settings in the config file as well if you want to keep things consistent.

Refer to the section on channel settings for more information about how the chanfile interferes with channel settings in the config.

I get the error `You have installed modules but have not selected an encryption module, please consult the default config file for info` when I try to start my bot. How do I fix this?

You need to load the blowfish encryption module. Look for the line checkmodule blowfish in your config file - if it's commented out (has a # in front if it), delete the # to uncomment it. If you can't find the checkmodule blowfish line in the config file, you will need to add it yourself.

My bot is having trouble with nicknames longer than 9 characters. How do I fix this?

With Eggdrop 1.6, the nick length allowed on your network type will be set automatically provided net-type is set correctly in the bot's config file. You can adjust the nick length manually using the nick-len setting in the config.

Eggdrop 1.4 and earlier, by default, only allow nicknames to be 9 characters long. If you want to use it on networks with long nicknames (e.g. DALnet), you need to change a setting defined in eggdrop.h before compiling the bot. To do this, FTP to the shell, download src/eggdrop.h, then open the file in a text editor. Find the NICKMAX setting and change it to the maximum number of characters allowed by your IRC network, then save the file and upload it (overwriting the existing eggdrop.h). Of course, you can edit the file directly on the shell if you prefer to do so instead of downloading, editing locally, then uploading it.

Even if you change the nick-len or NICKMAX setting, user handles will still be limited to 9 characters. To increase the handle length above 9 characters in Eggdrop 1.6 or Eggdrop 1.4 and earlier, you need to change the HANDLEN setting in src/eggdrop.h before compiling. Note that your bot will only be able to link with bots compiled with the same HANDLEN setting. Since most bots are compiled with the default of 9, this should be taken into consideration before you change it.

I get the error `invalid command name "channel"` when I try to start my bot. What have I done wrong?

This usually means you missed the make install step that you need to do after make when compiling your Eggdrop. Refer to the setup guide for correct setup instructions.

Another possible cause is specifying your channels in the config file before the line that loads the channels module. Look for the line loadmodule channels in your bot's config file, and make sure you're defining your channels somewhere below this line.

When I try to start my bot I get the error `Hostname self-lookup failed` or `Couldn't assign the requested IP.` How do I fix this?

This means the bot isn't able to resolve its own hostname on the shell (possibly due to a server misconfiguration). Try setting the my-hostname and my-ip settings in your bot's config file to the correct hostname and IP of your shell (e.g. set my-hostname "shell1.niceshells.net" and set my-ip "555.43.254.133"). Alternatively, try using set my-hostname "localhost" and set my-ip "127.0.0.1" exactly as shown.

Why is my bot displaying strange messages like 'MSG33A'?

This may occur if the language files your bot is using don't match the version of Eggdrop (e.g. you're using a language file written for 1.3.23 on a 1.3.27 bot). Typically, new language files will be copied over when you upgrade the bot to a new version, but if you're getting these errors, you will need to make sure your bot's language files are up-to-date. Refer to the section on Using Language Files for more information.

Another possible cause of this error is if you start Eggdrop from a directory other than the one the bot resides in. This is because Eggdrop looks for language files based on the current directory. Try changing to the bot's directory (e.g. cd /home/mutant/turtlebot) then launch the bot from there.

I get the error `couldn't grab nearby port` when I try to start my bot. How do I fix this?

The most common cause of this problem is the listening port you've selected in the config file is already in use by another process on the shell. Look for the line where you've set the port (e.g. listen 3333 all) in the config file, and try several different ports to see if it fixes the problem. If your shell provider specifies a port range to choose from, follow that. Otherwise, you can generally choose a port number between 1024 and 65535, although the private/dynamic 49152-65535 range is best. Keep in mind that 'pretty' numbers like 1234 or 8888 are the most likely to be already in use on a shell that hosts many other bots.

If changing the port doesn't fix the problem, it's possible that your my-ip and my-hostname settings are incorrect. Double check these settings in the config file.

If neither of the above work, you can solve the problem by commenting out or removing the listen command in the config file. Unfortunately, if you have to do this, the bot will not have a telnet port. This means you won't be able to telnet to the bot directly, and you won't be able to use it as a hub bot.

When my bots try to share userfiles, they disconnect with the error `Lost userfile transfer`. How do I fix this?

Make sure the my-hostname and my-ip settings are correctly set in each bot's config file.

I loaded botnetop.tcl, but my bots are not opping/inviting one another!

If you loaded botnetop.tcl and your bots are not opping/inviting one another, or are not sharing keys, raising limits, or unbanning one another when required, try the following steps to diagnose the problem. For problems sharing keys, raising limits, or unbanning, follow the same steps as for diagnosing an invite problem.

You will need to choose two of your bots (an opped one and a non-opped, or one that is opped on the channel and another that's trying to get invited) to try the following steps with. To make things easier to explain, I will call one bot GiveBot, which will represent the opped bot or the one that is on the channel, and the other bot WantBot.

1. Make sure the bots are a supported Eggdrop version. botnetop.tcl requires Eggdrop 1.3.22 or later with Tcl 7.6 or later. Windows ports aren't officially supported, although I suspect the script would probably work fine on such bots as long as they're based on 1.3.22 or later.

2. Make sure the botnetop.tcl component is loaded on both bots. If you're running netbots.tcl, type .components in the console of both GiveBot and WantBot, and make sure botnetop is listed in the "Loaded components". If you're running the standalone botnetop.tcl, type .rehash and make sure the Loaded botnetop.tcl... message appears.

3. Make sure the bots are linked. Type .bots or .bottree to check.

4. The bots must be added as users to one another, and their hostmasks must be correct and up-to-date.

If both bots are on the channel, type .channel #channel on GiveBot. If the handle for WantBot appears as an asterisk (*), it is not being recognised, either because WantBot is not added as a user on GiveBot or, more likely, none of the hostmasks in its user record match its current hostname on IRC. On GiveBot, type .whois WantBot to check WantBot's hostmasks and, if necessary, add a new hostmask. Repeat this step in WantBot's console (i.e. use .channel and .whois to check GiveBot's details).

If one of the bots isn't on the channel (e.g. invite problem), the .channel command is of no use. Instead, type .whois WantBot in GiveBot's console, then /whois WantBot on IRC. Check that one of WantBot's hostmaks matches its IRC hostname. Repeat this step for checking GiveBot's details on WantBot.

5. The bots must have +o status for one another. On GiveBot, bot type .whois WantBot to check that it has either global +o in its user record, or a channel +o for each channel WantBot is to get ops on or be invited to. On WantBot, type .whois GiveBot to check that it has +o as well.

6. Do you have multiple bots sharing a single ident and hostname? For example, GiveBot, WantBot, and MyBot all sharing the host cooldude@awesome.niceshells.com? If so, the bots may have trouble telling each other apart, and this can confuse botnetop.tcl. To resolve this problem, you should include each bots nickname in their hostmasks, e.g. WantBot!cooldude@awesome.niceshells.com instead of *!cooldude@awesome.niceshells.com.

7. If all the above steps checked out fine and the bots still aren't opping one another, try enabling bop_osync in your netset.tcl. If they aren't inviting one another, try disabling bop_icheck. If neither of these work for either problem, disable bop_hcheck. You can find more info about these settings in the components documentation.

Problems with Eggdrop's botname variable also explain some of the mysterious cases where the invite and unban functions don't seem to be working. Disabling bop_hcheck will fix invite problems, but there is no solution to the botname-related unban problem until Eggdrop versions beyond 1.6.6 address the botname problem.

Will you be adding userfile commands like .netadduser, .netchattr, and .net+ban to netbots.tcl?

No, no, and no. Aside from netpass, I won't be implementing any functions in netbots.tcl that are the domain of Eggdrop's userfile sharing. The reason for this is simply that one thing would lead to another and I'd end up having to duplicate (or create enhanced versions of) every share function to please people. If you want to activate this type of functionality, then use the share module. Yes, I know the share module can be annoying and unreliable, but that's not my fault.

It would, however, be possible for a third-party to create an add-on component script which adds these types of functions to netbots.tcl, if there is anyone out there who wishes to take on such a task.

Will you be adding chanfile sharing to netbots.tcl?

No. In most configurations, different channel settings will be required for different bots. For example, having +seen enabled on all bots is generally a bad idea, and security-concious people like to split up protection features such as enabling +protectops on several bots while disabling it on others. Having all bots use the same chanfile forces all bots to be on the same channels and have the same settings for each, which would be too inflexible for most people.

I have multiple bots running from the same directory. How do I use netbots.tcl in this setup?

You could simply have one netbots.tcl installation (directory), including one copy of netset.tcl (using nb_set to customise the settings for each of the different bots).

If those are the only bots you are running, things should be fine. However, if you have bots on other shells, and want to use netupdate between the bots, things can be problematic, as netupdate wasn't really written with the idea that multiple bots may be run from the same directory. Let's say you have three bots running on the same shell from the same directory, and initiate a netupdate from a bot on a different shell. A .netupdate -config will be fine: the three bots will each receive and update their own config file. However, with a .netupdate -scripts, the bots may receive and update the same files simultaneously, which can cause problems.

You could use .control to make sure only one of the bots receives the update, or disable netupdate on all except one of the bots that are in the same directory. However, both these solutions can prevent the other bots from receiving files they may need, which is likely to be a problem. A less problematic solution may be to use .control or the bot argument of .netupdate to update each of the bots one at a time, but this can be tedious and it may be easier simply to update the files manually via FTP.

Not even mentioned yet are additional problems which might arise if you attempt to netupdate between bots in the same directory, particularly if the smart update feature is not enabled.

The "final solution" would be to give each bot its own netbots directory. Unfortunately, netupdate currently requires every bot to have its files in the same relative location. A future version of netbots.tcl should remove this limitation and officially support multiple bots in the same directory.

Is there a way to have custom sentinel.tcl settings for different channels, or to disable it on certain channels?

Unfortunately not. I probably won't be implementing custom settings for each channel (e.g. per-channel flood settings and lock times) as this would over-complicate the settings section of the script, particularly in future versions where array settings are reserved for a different purpose in some of the settings.

As for disabling the script on certain channels, a setting for this is a possibility. The main reason I haven't implemented such as setting is that it's optimal, for the bot's stability, that it be able to lock any channel it's on in response to a flood. Disabling it on a channel creates a hole - if a flood is allowed to go unchecked on that channel, it's not only a threat to that one channel, but to the stability of the bot itself and the other channels it's protecting. Given that, I'd have to hear enough real-world examples of where such a setting would be needed before I implement it.

Knowledgebase

Categories