I know that this topic has been already covered but I have few questions i need help with.

I am currently trying to put together a bot in VB and whenever i unsquelch someone in the void on my bot, the program freezes or (unless I use On Error Resume Next in my DataArrival sub) it throws a Run-Time Error '5'.

Is this because the winsock is overloaded with all the data it receives after the flags in The Void are re-enabled? If so, how can I make it so that it devides the data and receives it little by little.

You shouldn't be unsquelching anyone in The Void, you should only unsquelch yourself, than bnet just does a flag update for you. Which if your "Channel" event is done properly it should list everyone after the update.

[quote author=l2k-Shadow link=board=17;threadid=8397;start=0#msg77514 date=1093574474]
I know that this topic has been already covered but I have few questions i need help with.

I am currently trying to put together a bot in VB and whenever i unsquelch someone in the void on my bot, the program freezes or (unless I use On Error Resume Next in my DataArrival sub) it throws a Run-Time Error '5'.

Is this because the winsock is overloaded with all the data it receives after the flags in The Void are re-enabled? If so, how can I make it so that it devides the data and receives it little by little.


[/quote]

It sounds like your not handling incomplete packets properly, and it's getting you stuck in an endless loop.

[quote author=LordNevar link=board=17;threadid=8397;start=0#msg77524 date=1093575911]
You shouldn't be unsquelching anyone in The Void, you should only unsquelch yourself, than bnet just does a flag update for you. Which if your "Channel" event is done properly it should list everyone after the update.
[/quote]

that appeared to be my exact problem, thanks very much

Just a minor comment: to help protect against situations like this in the future, it's generally a good idea to have your handlers impose some basic sanity checks on the packet (like, the ID isn't above highest known ID for this product, length isn't thousands of bytes, etc.) It won't catch all the problems, but it's pretty unlikely that a corrupt stream could still pass all the sanity checks. For reference, the largest profile messages I've ever seen are somewhere around 400-500 bytes, iirc. Since the individual fields are each capped at 512 bytes, it could get a lot longer if you profiled somebody who'd used a custom client to max out their data, but even then, I'd say nothing should exceed 2kb. The exact limits you choose should depend on the protocol and expected messages, of course, but hopefully these will give you a starting point.