mirror of https://github.com/Mikaela/Limnoria.git
360 lines
16 KiB
Plaintext
360 lines
16 KiB
Plaintext
<!DOCTYPE article SYSTEM "supybot.dtd">
|
|
<article class="faq">
|
|
<articleinfo>
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Jeremiah</firstname>
|
|
<surname>Fincher</surname>
|
|
</author>
|
|
<editor>
|
|
<firstname>Daniel</firstname>
|
|
<surname>DiPaolo</surname>
|
|
<contrib>DocBook translator</contrib>
|
|
</editor>
|
|
</authorgroup>
|
|
<title>Supybot Frequently Asked Questions</title>
|
|
<revhistory>
|
|
<revision>
|
|
<revnumber>0.1</revnumber>
|
|
<date>18 Feb 2004</date>
|
|
<revremark>Initial Docbook translation</revremark>
|
|
</revision>
|
|
<revision>
|
|
<revnumber>0.2</revnumber>
|
|
<date>26 Feb 2004</date>
|
|
<revremark>Changed to Supybot DTD</revremark>
|
|
</revision>
|
|
</revhistory>
|
|
</articleinfo>
|
|
<qandaset defaultlabel="qanda">
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Why does my bot not recognize me or tell me that I don't
|
|
have the <capability>owner</capability> capability?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Because you've not given it anything to recognize you
|
|
from! You'll need to identify with the bot
|
|
(<botcommand>help identify</botcommand> to see how that
|
|
works) or add your hostmask to your user record
|
|
(<botcommand>help addhostmask</botcommand> to see how that
|
|
works) for it to know that you're you. You may wish to
|
|
note that <botcommand>addhostmask</botcommand> can accept
|
|
a password; rather than identify, you can send the command
|
|
<botcommand>addhostmask myOwnerUser [hostmask]
|
|
myOwnerUserPassword</botcommand> and the bot will add your
|
|
current hostmask to your owner user (of course, you should
|
|
change <literal>myOwnerUser</literal> and
|
|
<literal>myOwnerUserPassword</literal> appropriately for
|
|
your bot).
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
How do I make Supybot op my users?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
First, you'll have to make sure that your users register
|
|
with the bot. They can do this with the
|
|
<botcommand>register</botcommand> command. After they do
|
|
so, you'll want to add the
|
|
<capability>#channel,op</capability> capability to their
|
|
user. Use the <botcommand>channel
|
|
addcapability</botcommand> command to do this. After
|
|
that, your users should be able to use the
|
|
<botcommand>op</botcommand> command to get ops.
|
|
</para>
|
|
<para>
|
|
If you want your users to be auto-opped when they join the
|
|
channel, you'll need to load the <plugin>Enforcer</plugin>
|
|
plugin and turn its <registrygroup>autoOp</registrygroup>
|
|
configuration variable on. Use the
|
|
<botcommand>config</botcommand> command to do so. Here's
|
|
an example of how to do these steps:
|
|
</para>
|
|
<ircsession>
|
|
<jemfinch|lambda> I'm going to make an example session for giving
|
|
you auto-ops, for our FAQ.
|
|
<dunk1> ah ok ;]
|
|
<jemfinch|lambda> First, I need you to register with supybot, using
|
|
the "register" command (remember to send it in private).
|
|
<dunk1> done
|
|
<jemfinch|lambda> what name are you registered under?
|
|
<dunk1> dunk1
|
|
<jemfinch|lambda> ok, cool.
|
|
<jemfinch|lambda> @channel addcapability dunk1 op
|
|
<supybot> jemfinch|lambda: The operation succeeded.
|
|
<jemfinch|lambda> now use the "op" command to get ops.
|
|
<dunk1> @op
|
|
— supybot gives channel operator status to dunk1
|
|
<dunk1> works!
|
|
<dunk1> ;]
|
|
<jemfinch|lambda> @load Enforcer
|
|
<supybot> jemfinch|lambda: The operation succeeded.
|
|
<jemfinch|lambda> @config channel supybot.plugins.Enforcer.autoOp On
|
|
<supybot> jemfinch|lambda: The operation succeeded.
|
|
<jemfinch|lambda> 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|lambda> cool, thanks :)
|
|
</ircsession>
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Can users with the <capability>admin</capability>
|
|
capability change configuration variables?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Currently, no. Since this is the first release of Supybot
|
|
that uses the registry, we wanted to stay on the
|
|
conservative side and require the
|
|
<capability>owner</capability> capability for changing all
|
|
non-channel-related configuration variables. Feel free to
|
|
make your case to us as to why a certain configuration
|
|
variable should only require the
|
|
<capability>admin</capability> capability instead of the
|
|
<capability>owner</capability> capability, and if we agree
|
|
with you, we'll change it for the next release.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Can Supybot do factoids?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Supybot most certainly can! In fact, we offer three
|
|
full-fledged factoids-related plugins!
|
|
</para>
|
|
<para>
|
|
<plugin>Factoids</plugin> (written by
|
|
<nick>jemfinch</nick>) 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
|
|
<registrygroup>supybot.databases.plugins.channelSpecific</registrygroup>
|
|
configuration variable.
|
|
</para>
|
|
<para>
|
|
<plugin>MoobotFactoids</plugin> (written by
|
|
<nick>Strike</nick>) 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
|
|
comaptible 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.
|
|
</para>
|
|
<para>
|
|
<plugin>Infobot</plugin> (written by
|
|
<nick>jamessan</nick>) is used for Infobot compatibility;
|
|
if you still want the basic functionality of Infobot, this
|
|
is the plugin to use.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Can I import my Infobot/Blootbot/Moobot factoids into
|
|
Supybot?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
As of present, we have no automated way to do so.
|
|
<nick>Strike</nick> 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.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Do I really have to use separate databases for each
|
|
channel?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Of course not! We default to separate databases for each
|
|
channel because, well, that's what <nick>jemfinch</nick>
|
|
always thought was reasonable. Anyway, if you change the
|
|
configuration variable
|
|
<registrygroup>supybot.databases.plugins.channelSpecific</registrygroup>
|
|
to <literal>False</literal> instead of
|
|
<literal>True</literal>, for <emphasis>most</emphasis>
|
|
databases, each channel will share the same database (the
|
|
exceptions are <plugin>ChannelStats</plugin>,
|
|
<plugin>Herald</plugin>, <plugin>Seen</plugin>, and
|
|
<plugin>WordStats</plugin>, which are inherently rather
|
|
channel-based).
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Karma doesn't seem to work for me.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
<plugin>Karma</plugin> 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
|
|
<plugin>Karma</plugin> acknowledge karma updates, change
|
|
the
|
|
<registrygroup>supybot.plugins.Karma.response</registrygroup>
|
|
configuration variable to <literal>On</literal>.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I added an alias, but it doesn't work!
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Take a look at <botcommand>help <alias you
|
|
added></botcommand>. If the alias the bot has listed
|
|
doesn't match what you're giving it, chances re 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:
|
|
<para>
|
|
<ircsession>
|
|
alias add mylink "format concat http://myhost.com/
|
|
[urlquote $1]"
|
|
</ircsession>
|
|
<para>
|
|
and not:
|
|
</para>
|
|
<ircsession>
|
|
alias add mylink format concat http://myhost.com/
|
|
[urlquote $1]
|
|
</ircsession>
|
|
<para>
|
|
The first version works; the second version will always
|
|
return the same url.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Is there a command that can tell me what capability
|
|
another command requires?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
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.
|
|
</para>
|
|
<para>
|
|
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?
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
How do I make my Supybot connect to multiple servers?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Just use the <botcommand>connect</botcommand> command in
|
|
the <plugin>Owner</plugin> plugin. Easy as pie!
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I found a bug, what do I do?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Submit it on Sourceforge through our Sourceforge project
|
|
page:
|
|
<ulink
|
|
url="http://sourceforge.net/tracker/?group_id=58965&atid=489447">
|
|
http://sourceforge.net/tracker/?group_id=58965&atid=489447
|
|
</ulink>. 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
|
|
<ulink url="http://forums.supybot.org">
|
|
http://forums.supybot.org/
|
|
</ulink>. If that doesn't work, email
|
|
<email>supybot-bugs@lists.sourceforge.net</email>. If
|
|
that doesn't work, email
|
|
<email>jemfinch@supybot.org</email>. If that doesn't
|
|
work, find yourself some carrier pigeons and … hah!
|
|
You thought I was serious!
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
</qandaset>
|
|
</article>
|
|
|
|
|