Come on Mods. Please leave this alone.
What Bot Ideas do you all have. Please list them in this thread. If you don't want an idea taken, Don't post it!

It's not like i'm stealing code in this thread. I have Voice Regegnition on the list and there was another one I forgot (Since post was deleted)

the point of this board is to develop ideas/code, not brainstorm

I am developing ideas

no, you're asking for people to give you ideas. that's different than presenting an idea and asking for criticism or help improving that idea.

Come on. Give me a <Break>

[quote author=Hashed link=board=17;threadid=1147;start=0#msg8432 date=1051218741]
Come on. Give me a <Break>
[/quote]Very well. What part would you like broken?

start with his left testicle. that seems to be the most popular place to start.

SKINNED
IN
LESBIAN
PORN
.

[quote author=St0rm.iD link=board=17;threadid=1147;start=0#msg8454 date=1051232438]
SKINNED
IN
LESBIAN
PORN
.
[/quote]
...lol

How about remaking the interbot protocal, any bot developers interested in recreating the old IBP? I think UB still uses it...I always thought it was pretty kickass...I'm gonna go now cause I just found some weed, PeAcE

[quote author=PiaNKA link=board=17;threadid=1147;start=0#msg8474 date=1051282522]
How about remaking the interbot protocal, any bot developers interested in recreating the old IBP? I think UB still uses it...I always thought it was pretty kickass...I'm gonna go now cause I just found some weed, PeAcE
[/quote]That's the primary function of the BotNet. In particular, IB was unreliable/unsuccessful because it's got severe data transmit restrictions and communication between bots tends to break down easily (it's a bad idea to do such things via Battle.net).

botnet is obviously a great idea, and probably great in reality, but the documentation is minimal and poor, making it hard to impliment -_-

How is the documentation "minimal and poor"? Skywing has a full text about the protocol which, might I add, basically follows the same schema of Battle.net. Perhaps someone should make a CSB variant for the botnet?

[quote author=kamakazie link=board=17;threadid=1147;start=0#msg8499 date=1051334818]How is the documentation "minimal and poor"? Skywing has a full text about the protocol which, might I add, basically follows the same schema of Battle.net.[/quote]That, and Kp's "updated" protocol for the BotNet server that he's working on. Both of them are fugly... But as Kp told me, you're free to make and distribute your own protocol spec if you don't like those. *hint hint* [quote author=kamakazie link=board=17;threadid=1147;start=0#msg8499 date=1051334818]Perhaps someone should make a CSB variant for the botnet?[/quote]FUCK NO! CupHead already gave babies rifles to play with, you do that and they'll have oozies too!

no, he gave them oozies... i'd think a full fledged bot is more valuable then botnet

[quote author=Noodlez link=board=17;threadid=1147;start=0#msg8504 date=1051336958]i'd think a full fledged bot is more valuable then botnet[/quote]Agreed.

Anyone interested in created a REAL p2p botnet using UDP?

[quote author=St0rm.iD link=board=17;threadid=1147;start=15#msg8515 date=1051368795]
Anyone interested in created a REAL p2p botnet using UDP?
[/quote]

yes. preferably on a reliable connection.

[quote author=St0rm.iD link=board=17;threadid=1147;start=15#msg8515 date=1051368795]Anyone interested in created a REAL p2p botnet using UDP?[/quote]You don't like BotNet? Actually, there's several key points that I don't like about what Kp claims to be "improving" the BotNet server and documentation. But all in all, the Valhalla Legends botnet is very nice (albeit rather sucky docs) for what it was designed for: the communication and coordination between bots, especially during (the now rare) Battle.net server splits. Oh, and by the way, UDP is eww++.

I beleive there's already an IRC standard for a bot network, but I'm not sure... I'd have to check into that.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8541 date=1051398055]
Actually, there's several key points that I don't like about what Kp claims to be "improving" the BotNet server and documentation.[/quote]
All I've heard is complaint that the server won't let you use as long a battle.net name as you like; the documents never specified that you could use arbitrary length strings. If you'd like to enumerate the failings...?

...Well what I meant is not using the already implemented IB, but a completely new one...? Like we all sit down for a week and setup a whole new protocal, add it to our bots and hopefully create something that will be used for a few years. But I doubt anyone would be interested, although if you are, e-mail me. I think me e-mail link is on the left, but if it's not, pianka_404@hotmail.com is my e-mail. Or you could just reply to this thread, either way, it works. The new protocal, if we made one, would be a very interesting project, I'm kind of excited if you guys think it's a good idea, but if not, it's all good. :)

By the way, I've put up the BotNet spec on my server at, since vl.com is unreachable:
http://kbg3.ath.cx/misc/BotNetProtocol.txt
I don't have your revision 0x04 docs backed up and as such, can't put them up on my server.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8543 date=1051399742]All I've heard is complaint that the server won't let you use as long a battle.net name as you like; the documents never specified that you could use arbitrary length strings.[/quote]Nor did they say the maximum length of the string (except that common sense states that the string length cannot exceed the maximum length of the packet, minus the length of the other datas of the packet).
[quote author=Kp link=board=17;threadid=1147;start=15#msg8543 date=1051399742]If you'd like to enumerate the failings...?[/quote]1) C->S 0x0B: Protocol spec does not state you can not use action values other than 0 or 1 (emote vs non-emote). Though it works on old clients, you've now broken that for the new-server-aware clients. Additionally, it's a rather waste to have 3 possible values for the command, and 2 possible values for the action, and both parameters using DWORDs to communicate those values. Just combining both parameters into a single byte would be sufficient.

2) C->S 0x02: Does not provide a field for the gateway name, so if you were to add the gateway name by appending "@Gateway" to the unique battle.net name field, it gets cut off. Additionally, the unique Battle.net name field isn't unique if multiple bots are on the same account on different gateways (Eg, MacBinaryBot@USWest, MacBinaryBot@USEast, MacBinaryBot@Azeroth, etc).

3) No documented standard for how to display the bot as "offline", yet you get mad when I do it differently than the way other bots commonly do it.

4) C->S 0x02: The bot's cycle status has very little documentation. You tell me it's defunct (I've forgotten the term you used, but it's essentially old and useless), yet it still exists in the 0x04 revision.

5) You provide a user database, but no standard for which to store the user entries (eg, what values do what). This is more of a general complaint than a botnet server specific complaint, but if the server's supposed to support multiple bot types, then there should be a standard for the database entries.

6) The protocol supports server version and protocol version information. What's the difference between the two? If it's the protocol that's getting added to, why is it the server version gets changed?! ???

7) The 0x04 protocol supports protocol violation messages, but only to a limited degree: Packet data, and parsed length (and a useless packet data length; useless in that isn't it obvious that the packet data is the length of the protocol violation packet minus the length of the other parameter?). You say that it takes common knowledge to know that the error is at whereever the server stopped parsing the packet data. Yes, that's simple enough to understand. But what if the data looks good to the user? Perhaps you should also include an error message (beit a string or an enumerated integer, or both), stating the type of error which occured, such as these basic errors:
[code]Parameter expected (aka packet too short)
Invalid parameter value (eg, privmsg action not being 0 or 1)
String parameter too long
String parameter malformed (such as a space in the account name, or no password provided when changing databases)
Access violation (client tried to do something restricted to verified administrators (logged in and account has access))
Bad connection sequence (eg, client requested bot list before providing its own bot stats, or before sending packet 0x01)
Server Error (internal server error required client to disconnect)
Other (eg, "See Attached String")[/code]
I'm sure there's more for me to complain about, but that's all I can think of right now... most of it is poor documentation.

Edit: Hehe, took me a long time to write this post; I started writing it before pianka replied :P

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8549 date=1051404713]1) C->S 0x0B: Protocol spec does not state you can not use action values other than 0 or 1 (emote vs non-emote). Though it works on old clients, you've now broken that for the new-server-aware clients. Additionally, it's a rather waste to have 3 possible values for the command, and 2 possible values for the action, and both parameters using DWORDs to communicate those values. Just combining both parameters into a single byte would be sufficient.[/quote]
The protocol also doesn't state that you *are* permitted to use values other than 0 and 1. Relying on things that happen to work at the moment is generally a bad practice, IMO. I agree about the waste, but this can't be fixed without either introducing a new message or making message parsing even more complex for both sides.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8549 date=1051404713]2) C->S 0x02: Does not provide a field for the gateway name, so if you were to add the gateway name by appending "@Gateway" to the unique battle.net name field, it gets cut off. Additionally, the unique Battle.net name field isn't unique if multiple bots are on the same account on different gateways (Eg, MacBinaryBot@USWest, MacBinaryBot@USEast, MacBinaryBot@Azeroth, etc).[/quote]Botnet predates the Warcraft III name mangling, which I still maintain to be a bad idea. Truncation of overlong strings is rather generous. The server really ought to have disconnected clients which supplied excessive input. This has been corrected. Differentiating gateways (west v. east) is a property of the server IP field, not the name field.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8549 date=1051404713]3) No documented standard for how to display the bot as "offline", yet you get mad when I do it differently than the way other bots commonly do it.[/quote]Using "Not logged on" in angle brackets has become a de facto standard, as can be seen by observing existing clients in use. If you choose to deviate, that's unfortunate, as other bots will not necessarily recognize you properly.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8549 date=1051404713]4) C->S 0x02: The bot's cycle status has very little documentation. You tell me it's defunct (I've forgotten the term you used, but it's essentially old and useless), yet it still exists in the 0x04 revision.[/quote]Skywing asked that the server retain support for it. It is not being updated, but will remain supported in case someone can find a use for it. Its original purpose was regenerating operator status in private channels by cycling out all bots, if only bots under control of a single entity remained in the channel.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8549 date=1051404713]5) You provide a user database, but no standard for which to store the user entries (eg, what values do what). This is more of a general complaint than a botnet server specific complaint, but if the server's supposed to support multiple bot types, then there should be a standard for the database entries.[/quote]The database takes a name field and a value field, where the value contains any of the letters A-Z. The client is free to interpret the data however it pleases. Aside from Zerobot, I've not been made aware of any bots seeking to store a database on the server. If there are any, and they require other database support, I encourage the authors to contact me at my vL e-mail address to discuss possible support.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8549 date=1051404713]6) The protocol supports server version and protocol version information. What's the difference between the two? If it's the protocol that's getting added to, why is it the server version gets changed?! ???[/quote]The server version is a concept Skywing introduced, to let clients know what features are present. Protocol version is something I introduced, with the intent of being able to determine what particular fields a message would have. Server version will likely increase whenever a new feature is added; protocol revision probably will not change much.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8549 date=1051404713]7) The 0x04 protocol supports protocol violation messages, but only to a limited degree: Packet data, and parsed length (and a useless packet data length; useless in that isn't it obvious that the packet data is the length of the protocol violation packet minus the length of the other parameter?). You say that it takes common knowledge to know that the error is at whereever the server stopped parsing the packet data. Yes, that's simple enough to understand. But what if the data looks good to the user? Perhaps you should also include an error message (beit a string or an enumerated integer, or both), stating the type of error which occured, such as these basic errors:
[code]Parameter expected (aka packet too short)
Invalid parameter value (eg, privmsg action not being 0 or 1)
String parameter too long
String parameter malformed (such as a space in the account name, or no password provided when changing databases)
Access violation (client tried to do something restricted to verified administrators (logged in and account has access))
Bad connection sequence (eg, client requested bot list before providing its own bot stats, or before sending packet 0x01)
Server Error (internal server error required client to disconnect)
Other (eg, "See Attached String")[/code]
I'm sure there's more for me to complain about, but that's all I can think of right now... most of it is poor documentation.[/quote]The present implementation of the parser simply returns true if the packet was acceptable, or false if the parser bailed out due to an error. No facility is provided for it to indicate to the caller about the nature of the error. I'll look at adding an enumerated type to be returned, but don't count on it.

