Skywing..about ZeroBot...

[Yoni]

Currently, there are 99 bots in the database. StealthBot, the most popular of which, has had over 4 million logins.

[Kp]

Also, just +F people so they won't be randombanned (or l33tbanned?)

Yes and no, respectively.  Random ban only works on "random users", the ones that the bot doesn't know at all.  Leetban was modified a few days ago to honor +F, but the running copy of Zerobot at this time is too old for that.  I'll put in controls on leetban to make it toggleable, unless someone objects to that too...?

[Grok]

My request is that the bot honor members requests.  If a member wants to ban a non-member, it should ALWAYS be allowed.  If a member wants to unban anyone, it should ALWAYS be allowed.  The bot should not decide for a member what he means, what he wants, or whether it is a good idea.  How does that sound?

[Kp]

My request is that the bot honor members requests.  If a member wants to ban a non-member, it should ALWAYS be allowed.  If a member wants to unban anyone, it should ALWAYS be allowed.  The bot should not decide for a member what he means, what he wants, or whether it is a good idea.  How does that sound?

It sounds like that functionality has already been there a while.  However, since no one seems to actually use the overrides, I'm thinking about making override the default and having an alternate set that does the checking.  e.g. "unban naem" would work regardless, but the new command would work only if naem would avoid being banned upon reentering the channel.  Acceptable?

[Grok]

I think we're on the same wavelength.  Members know ban/unban, but might not be aware of all the toggles, rules of default, and so forth.  Especially members who visit less frequently.  When they ban a nonmember, the nonmember should be gone.  When they unban some name, in full or with wildcard ( i.e. unban Grok* ), any banned names matching the name or wildcard should be unbanned.

The member should not have to be told to toggle something before his command will work.

Good:
<Member[vL]>:  .unban God
<God was unbanned by [vL]>

Bad:
<Member[vL]>: .unban God
<From: [vL]> God would just be banned again.  If you still want to do this, first toggle (some setting) and attempt the unban again.

[Kp]

I think we're on the same wavelength.  Members know ban/unban, but might not be aware of all the toggles, rules of default, and so forth.  Especially members who visit less frequently.  When they ban a nonmember, the nonmember should be gone.  When they unban some name, in full or with wildcard ( i.e. unban Grok* ), any banned names matching the name or wildcard should be unbanned.

The member should not have to be told to toggle something before his command will work.

Good:
<Member[vL]>:  .unban God
<God was unbanned by [vL]>

Bad:
<Member[vL]>: .unban God
<From: [vL]> God would just be banned again.  If you still want to do this, first toggle (some setting) and attempt the unban again.

Though as a minor point of reference, the present limits on unban wildcarding seem to be related to the unbans being forgotten (and I haven't yet figured why this is happening, but it really shouldn't be).  The new version (which isn't yet installed) has some diagnostic commands to hopefully let me figure why the unbanlist is shortening so quickly.

Also, I've been working on a script to let me harvest changelogs (which I've been keeping as comments in the source files).  Once it's done, I'll try to make a habit of posting the changelog into /zerobotlogs/ (it *is* a log, of a sort! ) so that interested parties can see what's been changed / when new features were added/removed.

[Grok]

If you need to and test a version, I'll be home in a couple hours to assist.

[Kp]

If you need to and test a version, I'll be home in a couple hours to assist.

Testing new versions requires Skywing, since he's presently the only one who can build them.  This arrangement grew up in part because I can only build unoptimized forms of the bot (somehow optimization is not a "standard" compiler feature...), and in part because I can't directly install it even if I could build it.  *shrug*

Regarding the script, it's working and the revision history is extracted -- but I can't write to /zerobotlogs/.  For now, I've left the file in the Zerobot main directory (in which the logs directory resides) as corechangelog.log.  If you don't mind moving it to the logs directory so that other members can see it, I'd appreciate it.  It can be renamed if you want, but I think the .log extension needs to be kept.

[Hostile]

On the bright side, due to asking him not work I found sending flowers worked like a charm.

[Etheran]

bijillion isn't exact enough for you? :p