I was just recoding a script i had written that started to bog down time wise when its dealing with 1000's of files, it checks if a sent file already exists and redirects the download to that files location if the send is longer, well anyway, i couldnt actually use what came to mind while doing it, but heres what i was thinking about.
I know (suspect) it would be quite hard to make mirc multithreading, so i beleive most scripts well always have to run to completion before control is handed back.
What if there was a command (/yield) that said "ok lets stop the script here & start a timer to resume here when it reaches zero & pass control back", mirc then can deal with any pending events etc, and then the timer goes off after them.
I said a timer becuase thats currently how i deal with any large levels of looping, ill just set a timer off using "/timer 1 0 aliasname" then that alias does what ever and if it would normally loop back it calls itself using he same /timer 1 0 system.
This allows mirc to catch up on anything its needing to do, and still process my loop.
I do accept that a command in the center of a script doing it could run into problems, the most obvious is the same script being called during a /yeild.
That could be of course mentioned in a warning to use this with care, or any occurances of the same /yeild command being encountered well be ignored, so the subsequent calling of a script would just countinue to run.
PS: im sure there are problems with this, just throwing it out as an idea.