I think the botnet sucks because it's centralized and not open.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8557 date=1051414042]The protocol also doesn't state that you *are* permitted to use values other than 0 and 1. Relying on things that happen to work at the moment is generally a bad practice, IMO. I agree about the waste, but this can't be fixed without either introducing a new message or making message parsing even more complex for both sides.[/quote]It would have been better for the protocol spec to specify what happens to a request with bad values.

It might make message parsing more complex for you, but it's a simple change of 3 lines for me...[code]Old code:
Command = StringToInteger(MidB(Buffer,1,4))
Action = StringToInteger(MidB(Buffer,5,4))
Buffer = MidB(Buffer,9)
Possible new code:
Command = StringToInteger(MidB(Buffer,1,1))
Action = StringToInteger(MidB(Buffer,2,1))
Buffer = MidB(Buffer,3)
Other possible new code:
Temp = AscB(MidB(Buffer,1,1))
Command = BitshiftRight(BitwiseAnd(Temp,&hF0),4)
Action = BitwiseAnd(Temp,&h0F)
Buffer = MidB(Buffer,2)[/code]I don't understand how it would be so hard to write similarly (in VB or RB), I would probably need to at least understand a whole lot more about how you've implemented some of the things.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8557 date=1051414042]Botnet predates the Warcraft III name mangling, which I still maintain to be a bad idea. Truncation of overlong strings is rather generous. The server really ought to have disconnected clients which supplied excessive input. This has been corrected. Differentiating gateways (west v. east) is a property of the server IP field, not the name field.[/quote]I agree the name mangling is a bad idea. Yes, truncation of overlong strings is rather generous, considering that the protocol doesn't specify the maxmimum length of the string in the first place...
Oh, and by the way, the server IP field shouldn't be relied of for the gateway... suppose the bot is on a 3rd party gateway (such as BnetD or WarrNet, as some examples (not saying I support either of those))? As such, it wouldn't be in the server list of other bots, and so the gateway "lookup" could fail. And even if you put that aside, not all clients have all of the server IPs for each gateway and nor do all clients have domain lookup features (eg, if its told to connect to a domain instead of an IP, the provider does the lookup instead of the client).

