I have downloaded and tried the new beta. And it definitely works. Here is my test:
//window -ae @test | var %j = 0, %s | while (%j <= 20) { .fupdate %j | var %i = 1, %n = 1000, %t = $ticks | while (%i < %n) { echo $calc(%i % 100) @test %i $str(X,100) | inc %i } | var %m = $calc($ticks - %t), %s = %s $+(%j,:,%m) | echo 4 -a done. fupdate= %j in %m ms. | inc %j } | echo 13 -a DONE. (fupdate:millisec) %s
(fupdate:millisec) 0:3250 1:1875 2:1485 3:1219 4:1093 5:1000 6:891 7:828 8:781 9:703 10:687 11:672 12:656 13:625 14:578 15:563 16:562 17:547 18:532 19:546 20:500
Law of diminishing returns suggests that with the latest update an fupdate of 10 is a good setting - and since I doubt you will see any delay at 10ms, a default of /fupdate 10 might be ok.
That said...
I am unclear what impact the fupdate setting has on the algorithm just described by Khaled.
Additionally, without some sort of server driven flood test running mIRC on a low powered CPU, I have no idea whether this would stop mIRC locking up in such situations.
