R77 Community Forum Archive
Battle.net => Bot Development => Fail Bot => Topic started by: Hero on October 30, 2008, 05:09:28 AM
-
[size=]Main Ideas:[/size]
- Control over other bots
- Command queue sharing
- Moderation queue sharing
- Sending messages and commands (Without going through battle.net)
- Connecting to friends
[size=]Control over other bots[/size]
Local:
Let's say you want this bot in the channel to kick a user but you don't want to use the normal command.
Right click the bot in the channel
Since it is one of your bots a menu item "Send Command..." will show up.
When you click it, it opens a input box asking for a command to send
Type "kick bob" and it executes the command
Good idea?
Let's try another one, you want to reconnect your bot but don't want to open it.
Right click the bot in the channel
Since it is one of your bots a menu item "Reconnect..." will show up
When you click it the other bot will reconnect
Non-Local:
See "Connecting to friends"
Visual things to add...
Menu Items:
Send Command...
Reconnect...
Disconnect
[size=]Command queue sharing[/size]
Local
All of your bots, in the same channel (option), will share a queue for scripting and built-in commands.
Non-Local
See "Connecting to friends"
Visual things to add...
Settings:
Bot Networking Category
Share command queue checkbox
Only share for bots in the same channel checkbox
[size=]Moderation queue sharing[/size]
Local
All of your bots that have ops in the same channel will share banning and kicking queues. (Simple eh?) On by default.
Non-Local
See "Connecting to friends"
Visual things to add...
Settings:
Share ban queues
Share kick queues
Share other moderation queues
[size=]
Command and Message sending[/size]
Local
The ability to open a private message box with another one of your bots. Everything you say will be added to that bots queue. You can use commands via "/"
Non-Local
The ability to start chatting with other Fail Bots. Commands will be accepted if allowed (option).
Visual things to add...
Forms:
Private message boxes
Settings:
Allow commands from friends
[size=]Connecting to friends[/size]
By connecting to friends you can have the bots share the above information. A new settings window will be made for each friend link. (The settings are stored in a different file)
You give a friend a key or password and your computer's IP Address, then they connect to you via some sort of command or button.
[size=]Port Listening and outputing[/size]
Local
Able to listen to a list of ports and display data sent to/from them
Visual things to add...
Settings:
Ports to listen to
Forms:
Port Listener
-
Sounds good already... but what about NETWORK wise??
-
I am with my husband on this one. Sounds good, but will it be as good as it sounds?
-
Added the rest of the descriptions. Added some Non-local details. I will add to this list as I think of things.
-
Hmm sounds like fun! Now if only Stealthbot thought of that!
-
And how long did it take you to think of this?? Sounds good and all...
@Kat... I knew you were on just moments before me you sneaky girl!
-
A good 10 minutes or so
-
Well, make sure you run the information through--say 1024 (<--Random sum of doubling 1 until I felt like stopping) bit-- encryption. This way WE KNOW it is secured xD
-
Hmm sounds like fun! Now if only Stealthbot thought of that!
I'm sure they have, just never had the time to implement such a system. It can be done with scripting, anyways.
-
I see no reason why it should be encrypted unless someone is gonna be stupid and do something like
/g say password -OR-
/g say cdkey
-
Connecting to friends
By connecting to friends you can have the bots share the above information. A new settings window will be made for each friend link. (The settings are stored in a different file)
You give a friend a key or password and your computer's IP Address, then they connect to you via some sort of command or button.
When doing that, I don't want my friend seeing my passwords, cdkeys, and such. In fact, I want to be able to custom set the commands he or she can use, even if he or she is a trusted friend. Commands like settrigger, setpass, setname, reconnect, resign, designate and such should be restricted. Only ban, kick, say, safeadd, etc should be used in this connection.
-
No by key/password - he means a password or key to CONNECT to your computer.
And just for the heck of it, sure I will encrypt stuff.
Probably using my own encryption method.
(Such as my encryption program, which ran stuff through 3 DIFFERENT encryption methods
And Hero ~ Getting the bot to detect which bots are Fail Bots or not will be VERY tricky. For example -
User1 joins the channel (Fail Bot)
User2 joins the channel (stealth Bot)
User3 joins the channel (Starcraft)
How would
Bot1 (You [On Fail Bot]) Be able to detect if its a Fail Bot or not?
you see the delima?
The ONLY way would be to
have ALL Fail Bot's connect to a server (Using there name on BNET)
Have 4 different servers (East, West, Asia, And Europe)
And have the bot "Whisper" and see if the other bot is a Fail Bot or not!
-
Just have all the usernames, products, and realms on the local server.
Example:
For Each botInfo In LocalServer.Bots
userToFind = botInfo.Username
If ( myProduct = "WAR3" OR myProduct = "W3XP" ) AND ( botInfo.Product = "STAR" OR botInfo.Product = "D2DV" ) Then
userToFind = userToFind & "@" & botInfo.SimpleRealm
End If
For Each User In Channel.Users
If LCase(User.Name) = userToFind Then
'// Yay we found a fail bot
End If
Next
Next
-
where can u dl fail bot??
-
Here (http://zone57.co.nr/FailBot/FailBot.zip) is this most recent version I believe.
-
I like this idea very much.
-
Added Port listening and outputting - Read up ;\
-
The port listener would only work for Fail Bot, and i see no purpose for this as all the ports Fail Bot uses are outputted SOMEWHERE (1337 = local server, 1338 = Clan meeter, 6112 = BNET, 9367 = BNLS)
-
[size=]Main Ideas:[/size]
- Control over other bots
- Command queue sharing
- Moderation queue sharing
- Sending messages and commands (Without going through battle.net)
- Connecting to friends
I am not certain of the exact ability of Forsaken Ops, but I'm sure that if FailBot had all these features, then it would be a much better bot than most other bots. (Even those that use BotNet)
[size=]Moderation queue sharing[/size]
Local
All of your bots that have ops in the same channel will share banning and kicking queues. (Simple eh?) On by default.
This is VERY ESSENTIALLY to a bot to have. That way, you don't clog your bot with unnecessary bans and whatnot. Excessive message are problematic to every bot unless they adopt a feature like this. FoolOps has this capability as well.
Command and Message sending[/size]
Local
The ability to open a private message box with another one of your bots. Everything you say will be added to that bots queue. You can use commands via "/"
I only see this as a solution to laziness, UNLESS you and the other bot are not on the same computer.
[size=]Port Listening and outputing[/size]
Local
Able to listen to a list of ports and display data sent to/from them
Visual things to add...
Settings:
Ports to listen to
Forms:
Port Listener
I think this is pointless. This wouldn't even be FailBot-related, but instead a packet logger.
If I can add a suggestion. Eric was taling to me sometime ago of a feature he wanted to put into StealthBot. This feature is called SmartQueue. If you send the bot a command, and another user sends the bot a command as well, before the bot is finished sending the responses to the first user, it will also take the messages sent to its queue by the second user, and show him his responses as well.
<user1>.whois *
<user2>.say hai; this is a test
<bot>Found three users in the database: (to the first user)
<bot>hai (to the second user)
<bot>bob 50/S; harry 40/H; test 80/G. (to the first user)
<bot>this is a test (to the second user)
I am very fluid with the concept of this idea, but I would really have to think of how to implement this feature.
-
Finally, someone who dumbed it down for the nubs! Now if only I actually understood what Vector meant.... actually I did, and I think I agree with all but his last point. The person who did a command first should be the one who gets the responses first, Plain and simple.
-
Hmmm..... Lets see how i could implement that....
Public Function Add2Queue(SplitChar, Message)
Dim CommandResponse() As String
CommandResponse() = Split(Message, SplitChar)
If UBound CommandResponse() <= 2 Then
For CommandCount = 1 to lstQueue.listitems.count
If CommandResponse(lstQueue.items(i)) = True then
'go from there. Idk, anyone have suggestions?