[quote author=Kp link=board=17;threadid=1147;start=15#msg8557 date=1051414042]Using "Not logged on" in angle brackets has become a de facto standard, as can be seen by observing existing clients in use. If you choose to deviate, that's unfortunate, as other bots will not necessarily recognize you properly.[/quote]As you've stated elsewhere, if you were to join that exact channel, bots could then mark you as offline, even if you weren't.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8557 date=1051414042]Skywing asked that the server retain support for it. It is not being updated, but will remain supported in case someone can find a use for it. Its original purpose was regenerating operator status in private channels by cycling out all bots, if only bots under control of a single entity remained in the channel.[/quote] ::) I don't see it as being very useful, in that the cycle status of client A does not get received by client B, and vice versa. Instead, all I see is the ability to send a request to cycle a channel, the ability to receive a request, and the ability to send the bot's cycle status. Since there's no acknowledgement received by the requester (AFAIK), nor by other bots (AFAIK), it seems fairly useless.

But, if this was received by other clients, then parameter would be where I would put a "Connection Status" parameter, after making it only a byte instead of 4, and would then remove the packet 0x05 (both C->S and S->C). Then, it could be reused in a later protocol version for some other feature (being that old ("legacy") clients won't support the new feature and new clients wont support the old feature...). Here's some example connection status values:[code]0x00: Not connected; Server is invalid (useful for services, such as BNLS or Webbot, perhaps with this value, the client would not be required to send the server parameter (though, it would require the server parameter to be moved to after this parameter))
0x01: Connecting
0x02: Connected; available
0x03: Reconnecting (I beleive WarCraft 3 supports some sort of reconnect feature, does it not? As such, is it not possible for a bot to reconnect?)

Additional (unneeded) values:
0x04: Disconnected; Server is old server

0x05: Proxy down (the bot could not connect to a proxy, which it uses to connect to Battle.net; suppose this could be either of the disconnected values though)

0x06: Bad Version (perhaps the bot does not support auto-updating its hash files, and the Battle.net server doesn't like the version (eg, version too old, unrecognized version); could be useful to see when a new product version has been released, and hashfiles need to be manually updated for services)

0x07: Bad Key (perhaps Battle.net has rejected a CD key and the bot does not have (or support?) autmoatically changing keys, or it out of new keys)

0x08: Server Down/Unreachable (perhaps the bot does not support automatically changing servers or all of the servers which is has are down or unreachable?)

etc etc, I could go one with other useless values...[/code]

[quote author=Kp link=board=17;threadid=1147;start=15#msg8557 date=1051414042]The database takes a name field and a value field, where the value contains any of the letters A-Z. The client is free to interpret the data however it pleases. Aside from Zerobot, I've not been made aware of any bots seeking to store a database on the server. If there are any, and they require other database support, I encourage the authors to contact me at my vL e-mail address to discuss possible support.[/quote]I wish to have support for storing a database on the server, probably in a different way than that of ZeroBot. I will contact you at your email address, then, since that's where you've requested this particular discussion to take place.

Though, I was under the impression that there were other bots that had supported such a feature.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8557 date=1051414042]The server version is a concept Skywing introduced, to let clients know what features are present. Protocol version is something I introduced, with the intent of being able to determine what particular fields a message would have. Server version will likely increase whenever a new feature is added; protocol revision probably will not change much.[/quote]IMO, the server version should change when it's being modified to support a new protocol version, changed when bugs are fixed, and etc. Additionally, IMO, it's the protocol version that should have changed when new features are added to it (such as the account management features in "server version" 0x02, and the "client supports X server version" and "client and server will communicate in 'server version' X" in "server version" 0x04).

I'm not saying that either of your intentions are invalid... it's just that they seem to be ambigous, with only one of them being updated.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8557 date=1051414042]The present implementation of the parser simply returns true if the packet was acceptable, or false if the parser bailed out due to an error. No facility is provided for it to indicate to the caller about the nature of the error. I'll look at adding an enumerated type to be returned, but don't count on it.[/quote]Now that you mention it, I remember you telling me as such. Yet, I still beleive there should be an error code, instead of just "an error occured". Perhaps you could create a variable (since I don't know how the BotNet server is structured, I'll just say in or with the packet's context, or perhaps in the data received function and pass a pointer to it in the packet's parser), which gets set to 0 at the default return, or to an error code at any other return. Then, if the parser returns true, you pass that variable along to the protocol violation handler, else, you ignore the value. If you *do* do it that way, then be sure to set init the value to either 0 or "internal server error", so that if you forget to set it in the parser, you won't send along an invalid error code value.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8567 date=1051418192]
It would have been better for the protocol spec to specify what happens to a request with bad values.[/quote]Probably so. However, using nonstandard values already causes you problems in communication. Some clients (in particular mine) refuse to accept messages not in strict compliance with the specification.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8567 date=1051418192]It might make message parsing more complex for you, but it's a simple change of 3 lines for me...[code]Old code:
Command = StringToInteger(MidB(Buffer,1,4))
Action = StringToInteger(MidB(Buffer,5,4))
Buffer = MidB(Buffer,9)
Possible new code:
Command = StringToInteger(MidB(Buffer,1,1))
Action = StringToInteger(MidB(Buffer,2,1))
Buffer = MidB(Buffer,3)
Other possible new code:
Temp = AscB(MidB(Buffer,1,1))
Command = BitshiftRight(BitwiseAnd(Temp,&hF0),4)
Action = BitwiseAnd(Temp,&h0F)
Buffer = MidB(Buffer,2)[/code]I don't understand how it would be so hard to write similarly (in VB or RB), I would probably need to at least understand a whole lot more about how you've implemented some of the things.[/quote]The parsing change is simple -- if you don't mind losing backward compatibility. The server is supposed to retain compatibility with clients using the current botnet, which will become "legacy" clients when we switch over. For a client to remain compatible with a legacy server, it will need to consider the protocol revision each time it tries to parse a message. Not hard, but it is more trouble.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8567 date=1051418192]I agree the name mangling is a bad idea. Yes, truncation of overlong strings is rather generous, considering that the protocol doesn't specify the maxmimum length of the string in the first place...
Oh, and by the way, the server IP field shouldn't be relied of for the gateway... suppose the bot is on a 3rd party gateway (such as BnetD or WarrNet, as some examples (not saying I support either of those))? As such, it wouldn't be in the server list of other bots, and so the gateway "lookup" could fail. And even if you put that aside, not all clients have all of the server IPs for each gateway and nor do all clients have domain lookup features (eg, if its told to connect to a domain instead of an IP, the provider does the lookup instead of the client).[/quote]Identifying someone's gateway is primarily desirable for determining whether they will be able to affect your bncs environment. If they aren't on the same gate as you, they can't -- doesn't matter which gate they are on. I've never seen a client that couldn't figure out what IP it was connected to, so anyone supplying a bogus IP must be either a bad programmer, intentionally deceptive, or using a really sucky language. :)

