Ok if I were to build an ops bot, would it be smart to include any kind of interface? Or would it be best to leave it plain and simple. The reason I'm asking is I'm not really sure if the interface can interfere with the bots operation in any way (i.e. speed or stability.) Any input will be appreciated. Programmers with experience in this field is who I am looking to hear from so if you aren't one please don't interfere in the thread.

!~!HaZaRD!~!

My moderation bot has no intereface, it just sits in the tray and logs various things, such as errors and commands. It's worked fine for many months. However, I have seen moderation bots with minute interfaces that seem to do just as well.

It does take precious time to draw/redraw that GUI...

A program often has conflicting objectives. This is why we write requirements before starting design. An ops bot most important job is to moderate the channel. When making design decisions be sure to weigh your choice against that primary job.

You do need an interface, but it doesn't have to be graphical. The interface is defined as that set of functionality for which the bots abilities are manipulated. Thus, a bot like Ops [vL]'s ZeroBot, one interface is the BNCS users talking in the channel, or whispering commands directly.

ZeroBot doesn't talk much, hardly at all. It's not important for keeping the channel moderated. If you're designing an ops bot, I'd suggest doing the same. If you let the bot respond to triggers, it can be flooded. If you have it greet people entering the channel, again it can be flooded. We've found it is best to have the bot simply ignore all unauthorized commands or interaction.

An interface of some kind if nice to have, even on an ops bot - at least during debugging. Being able to have it dump out internal state information to the console as it performs operations is a quick way to see what's going wrong without halting it in a debugger. However, unless you plan on using it to chat (I would recommend against this), make the interface: 1) simple (i.e. console only) and 2) removable. Then dismiss the console whenever you're not watching it for debug output. If you're careful with how you do your output routine, it can do almost no work when the console is not present, thus providing a minimal speed hit. If you really care about speed, compile the console out when you don't need it!

I'd recommend adding the capability to run your program as a Windows NT service; those can be set to auto start when nobody's logged on and continue running in the background despite user logons and logouts - something which is just perfect for an automated channel moderator program.

Would it improve the ability of the bot for moderation purposes to ignore all users not on the access list?

!~!HaZaRD!~!

