Repost. List your Ideas HERE!

[Noodlez]

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

[tA-Kane]

A strict interpretation would be that anything not specifically permitted is not guaranteed to work or be allowed.

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...

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.

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.

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.

Oh well... I just thought that was a good argument  

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.

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.

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.

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.

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.

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?

I won't remove old fields.  New ones may be created if there is sufficient merit, though.

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...

That's outside the scope of botnet server development.

Shush you!

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

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.

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.

[dxoigmn]

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.

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?

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

[tA-Kane]

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.

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?

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

Errm, I was incorrect in correcting him. After looking it up in the dictionary, you are correct.

[Skywing]

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.

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?

Some clients still support this - namely, mine.