If you have some other use for gateway name, please say so. :)

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8567 date=1051418192]As you've stated elsewhere, if you were to join that exact channel, bots could then mark you as offline, even if you weren't.[/quote]Unfortunate, but unavoidable. Suggest an alternate value for that field that can't be accidentally spoofed by a user roving unusual channels?

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8567 date=1051418192]::) I don't see it as being very useful, in that the cycle status of client A does not get received by client B, and vice versa. Instead, all I see is the ability to send a request to cycle a channel, the ability to receive a request, and the ability to send the bot's cycle status. Since there's no acknowledgement received by the requester (AFAIK), nor by other bots (AFAIK), it seems fairly useless.[/quote]Zerobot has a fair amount of clientside support involved in this. If I read the code right, the logic is essentially that if the channel is comprised only of friendly bots, Zerobot asks everyone else to bail out. When the channel is comprised of only itself, it rejoins to reacquire the gavel.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8567 date=1051418192]But, if this was received by other clients, then parameter would be where I would put a "Connection Status" parameter, after making it only a byte instead of 4, and would then remove the packet 0x05 (both C->S and S->C). Then, it could be reused in a later protocol version for some other feature (being that old ("legacy") clients won't support the new feature and new clients wont support the old feature...). Here's some example connection status values:[code]0x00: Not connected; Server is invalid (useful for services, such as BNLS or Webbot, perhaps with this value, the client would not be required to send the server parameter (though, it would require the server parameter to be moved to after this parameter))
0x01: Connecting
0x02: Connected; available
0x03: Reconnecting (I beleive WarCraft 3 supports some sort of reconnect feature, does it not? As such, is it not possible for a bot to reconnect?)