[quote author=HaZarD link=board=17;threadid=1750;start=0#msg13339 date=1057006993]
Would it improve the ability of the bot for moderation purposes to ignore all users not on the access list?

!~!HaZaRD!~!
[/quote]However, probably the answer is yes. Generating any reaction to non-authorized users (other than banning users marked for autoban) makes the bot more susceptible to abuse. If you really want it to respond to random users, I recommend an internal ruleset that prohibits such responses more often than once every few minutes.

Can we get past the daunting task I know this whole thing is going to take a lot of work. Kp can you elaborate on this topic you were discussing? I see no reason to have my bot relate to users not in the database (those you lable as "random users") I was considering adding in commands that require no access to access but do you think this would be unwise?

[Edit] By the way thanks guys for the lessons of simplicity as it relates to relativity :P

!~HaZaRD!~!

Tnx Grok my first Toast :P But my question still stands. Is it feesible to add commands that require no access to the bot yet still be a stable ops operator? Or might it be wiser to require to have for instance the Safelist flag/access number in order to access those commands?

[Edit] I am of course aiming for a very stable and effective channel moderation bot and this is one of the big problems I've come up with while planning what I want to do.

!~!HaZaRD!~!

Maybe give some examples of what the purpose of the accessless commands is, since I can't think of any reason to have them at all.

You know like finding the botmaster or the trigger. For convinence purposes.

!~!HaZaRD!~!

What happens when Mass(1)Bot through Mass(30)Bot join and your ops bot tries to say hello to all of them, or respond to them doing ".version" or whatever? You get seriously backed up trying to handle a lot of junk traffic from someone who's just trying to screw up your client. An attentive bot operator could clear the outbound queue to stop that, but what if it happens while all the bot's authorized operators are away and/or not paying attention? That can be mostly mitigated if your bot has rules about not responding to unauthorized users more than once every few minutes, but it'd still be irritating to have the bot's queue getting tied up (even briefly) by disruptive people. Depending on how inclined you are to give out minor levels of access, you could to that instead.

As an interesting aside, the bncs naming rules (which gave rise to so-called "illegals") actually help out bots to some degree. For instance, you could set "[vL]*" to some pattern and know that only pre-existing [vL] accounts can match that, since no one can make an account that starts with [ anymore. Of course, such wouldn't catch all [vL] since some prefer to have the tag at the end (or arrived after the rules changed). Similar logic can be applied to any other clan which was around before the change.

Since Zerobot doesn't permit changing the trigger, we've had no need of a "?trigger" type command. Further, we have a specific attribute which grants access to the query commands so you can look up operator/master/whatever. By doing so, we allow members (and theoretically nonmembers, though we almost never do that) to query the database without just making it world-readable.

Thanks Kp excellent point on the massload idea. Also thanks for that reminder on the bncs naming regulations that I have to make sure to take that under consideration.

!~!HaZaRD!~!

IMO the best way to do this is to keep all commands restricted, my bot has ?trigger but it requires access to the trigger command. Also you really need to consider a priority queue, where some messages take precidence over others. on 01 bans/ignores/designates are on the highest priority, then greetings and other junk is on a diffrent priority that is limited in size, so you can only have 3 messages queued up.

Thnx c0ol great suggestion.

!~!HaZaRD!~!

[quote author=Camel link=board=17;threadid=1750;start=0#msg13365 date=1057018536]
[quote author=DarkMinion link=board=17;threadid=1750;start=0#msg13364 date=1057017904]This was being done *long* before VS .NET came out.[/quote]

That by no means whatsoever makes it simple.
[/quote]It couldn't be more simple. MSDN has had a nice drop-in C module for service (service.c, service.h) support for years, and has had a VB OCX for service support since the days of VB5 or so (ntsvc.ocx).

It helps a bit if you spend 5 minutes doing research :-)

[quote author=c0ol link=board=17;threadid=1750;start=15#msg13432 date=1057086974]
IMO the best way to do this is to keep all commands restricted, my bot has ?trigger but it requires access to the trigger command. Also you really need to consider a priority queue, where some messages take precidence over others. on 01 bans/ignores/designates are on the highest priority, then greetings and other junk is on a diffrent priority that is limited in size, so you can only have 3 messages queued up.
[/quote]
Interesting point on the priority queue, I'll have to consider implimenting that. ATM, my external buffer (in a database) does have a column for priority and it is used while reading the buffer, but I hadn't thought of setting the priority the outgoing text based on the access of a user.

I agree with Camel it's a very interesting idea for the sytem. However was your point that the priority queue was based on access level or by the type of command?

!~!HaZaRD!~!

Err, I meant I hadn't thought of doing priority based on the command, just on the user's rank. =P

Trying I was asking an opinion. I was asking what people think is a more interesting idea, priority queue based on the command or based on access.

!~!HaZaRD!~!

Well if you want it to be a stable ops bot just go with ur first idea and make it ignore anyone and everyone that isn't in the database with access or ban. Or what you could do is try it both ways just to see which is more stable. Testing and retesting usually works the best to find the answer!

[quote author=RhiNo link=board=17;threadid=1750;start=15#msg14262 date=1057761738]
Well if you want it to be a stable ops bot just go with ur first idea and make it ignore anyone and everyone that isn't in the database with access or ban. Or what you could do is try it both ways just to see which is more stable. Testing and retesting usually works the best to find the answer!
[/quote]

Take any random ops bot and type: /o igpriv. Instant stability. :)

The opbot I use doesn't allow me to do that. It has no interface. :P

How about a !say command?

[quote author=Camel link=board=17;threadid=1750;start=30#msg14317 date=1057781718]How about a !say command?[/quote]...will not honor say requests for /commands that it does not recognize, as a security measure.

[quote author=Kp link=board=17;threadid=1750;start=30#msg14332 date=1057784691]...will not honor say requests for /commands that it does not recognize, as a security measure.[/quote]
And there's no override!? What an annoying feature.
Anyways, it is an account-wide change; log off your bot and log on to the account with something else and do /o ipgriv. :)

[quote author=Camel link=board=17;threadid=1750;start=30#msg14304 date=1057777816]
Take any random ops bot and type: /o igpriv. Instant stability. :)
[/quote]
If your op bot dies because of people talking, I think it's time to get a new op bot.

Good point, lol.

Lets just assume you actually were to use the /o igpriv feature.

That would actually make it so much easier.

Simply make the commands public (anyone can access the bot)

Then have the bot /o igpriv.

Add anyone to the bots friends list that you want to have access.

In a sense , battle.net is even keeping a bot database for you.

"If your op bot dies because of people talking, I think it's time to get a new op bot. " - Skywing

Skywing: however true , use the example that someone else used a while back. "what if mass(1)bot to mass(30)bot join the channel and repeatedly say .version?" (assuming it is a public command).
It may not drop it , but having the bot lagged is still an annoyance.

So don't make 'version' a public command!

[edit] And another thing, that's why I have queue priority: it parses all command right away, but it picks buffered text to send based first on the rank of the user who issued the command and then on the order. That way users with higher ranks get precedence over joe newbie spamming '!version.' ;)

[quote author=HaZarD link=board=17;threadid=1750;start=0#msg13298 date=1056984404]
Ok if I were to build an ops bot, would it be smart to include any kind of interface? Or would it be best to leave it plain and simple. The reason I'm asking is I'm not really sure if the interface can interfere with the bots operation in any way (i.e. speed or stability.) Any input will be appreciated. Programmers with experience in this field is who I am looking to hear from so if you aren't one please don't interfere in the thread.

!~!HaZaRD!~!
[/quote]

seeing as what i said before and what camel said if u really feel the need make the bot as complex as u want just make it /o igpriv and add ur name and users with access to f l thatway it ignores all but ur shit i guess sorta answeres the question.

RhiNo, I was joking when I said use /o igpriv. I highly doubt any serious programmer would even consider that as a plausable solution.

Well no need to joke =\ ne ways the more simple the faster it will run so make it as simple as u can and it odda be stable and fast :-P

".Version" is an ego trip.

".Version" is an ego trip. " - Grok
How so? Its just to let the users know which version of a particular bot they have. perhaps it is to show that you have version 1.0 but there is 2.0 available (shown if another user is loading 2.0?)

Camel - Why would you not concider it? It is a bit simple , true , but it is efficient and it gets the job done , properly. Also , you spend less time on programming if you do that.

Also , it would be one less section of code that could possibly mess up and drop the bot?

Now: lets all try and THINK before we speak?

[quote author=SoHKz x Ed link=board=17;threadid=1750;start=30#msg14438 date=1057853589]
Skywing: however true , use the example that someone else used a while back. "what if mass(1)bot to mass(30)bot join the channel and repeatedly say .version?" (assuming it is a public command).
It may not drop it , but having the bot lagged is still an annoyance.
[/quote]

uhh lets assume this situation, 30 bots join the channel and send (extreme impossible case) 1msg per second, at full length, 220 characters. so thats 30 * 220 = 6600 bps, so thats ~7k per sec. are u telling me that ur internet connection is going to be lagged by 7k per sec? no it wont. Even if the bot has a greeting, if it was well prioritized it would suffer no lag from 30 mass bots.

Now co0l , read carefully before you reply.

I never said that your internet connection would be lagged.
I said that your BOT would be.

[quote author=SoHKz x Ed link=board=17;threadid=1750;start=30#msg14494 date=1057891864]
".Version" is an ego trip. " - Grok
How so? Its just to let the users know which version of a particular bot they have. perhaps it is to show that you have version 1.0 but there is 2.0 available (shown if another user is loading 2.0?)

Now: lets all try and THINK before we speak?[/quote]

There are plenty of ways you can tell a user the version of bot he's using without him having to log on bnet and type ".version", and announce it to everyone else. Splash screens, Help|About.. dialog, "/version" if you insist on only telling them from command-line, or simply displaying the version on the window caption, status bar, or some static on the dialogs.

.version is more like "see what I have", thus my statement that it is an ego trip.

But I guess you didn't THINK about it like that.

[quote author=SoHKz x Ed link=board=17;threadid=1750;start=45#msg14521 date=1057930939]
Now co0l , read carefully before you reply.

I never said that your internet connection would be lagged.
I said that your BOT would be.
[/quote]
that doesnt even make since, a bot doesnt "lag" lag is high latency, a network issue. it is possible that mabe ur send queue can be loaded, and it could appear to be lag, but as i said if you well prioritize it there should be no problem there. Mabe i dont understand something, so please define this lag that you might suffer.

[quote author=Grok link=board=17;threadid=1750;start=45#msg14524 date=1057935062]
[quote author=SoHKz x Ed link=board=17;threadid=1750;start=30#msg14494 date=1057891864]
".Version" is an ego trip. " - Grok
How so? Its just to let the users know which version of a particular bot they have. perhaps it is to show that you have version 1.0 but there is 2.0 available (shown if another user is loading 2.0?)

Now: lets all try and THINK before we speak?[/quote]
[/quote]Zerobot's .version string includes __DATE__ and __TIME__, so it can be used to find out when exactly the currently active version was built. I find that immensely handy in determining whether a particular change is in the working version. :p

Sohkzxed: I concur entirely with Skywing on the matter of igpriv as a bad method of restricting access. It is not only a shoddy way of protecting a bot from unauthorized access, it's also unworkable in many situations. For instance, what if you decide that more than 25 names ought to legitimately have access to the bot? You're stuck, because you can only put 25 people on the list. If you do the access checks locally, you can have a theoretically unlimited number of authorized names. I say names specifically, because of the case where you have an authorized user with multiple names - which will fill up your friends list even faster. Further, if you rely on the server ignoring chat to protect the bot, you lose the ability to have multiple levels of access. Any given user either is, or is not, able to grant/remove access from other users. There's no middle ground of being able to give "a little access".

Further, the bot cannot be used to chat / monitor channel / automoderate if it is using server-side filtering. Unless your access-checking capability is extremely inefficient, it should be easily possible to allow the bot to receive all chat and process based on a local ACL. Zerobot does this and shows no visible performance problems (either in slowness of response or reported usage of CPU).

Multiauthoring of a single bot instance run on a shared server is unique to [vL] however.

[quote author=Grok link=board=17;threadid=1750;start=45#msg14537 date=1057955296]
Multiauthoring of a single bot instance run on a shared server is unique to [vL] however.
[/quote]
<cough> CVS </cough>