Chat/Moderation Bot Interface Discussion

[Hazard]

Thnx c0ol great suggestion.

!~!HaZaRD!~!

[Skywing]

This was being done *long* before VS .NET came out.

That by no means whatsoever makes it simple.

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 :-)

[Camel]

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.

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.

[Hazard]

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!~!

[Camel]

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

[Hazard]

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!~!

[RhiNo]

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!

[Camel]

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!

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

[Zakath]

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

[Camel]

How about a !say command?

[Kp]

How about a !say command?

...will not honor say requests for /commands that it does not recognize, as a security measure.

[Camel]

...will not honor say requests for /commands that it does not recognize, as a security measure.

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.

[Skywing]

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

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

[Camel]

Good point, lol.

[SoHKz x Ed]

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.