Additional (unneeded) values:
0x04: Disconnected; Server is old server

0x05: Proxy down (the bot could not connect to a proxy, which it uses to connect to Battle.net; suppose this could be either of the disconnected values though)

0x06: Bad Version (perhaps the bot does not support auto-updating its hash files, and the Battle.net server doesn't like the version (eg, version too old, unrecognized version); could be useful to see when a new product version has been released, and hashfiles need to be manually updated for services)

0x07: Bad Key (perhaps Battle.net has rejected a CD key and the bot does not have (or support?) autmoatically changing keys, or it out of new keys)

0x08: Server Down/Unreachable (perhaps the bot does not support automatically changing servers or all of the servers which is has are down or unreachable?)

etc etc, I could go one with other useless values...[/code][/quote]Not sure what this is in response to, but it is a possibility if additional fields are added to bot status.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8567 date=1051418192]I wish to have support for storing a database on the server, probably in a different way than that of ZeroBot. I will contact you at your email address, then, since that's where you've requested this particular discussion to take place.

Though, I was under the impression that there were other bots that had supported such a feature.[/quote]E-mail is preferred since there will likely be quite a bit of exchange working out the details. The internal database format is currently heavily geared toward Zerobot's flags based system, which is generally agreed to be a good design. Other clients do use the database system, but they're all flags-based as far as I know. (Though they assign different internal meaning to a given flag, which is fine since botnet doesn't care about the flags other than that they be alphabetic. That requirement is mostly for convenience, since the flags can be internally represented by a 26-bit wide flags variable.)

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8567 date=1051418192]IMO, the server version should change when it's being modified to support a new protocol version, changed when bugs are fixed, and etc. Additionally, IMO, it's the protocol version that should have changed when new features are added to it (such as the account management features in "server version" 0x02, and the "client supports X server version" and "client and server will communicate in 'server version' X" in "server version" 0x04).

I'm not saying that either of your intentions are invalid... it's just that they seem to be ambigous, with only one of them being updated.[/quote]I introduced protocol revision with server version 4; perhaps unfortunately, I didn't mention it to Skywing until a fair amount of code had already been written for it. If you look over the pr1 spec when it comes back up, you'll see that switching from revision 0 (the default for legacy clients) to revision 1 causes the internal format of several messages to change, thus why negotiation must occur. Additionally, the server only offers up certain types of new information to clients that indicate they expect it. This is in part to deal with certain clients which have demonstrated a tendency to self-destruct when passed more data than they expect. Skywing's concept of server revision is quite useful; however, as implemented, it didn't (IMO) lend itself to negotiation, which I wanted to support. Thus, I created protocol revision.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8567 date=1051418192]Now that you mention it, I remember you telling me as such. Yet, I still beleive there should be an error code, instead of just "an error occured". Perhaps you could create a variable (since I don't know how the BotNet server is structured, I'll just say in or with the packet's context, or perhaps in the data received function and pass a pointer to it in the packet's parser), which gets set to 0 at the default return, or to an error code at any other return. Then, if the parser returns true, you pass that variable along to the protocol violation handler, else, you ignore the value. If you *do* do it that way, then be sure to set init the value to either 0 or "internal server error", so that if you forget to set it in the parser, you won't send along an invalid error code value.[/quote]Actually, if I add error code reporting, it'll probably be in the form of having the parser return 0 for no error, or nonzero on error. If nonzero is returned, then the returned value is passed to the client.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8570 date=1051419736]Probably so. However, using nonstandard values already causes you problems in communication. Some clients (in particular mine) refuse to accept messages not in strict compliance with the specification.[/quote]Programmers wouldn't be so "willing" to break the protocol spec if it was more specific on the specifics.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8570 date=1051419736]The parsing change is simple -- if you don't mind losing backward compatibility. The server is supposed to retain compatibility with clients using the current botnet, which will become "legacy" clients when we switch over. For a client to remain compatible with a legacy server, it will need to consider the protocol revision each time it tries to parse a message. Not hard, but it is more trouble.[/quote]IMO, it's really not too hard to do backwards compatibility... Again, I would need to know more about the server in order to understand.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8570 date=1051419736]Identifying someone's gateway is primarily desirable for determining whether they will be able to affect your bncs environment. If they aren't on the same gate as you, they can't -- doesn't matter which gate they are on. I've never seen a client that couldn't figure out what IP it was connected to, so anyone supplying a bogus IP must be either a bad programmer, intentionally deceptive, or using a really sucky language.[/quote]Yes, sucky language indeed, which refuses to link to OTLib (Open Transport is required for domain lookups), and linking to any "standard library" would require that the library be either in the user's extensions folder or the same folder as the application, which just causes confusion.

