Newest CSB

[CupHead]

Before I rewrite CSB (for the 3rd time), I would like some input as to what features people want to see in it this time.  There are already plans for how it will be implemented, so I'm looking for feature requests related to the actual b.net protocol.  Anyone is welcome to suggest stuff.

[Kp]

Before I rewrite CSB (for the 3rd time), I would like some input as to what features people want to see in it this time.  There are already plans for how it will be implemented, so I'm looking for feature requests related to the actual b.net protocol.  Anyone is welcome to suggest stuff.

An optional callback that is called on data receipt / transmit, so the user can readily track all data being sent by CSB at the time of transmission.  This would be very useful in letting people see exactly what they're sending when they use the packet-building capacilities.

An optional built-in flood protection queue, since so many people seem unable to write one.

Not crashing on using war3.

[Skywing]

Building on Kp's idea, I'd suggest that the user callback be able to disable the default CSB handling of a received messages.  Among other things, this could be used as a workaround for problems like the current not-being-able-to-connect-as-Warcraft-III bug if/when you lose the source code again.

[CupHead]

Yes, War3 will be the main fix.  The flood protection can be added, and yes, I can add an event so that people can see what is sent.

[CupHead]

Yes, that is also a good idea.  I do tend to be so absent minded about these things.  As a little bit of a preview, because of the implementation of the new CSB, users will have access to all data before it even gets into CSB routines thus allowing them to write custom handlers for packets.

[Freeware]

1. An option NOT to handle chat events
2. Local Hashed Option
3. Support every client (STAR,SEXP,W2BN,D2DV,D2XP,WAR3,W3XP,SSHR,DRTL,DSHR, and CHAT)
4. Keep the packetbuilder like before
5. Optional Queue
6. If you dont want to go with local hashed option, let the user do it themselves with events such as:
CleanSlateBot1.Send0x51 Version, Checksum, GTC, Cdkeyhash, Exeinfo, Owner (etc... for all packets)

Edit - Removed #7 - people keep changing the subject by commenting on it.

[Skywing]

Yes, War3 will be the main fix.  The flood protection can be added, and yes, I can add an event so that people can see what is sent.

If you're adding a flood protection system, it may be a good idea to allow the user to specify an (optional) function for calculating message delays.  Considering that Blizzard has changed their flood protection at least twice now, this would provide future compatibility if/when they do so again.

[Grok]

Hardcode it to prevent stupidity.

[CupHead]

Like that would help.  See DM's signature.

[iago]

Don't allow people using it to join vL's channel.  Make it remap the user's HOSTS file so they can't access forum.valhallalegends.com.

[Hazard]

Diabolical... yet ingenious at the same time.

[CrAz3D]

Maybe some type of simple command sub?

[SKiLLs]

I think you should make it so it can update to the new patches and all or when a new patch comes out it will have no use on that game..

[Skywing]

I think you should make it so it can update to the new patches and all or when a new patch comes out it will have no use on that game..

Old versions did this as well - it's a pleasant side-effect of using BNLS for handling the version check procedure.

[Dark-Feanor]

It would be kind of cool if CSB did the entire queue thing for you. Like:

Code Select Expand


cleanslatebot1.addq "blah"
cleanslatebot1.sendqnum(element number)
cleanslatebot1.removeqnum(element number)
cleanslatebot1.clearq

That would certainly help new programmers from constantly dropping and getting IPbanned.