Botmaster cheat sheet#

For botmasters (+n/+m). Your job is managing the bot’s user records — adding, finding, changing, and removing the people the bot knows about. That includes adding new members so their feature prefs (like a saved weather default) stick (see Adding a non-privileged member).

You have partyline access, so partyline (.command) forms lead here. If you’re not on yet, see Joining the partyline.

The bot does not auto-add users (learn-users 0). Every record is botmaster-created — there is no self-registration path for members. If someone needs a record, you create it.

Adding a user#

If the user is present in the channel:

.adduser <nick>

.adduser Creates a new user record for a user on the channel, using their current hostname.

If the user is not present in the channel:

.+user <handle> <hostmask>
  • <handle> is the bot record name (a short, stable identifier; often the member’s usual nick).
  • <hostmask> is how the bot will recognize them — see Hostmask formats.

Example:

.+user alice *!*@alice-dsl.example.com

After creating, set them a password (or tell them to set one via MSG pass — see the user cheat sheet):

.chpass alice <temp-password>

Finding a member’s hostmask#

If they’re in channel, the quickest way to get their current hostmask:

/whois <nick>

The output shows their nick!user@host — use that (wildcarded) as the hostmask when you .+user or .+host.

Hostmask formats#

Eggdrop matches on nick!user@host with wildcards. Typical safe choices:

PatternMatches
*!*@*.example.comanyone from that domain
*!ident@*.example.coma specific ident from that domain
alice!*@*the nick alice from anywhere (fragile — nicks are cheap)
*!*@192.168.0.*a subnet

Prefer host/ident-based masks over nick-based ones — a nick can be taken by anyone.

Finding a user#

.whois <nick>          look up by current nick (shows handle, flags, hosts, last seen)
.match <handle>        find a record by handle
.match *               list everyone
.userinfo <handle>     extra stored info for a handle

Changing flags and hostmasks#

Flags — .chattr#

.chattr <handle> <flags>          global flags
.chattr <handle> <flags> #chan    channel-specific flags

Common flags:

FlagMeaning
+oop (channel op). Global +o = op on every channel the bot is on.
+mmaster (can manage the bot’s channel settings)
+nowner (full bot control — hand these out very sparingly)
+ppartyline access
+ffriend (protected from some bans/limits)
+vvoice (channel)

Examples:

.chattr alice +o #motorcycles     give alice op on #motorcycles only
.chattr alice +o                  give alice global op
.chattr alice -o                  remove alice's global op

Hostmasks — .+host / .-host#

.+host <handle> <hostmask>     add a hostmask to an existing record
.-host <handle> <hostmask>     remove a hostmask

Members self-serve hostmask changes. /msg <bot> ident <password> re-matches a member for the current session and permanently adds their current host to their record — no botmaster needed. Point them at the user cheat sheet. You only reach for .+host to add a hostmask the member isn’t connecting from right now — a broader wildcarded mask, or a host for someone who’s offline.

Adding a non-privileged member#

Most members just need a record so their feature prefs (like a weather default) work — no flags, no special privileges. On this fleet default-flags is empty, so a freshly .+user’d member is non-privileged by default: no +o, no +m, no +n, no partyline. You don’t have to do anything special; just don’t add flags.

Verify with .whois — confirm the flags line is empty (no +m/+o/+n):

.+user alice *!*@*.example.com
.whois alice
# → check: no +o/+m/+n in the flags output

Only add flags deliberately, when someone actually needs them.

Removing a user#

.-user <handle>

Removes the record and all its hostmasks/flags. Use with care.

Symptom: “the bot isn’t recognizing me”#

If a member says the bot isn’t recognizing them — .wzset claims they have no default, or the bot ignores them — it’s almost always a hostmask mismatch. First .whois <nick> and check their hostmasks against their current host (shown in the .whois output).

First-line fix: have the member ident. /msg <bot> ident <password> re-matches them for this session and permanently adds their current host to their record, so they’re set going forward — point them at the user cheat sheet. No botmaster action needed for the usual “my IP changed” case.

You only need .+host <handle> <new-hostmask> when the member can’t ident from that host right now — they’re offline, or you want to add a mask that isn’t their exact current host (a wildcarded domain, a future host).

If whois finds no record at all, it’s not a hostmask issue — create one with .+user (see Adding a user).