Before I begin, I suggest you look at this very very very old banning scriptlet I wrote long long long ago. A little here and there has been updated, but most of it hasn't been update in probably six years. (No it doesn't work, would if I hadn't started moderizing it). Be sure too look for the /set varaibles. That should show just how old it is.
http://www.nomorepasting.com/paste.php?pasteID=22787Now if you can understand any of that, it would be perfect for what I'm anout to suggest. And if code that complex would be helped by such a suggestion, well, I can't think of much else that would.
mIRC does NOT need threading support. No! I see no need for this. But there is a solution that would almost do the same thing. A '"yield" command to allow execution of other events and code to run. Once execution cesies, or another "yield" is invoked, the code will continue executing. Of course data could easily become out of order, I'd imagine if you can find a way to use "yield" then this won't be a problem.
Yield is not multithreading! I don't think mIRC coders could grasp multithreading. You'd just see them invoke a new thread, then instigate a loop while waiting for the data. Which completly defeats the purpose of multi-threading.
Yield would be simple for scripters to use, and for Khaled to impliment (I hope). And if scripters don't use yield correctly or at all, well forget threading.
Anyhow just my suggestion.