Additionally, doing a domain lookup shouldn't be relied upon to do find out the NAME of the gateway. Suppose the lookup fails? Suppose it comes out to something like bne-watcher-01.battle.net? Sure it'll tell the user what gateway they're on, but can a bot automatically know that bne- is USEast? Maybe through some file, perhaps, but that's eww++. The best way is for the other bot to know what gateway it's on (whether told by the user or by doing a /whoami after SID_LEAVECHAT) and report that to BotNet.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8570 date=1051419736]If you have some other use for gateway name, please say so.[/quote]Sure! Use the gateway names to identify who's using what command (and who has access to what command). As such, any commands received from botnet will be "Account@BotNet". Additionally, you could then "link" (associate) BotNet accounts to Battle.net accounts, and then display the "main" account@gateway, and do command processing that way. Not necessarily an easy task, but quite a luxury if done right (it's very possible to do).

[quote author=Kp link=board=17;threadid=1147;start=15#msg8570 date=1051419736]Unfortunate, but unavoidable. Suggest an alternate value for that field that can't be accidentally spoofed by a user roving unusual channels?[/quote]Empty... blank... nil... null... none..., and use a different parameter to specify "Not logged on".

[quote author=Kp link=board=17;threadid=1147;start=15#msg8570 date=1051419736]Zerobot has a fair amount of clientside support involved in this. If I read the code right, the logic is essentially that if the channel is comprised only of friendly bots, Zerobot asks everyone else to bail out. When the channel is comprised of only itself, it rejoins to reacquire the gavel.[/quote]That could be done via a bot command over botnet (aka interbot).

[quote author=Kp link=board=17;threadid=1147;start=15#msg8570 date=1051419736]Not sure what this is in response to, but it is a possibility if additional fields are added to bot status.[/quote]A possible use of the cycle status, in relation to replacing the "Not logged on" in angle brackets for the channel text.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8570 date=1051419736]E-mail is preferred since there will likely be quite a bit of exchange working out the details. The internal database format is currently heavily geared toward Zerobot's flags based system, which is generally agreed to be a good design. Other clients do use the database system, but they're all flags-based as far as I know.[/quote]That's fine.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8570 date=1051419736](Though they assign different internal meaning to a given flag, which is fine since botnet doesn't care about the flags other than that they be alphabetic. That requirement is mostly for convenience, since the flags can be internally represented by a 26-bit wide flags variable.)[/quote]That might be fine for the BotNet server, but it's not fine for bot interoperability (as you've subtly pointed out). A standard should be set up for user flags.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8570 date=1051419736]I introduced protocol revision with server version 4; perhaps unfortunately, I didn't mention it to Skywing until a fair amount of code had already been written for it. If you look over the pr1 spec when it comes back up, you'll see that switching from revision 0 (the default for legacy clients) to revision 1 causes the internal format of several messages to change, thus why negotiation must occur. Additionally, the server only offers up certain types of new information to clients that indicate they expect it. This is in part to deal with certain clients which have demonstrated a tendency to self-destruct when passed more data than they expect. Skywing's concept of server revision is quite useful; however, as implemented, it didn't (IMO) lend itself to negotiation, which I wanted to support. Thus, I created protocol revision.[/quote]Oh yeah, and there's THAT protocol revision as well. So, we now have *3* protocol revisions to worry about.

The one on the packet level (Protocol 'Version'; this is the one I was referring to, currently doing absolutely nothing except disconnecting the client if not 1).
The one specifying the server version (Server Version; this is the other one I was referring to, currently adds/removes certain packet support).
And, the one which is used to specify the expected format of packets (Protocol 'Revision'; which is the one you are referring to, also adds/removes certain packet support).

How many versions do we really need??? >:(

[quote author=Kp link=board=17;threadid=1147;start=15#msg8570 date=1051419736]Actually, if I add error code reporting, it'll probably be in the form of having the parser return 0 for no error, or nonzero on error. If nonzero is returned, then the returned value is passed to the client.
[/quote]Fine with me, just as long as an error code is produced and transmitted to the client.

To kp:
Kane raises a good point by saying that an empty channel string could indicate that the client is not logged on. If that were implemented - or merely, allowed (afaik it's not currently) - no additional field would be required.

To Kane:

Since you seem to have a good handle on this, I wonder if you'd like to help improve BnetDocs' BotNet documentation? If you have any suggestions for things to change, or any specific things you think should be clarified, I'd be happy to do that. I'd be happy to reciprocate with a higher access level or appripriate credit if you wish.

Yes, it's back up along with the rest of vL.com, and no, I doubt anyone wants to implement IBP because it was crap to begin with and BotNet is better, so just add support for that.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8575 date=1051427160]
Programmers wouldn't be so "willing" to break the protocol spec if it was more specific on the specifics.[/quote]A strict interpretation would be that anything not specifically permitted is not guaranteed to work or be allowed.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8575 date=1051427160]IMO, it's really not too hard to do backwards compatibility... Again, I would need to know more about the server in order to understand.[/quote]Server backwards compatibility is easy enough. However, if message formats start changing, the new-format-aware clients must also support old format messages in order to handle older servers.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8575 date=1051427160]Additionally, doing a domain lookup shouldn't be relied upon to do find out the NAME of the gateway. Suppose the lookup fails? Suppose it comes out to something like bne-watcher-01.battle.net? Sure it'll tell the user what gateway they're on, but can a bot automatically know that bne- is USEast? Maybe through some file, perhaps, but that's eww++. The best way is for the other bot to know what gateway it's on (whether told by the user or by doing a /whoami after SID_LEAVECHAT) and report that to BotNet.[/quote]I'm suggesting that the reporting client not care at all what gateway it is on. It merely submits the IP address to which it connected, and observing clients can use that address to figure out which gateway the reporter is on. Also, I'd expect that the /whoami method will produce bizarre results (if it at all works) if you tried that on a bncs-emulator, since most of those are not greatly compliant.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8575 date=1051427160]Sure! Use the gateway names to identify who's using what command (and who has access to what command). As such, any commands received from botnet will be "Account@BotNet". Additionally, you could then "link" (associate) BotNet accounts to Battle.net accounts, and then display the "main" account@gateway, and do command processing that way. Not necessarily an easy task, but quite a luxury if done right (it's very possible to do).[/quote]Convention has mostly dictated that you simply keep one database per server cluster ([vL]West vs. [vL]East, for instance). Also, aside from the war3/nonwar3 mangling issue, your linking idea doesn't require gateway identification IMO.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8575 date=1051427160]Empty... blank... nil... null... none..., and use a different parameter to specify "Not logged on".[/quote]Noted. I'd been considering this, but again a compatibility issue is introduced. Old versions of the server would take rather unkindly to a blank channel field, thus hurting client compatibility with old servers.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8575 date=1051427160]That could be done via a bot command over botnet (aka interbot).[/quote]It could, but cycling support works a bit better for that. The point is moot anyway, since there are no longer any channels in which ops can regenerate.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8575 date=1051427160]A possible use of the cycle status, in relation to replacing the "Not logged on" in angle brackets for the channel text.[/quote]I won't remove old fields. New ones may be created if there is sufficient merit, though.

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8575 date=1051427160]That might be fine for the BotNet server, but it's not fine for bot interoperability (as you've subtly pointed out). A standard should be set up for user flags.[/quote] That's outside the scope of botnet server development. :)

[quote author=tA-Kane link=board=17;threadid=1147;start=15#msg8575 date=1051427160]Oh yeah, and there's THAT protocol revision as well. So, we now have *3* protocol revisions to worry about.

The one on the packet level (Protocol 'Version'; this is the one I was referring to, currently doing absolutely nothing except disconnecting the client if not 1).
The one specifying the server version (Server Version; this is the other one I was referring to, currently adds/removes certain packet support).
And, the one which is used to specify the expected format of packets (Protocol 'Revision'; which is the one you are referring to, also adds/removes certain packet support).

How many versions do we really need??? >:([/quote]There actually is a logic to this. Packet revision, as specified in packet header will likely change only if support for old clients is completely dropped. Server version acts as an indicator of new features and whether protocol versioning is supported. Protocol revisions reshape packets internally, and add information to the reshaped packets.

i'd just like to point out that pastachat uses botnets database (it has same flagging system as zerobot :p)

[quote author=Kp link=board=17;threadid=1147;start=15#msg8659 date=1051505120]A strict interpretation would be that anything not specifically permitted is not guaranteed to work or be allowed.[/quote]Why limit yourself? I thought the whole idea of working on binary Battle.net bots was to discover what you could do, without being specifically told you can do such a thing? As such, I thought it was assumed to be similar with BotNet; create ideas for a use of BotNet instead of being limited to what "we" tell you to use it for...

[quote author=Kp link=board=17;threadid=1147;start=15#msg8659 date=1051505120]Server backwards compatibility is easy enough. However, if message formats start changing, the new-format-aware clients must also support old format messages in order to handle older servers.[/quote]I was meaning backwards compatibility in general. If you make something and gear it for multiple possible changes in future versions and know that you may encounter both "new" environments and "old", then backwards compatibility is a given must, and thus you program accordingly. That being said, only someone who wants to program for "what works now" is not going to program for backwards (or perhaps forwards) compatibility, and thus backwards compatibility is easy to do. As such, my botnet socket supports botnet server versions 2, 3, and 4, because I know that there may be other people wishing to create their own BotNet server, and might only have access to revision 2 specs, or perhaps don't like the newest revision and only want to implement revision 2.

In my eyes, backwards compatibility is easy for both the server and the client, if pre-programmed for changes. As such, perhaps you should stop letting clients' backwards compatibility issues affect what you do with the server.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8659 date=1051505120]Also, I'd expect that the /whoami method will produce bizarre results (if it at all works) if you tried that on a bncs-emulator, since most of those are not greatly compliant.[/quote]Oh well... I just thought that was a good argument :-\

[quote author=Kp link=board=17;threadid=1147;start=15#msg8659 date=1051505120]I'm suggesting that the reporting client not care at all what gateway it is on. It merely submits the IP address to which it connected, and observing clients can use that address to figure out which gateway the reporter is on.
...
Convention has mostly dictated that you simply keep one database per server cluster ([vL]West vs. [vL]East, for instance). Also, aside from the war3/nonwar3 mangling issue, your linking idea doesn't require gateway identification IMO.[/quote]That's eww. Why would a good bot not care about what gateway it's on? Obviously, convention prevents the use of a single database for a multi-gateway clan. Why don't you like the idea of having a single clan on a single database, and thus not cluttering up BotNet with multiple databases for a single clan?
Gateway identification is indeed required for both single-gateway clans that play/use both WarCraft 3 and other games, as well as for multi-gateway clans, since the validity of a user without the gateway appended to them (eg, users on the same gateway as the bot) to be able to use various commands is required.

Additionally, if you want your bot to be able to use the same database on both WarCraft 3 as well as other games, even on the same gateway (eg, Azeroth and USEast), you will need to identify the gateway name you are on (Azeroth or USEast), so that commands and flags work correctly.

Once the bot knows what gateway it's on, it's not hard to automatically append the default gateway to any user flags modifications, so that the users don't need to specify the local gateway, and yet still be able to specify other gateways.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8659 date=1051505120]Noted. I'd been considering this, but again a compatibility issue is introduced. Old versions of the server would take rather unkindly to a blank channel field, thus hurting client compatibility with old servers.[/quote]It wouldn't hurt client compatibility with old servers. All they'd need to do is be aware of this fact, and set the channel field accordingly.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8659 date=1051505120]It could, but cycling support works a bit better for that. The point is moot anyway, since there are no longer any channels in which ops can regenerate.[/quote]There are on bncs emulators. Additionally, if the point is moot because there's no channels which may regenerate ops, then (again, I ask) why do you keep the field? Or perhaps Skywing would like to comment?

[quote author=Kp link=board=17;threadid=1147;start=15#msg8659 date=1051505120]I won't remove old fields. New ones may be created if there is sufficient merit, though.[/quote]Don't remove old fields? Bah... oh well. If old fields are never going to be limited, then you need a way of selecting what fields the client will be using. I like your idea of using flags to specify such, but that limits the number of parameters to the number of bits in the flags. Oh well, I think we can cross that bridge when we get to it...

[quote author=Kp link=board=17;threadid=1147;start=15#msg8659 date=1051505120]That's outside the scope of botnet server development. :)[/quote]Shush you! :P

It's not really outside the scope of BotNet server development if the whole idea of BotNet is the coordinateion of bots.

[quote author=Kp link=board=17;threadid=1147;start=15#msg8659 date=1051505120]There actually is a logic to this. Packet revision, as specified in packet header will likely change only if support for old clients is completely dropped. Server version acts as an indicator of new features and whether protocol versioning is supported. Protocol revisions reshape packets internally, and add information to the reshaped packets.[/quote]It should be mentioned in the protocol spec that you should disconnect or ignore when receiving such packet headers.

Additionally, anyone looking at the protocol spec wouldn't know the difference, simply because of how poorly documented it is.

[quote author=tA-Kane link=board=17;threadid=1147;start=30#msg8663 date=1051513908]
[quote author=Kp link=board=17;threadid=1147;start=15#msg8659 date=1051505120]It could, but cycling support works a bit better for that. The point is moot anyway, since there are no longer any channels in which ops can regenerate.[/quote]There are on bncs emulators. Additionally, if the point is mute* because there's no channels which may regenerate ops, then (again, I ask) why do you keep the field? Or perhaps Skywing would like to comment?
[/quote]

Is that a correction of his spelling (bold word)? If so, moot is a word (meaning irrelevant), otherwise ignore me. :-\

[quote author=kamakazie link=board=17;threadid=1147;start=30#msg8665 date=1051515601]
[quote author=tA-Kane link=board=17;threadid=1147;start=30#msg8663 date=1051513908]
[quote author=Kp link=board=17;threadid=1147;start=15#msg8659 date=1051505120]It could, but cycling support works a bit better for that. The point is moot anyway, since there are no longer any channels in which ops can regenerate.[/quote]There are on bncs emulators. Additionally, if the point is mute* because there's no channels which may regenerate ops, then (again, I ask) why do you keep the field? Or perhaps Skywing would like to comment?
[/quote]Is that a correction of his spelling (bold word)? If so, moot is a word (meaning irrelevant), otherwise ignore me. :-\
[/quote]Errm, I was incorrect in correcting him. After looking it up in the dictionary, you are correct.

[quote author=tA-Kane link=board=17;threadid=1147;start=30#msg8663 date=1051513908]
[quote author=Kp link=board=17;threadid=1147;start=15#msg8659 date=1051505120]It could, but cycling support works a bit better for that. The point is moot anyway, since there are no longer any channels in which ops can regenerate.[/quote]There are on bncs emulators. Additionally, if the point is moot because there's no channels which may regenerate ops, then (again, I ask) why do you keep the field? Or perhaps Skywing would like to comment?
[/quote]
Some clients still support this - namely, mine.