mirror of https://github.com/Mikaela/Limnoria.git
241 lines
10 KiB
Plaintext
241 lines
10 KiB
Plaintext
Q: Why does my bot not recognize me or tell me that I don't have the
|
|
"owner" capability?
|
|
|
|
A: Because you've not given it anything to recognize you from!
|
|
You'll need to identify with the bot ("help identify" to see how
|
|
that works) or add your hostmask to your user record ("help
|
|
addhostmask" to see how that works) for it to know that you're you.
|
|
You may wish to note that addhostmask can accept a password; rather
|
|
than identify, you can send the command "addhostmask myOwnerUser
|
|
[hostmask] myOwnerUserPassword" and the bot will add your current
|
|
hostmask to your owner user (of course, you should change
|
|
myOwnerUser and myOwnerUserPassword appropriately for your bot).
|
|
|
|
|
|
Q: What's a hostmask?
|
|
|
|
A: Each user on IRC is uniquely identified by a string which we call
|
|
a "hostmask." The IRC RFC refers to it as a prefix. Either way,
|
|
it consists of a nick, a user, and a host, in the form
|
|
nick!user@host. If your Supybot complains that something you've
|
|
given to it isn't a hostmask, make sure that you have those three
|
|
components and that they're joined in the appropriate manner.
|
|
|
|
|
|
Q: How do I make my Supybot op my users?
|
|
|
|
A: First, you'll have to make sure that your users register with the
|
|
bot. They can do this with the "register" command. After they do
|
|
so, you'll want to add the #channel,op capability to their user.
|
|
Use the "channel addcapability" command to do this. After that,
|
|
your users should be able to use the "op" command to get ops.
|
|
|
|
If you want your users to be auto-opped when they join the channel,
|
|
you'll need to load the Enforcer plugin and turn its autoOp
|
|
configuration variable on. Use the "config" command to do so.
|
|
Here's an example of how to do these steps:
|
|
|
|
<jemfinch> I'm going to make an example session for giving
|
|
you auto-ops, for our FAQ.
|
|
<dunk1> ah ok ;]
|
|
<jemfinch> First, I need you to register with supybot, using
|
|
the "register" command (remember to send it in
|
|
private).
|
|
<dunk1> done
|
|
<jemfinch> what name are you registered under?
|
|
<dunk1> dunk1
|
|
<jemfinch> ok, cool.
|
|
<jemfinch> @channel addcapability dunk1 op
|
|
<supybot> jemfinch: The operation succeeded.
|
|
<jemfinch> now use the "op" command to get ops.
|
|
<dunk1> @op
|
|
--- supybot gives channel operator status to dunk1
|
|
<dunk1> works!
|
|
<dunk1> ;]
|
|
<jemfinch> @load Enforcer
|
|
<supybot> jemfinch: The operation succeeded.
|
|
<jemfinch> @config channel supybot.plugins.Enforcer.autoOp On
|
|
<supybot> jemfinch: The operation succeeded.
|
|
<jemfinch> ok, now cycle the channel (part and then rejoin)
|
|
<-- dunk1 (dunker@freebsd.nl) has left #supybot
|
|
--> dunk1 (dunker@freebsd.nl) has joined #supybot
|
|
--- supybot gives channel operator status to dunk1
|
|
<jemfinch> cool, thanks :)
|
|
|
|
|
|
Q: Can users with the "admin" capability change configuration
|
|
variables?
|
|
|
|
A: Currently, no. Feel free to make your case to us as to why a
|
|
certain configuration variable should only require the "admin"
|
|
capability instead of the "owner" capability, and if we agree
|
|
with you, we'll change it for the next release.
|
|
|
|
|
|
Q: Can Supybot do factoids?
|
|
|
|
A: Supybot most certainly can! In fact, we offer three full-fledged
|
|
factoids-related plugins!
|
|
|
|
Factoids (written by jemfinch) is Supybot's original
|
|
factoids-related plugin. It offers full integration with Supybot's
|
|
nested commands as well as a complete 1:n key to factoid ratio,
|
|
with lookup by individual number. Factoids also uses a
|
|
channel-specific database instead of a global database, though
|
|
that's configurable with the
|
|
supybot.databases.plugins.channelSpecific configuration variable.
|
|
|
|
MoobotFactoids (written by Strike) is much more full-featured,
|
|
offering users the ability to define factoids in a slightly more
|
|
user-friendly way, as well as parsing factoids to handle <reply>,
|
|
<action>, and alternations (defining a factoid "test" as
|
|
"<reply>(foo|bar|baz)" will make the bot send "foo" or "bar" or
|
|
"baz" to the channel (without the normal "test is " at the
|
|
beginning)). If you're accustomed to Moobot's factoids or
|
|
Blootbot's factoids, then this is the Factoids plugin for you.
|
|
Unfortunately, due to the more natural definition syntax (required
|
|
to be compatible with Moobot) you can't define Factoids with nested
|
|
commands; you'll have to evaluate the command first and then copy
|
|
the result into your factoid definition.
|
|
|
|
Infobot (written by jamessan) is used for Infobot compatibility;
|
|
if you still want the basic functionality of Infobot, this is the
|
|
plugin to use.
|
|
|
|
|
|
Q: Can I import my Infobot/Blootbot/Moobot factoids into Supybot?
|
|
|
|
A: As of present, we have no automated way to do so. Strike has
|
|
written a few scripts for importing a Moobot database into
|
|
MoobotFactoids, however, so you'll want to talk to him about
|
|
helping you with that. We're certainly happy to help you convert
|
|
such databases; if you can provide us with such a database exported
|
|
to a flat file, we can probably do the rest of the work to write a
|
|
script that imports it into a database for one of our
|
|
factoids-related plugins.
|
|
|
|
|
|
Q: Do I really have to use separate databases for each channel?
|
|
|
|
A: Of course not! We default to separate databases for each channel
|
|
because, well, that's what jemfinch always thought was
|
|
reasonable. Anyway, if you change the configuration variable
|
|
supybot.databases.plugins.channelSpecific to False instead of
|
|
True, for *most* databases, each channel will share the same
|
|
database (the exceptions are ChannelStats, Herald, Seen, and
|
|
WordStats, which are inherently rather channel-based).
|
|
|
|
|
|
Q: Karma doesn't seem to work for me.
|
|
|
|
A: Karma by default doesn't acknowledge karma updates. If you check
|
|
the karma of whatever you increased/decreased, you'll note that
|
|
your increment or decrement still took place. If you'd rather
|
|
Karma acknowledge karma updates, change the
|
|
supybot.plugins.Karma.response configuration variable to On.
|
|
|
|
|
|
Q: I added an alias, but it doesn't work!
|
|
|
|
A: Take a look at "help <alias you added>". If the alias the bot has
|
|
listed doesn't match what you're giving it, chances are you need
|
|
to quote your alias in order for the brackets not to be
|
|
evaluated. For instance, if you're adding an alias to give you a
|
|
link to your homepage, you need to say:
|
|
|
|
alias add mylink "format concat http://my.host.com/ [urlquote $1]"
|
|
|
|
and not:
|
|
|
|
alias add mylink format concat http://my.host.com/ [urlquote $1]
|
|
|
|
The first version works; the second version will always return the
|
|
same url.
|
|
|
|
Q: Is there a command that can tell me what capability another
|
|
command requires?
|
|
|
|
A: No, there isn't, and there probably never will be. Commands have
|
|
the flexibility to check any capabilities they wish to check;
|
|
while this flexibility is useful, it also makes it hard to guess
|
|
what capability a certain command requires. We could make a
|
|
solution that would work in a large majority of cases, but it
|
|
wouldn't (and couldn't!) be absolutely correct in all
|
|
circumstances, and since we're anal and we hate doing things
|
|
halfway, we probably won't ever add this partial solution.
|
|
|
|
Besides, is the error message so bad? If we did have such a
|
|
command, many users would call the command, see that they could
|
|
perform it, and then run the command, thus doubling the activity
|
|
in the channel. Is that something you want?
|
|
|
|
|
|
Q: How do I make my Supybot connect to multiple servers?
|
|
|
|
A: Just use the "connect" command in the Network plugin. Easy as pie!
|
|
|
|
|
|
Q: My bot can't handle nicks with brackets in them! It always
|
|
complains about something not being a valid command, or about
|
|
spurious or missing right brackets, etc.
|
|
|
|
A: You should quote arguments (using double quotes, like this:
|
|
"foo[bar]") that have brackets in them that you don't wish to be
|
|
evaluated as nested commands. Otherwise, you can turn off nested
|
|
commands by setting supybot.commands.nested to False, or change
|
|
the brackets that nest commands, by setting
|
|
supybot.commands.nested.brackets to some other value (like <>,
|
|
which can't occur in IRC nicks).
|
|
|
|
|
|
Q: I've edited my configuration file, but my Supybot doesn't notice
|
|
the changes! Even if I restart it, it doesn't see them. What's
|
|
the deal?
|
|
|
|
A: Supybot won't reload its configuration files unless you tell it
|
|
to. In addition, when Supybot exits (and periodically while it
|
|
runs) it flushes its configuration file to disk. The safest way
|
|
to avoid problems with configuration file edits is simply to exit
|
|
the bot before editing the configuration file(s). If you don't
|
|
wish to do that, however, you can edit the file, save the changes,
|
|
and tell the bot to reload its configuration, either via the
|
|
reload command in the Config plugin, or by sending the bot a
|
|
SIGHUP. There is a brief period in this whole sequence where the
|
|
bot can flush its configuration to disk after you write your
|
|
changes, but we even have something to fix that: set the
|
|
configuration variable supybot.flush to False, and then reload the
|
|
configuration.
|
|
|
|
|
|
Q: I found a bug, what do I do?
|
|
|
|
A: Submit it on Sourceforge through our Sourceforge project page:
|
|
<http://sourceforge.net/tracker/?group_id=58965&atid=489447>. If
|
|
Sourceforge happens to be down when you try to submit your bug,
|
|
then post it in the "Supybot Developer Discussion" forum at our
|
|
forums at <http://forums.supybot.org/>. If that doesn't work,
|
|
email supybot-bugs@lists.sourceforge.net. If that doesn't work,
|
|
email jemfinch@supybot.org. If that doesn't work, find yourself
|
|
some carrier pigeons and ... hah! You thought I was serious!
|
|
|
|
Anyway, when you submit your bug, we'll need several things. If
|
|
the bug involved an uncaught exception, we need the traceback
|
|
(basically the stuff from "Uncaught exception in ..." to the next
|
|
log entry). We'd also like to see the commands that caused the
|
|
bug, or happened around the time you saw the bug. If the bug
|
|
involved a database, we'd love to see the database. Remember, it's
|
|
always worse to send us too little information in a bug report than
|
|
too much.
|
|
|
|
|
|
Q: Is there a way just to load *all* the plugins Supybot has?
|
|
|
|
A: No, there isn't. Even if there were, some plugins conflict with
|
|
other plugins, so it wouldn't make much sense to load them. For
|
|
instance, what would a bot do with Factoids, MoobotFactoids, and
|
|
Infobot all loaded? Probably just annoy people :)
|
|
|
|
If you want to know more about the plugins that are available,
|
|
check out our "Plugin index" at our website.
|
|
|