Since a long time ago I've known that /filter has trouble sorting rather large numbers, even if those numbers can still be interpreted validly in an if statement. I did a search and could not find this reported, so I guess I simply forgot to report it in all this time.

Observe the following example:

Code:
alias filterbug {
  tokenize 32 40521140400 719036000000 508554000000 36067462783 $&
    512061375703 8403263000 171598000000 2393173908 479065999380 358651999380
  window -n @@
  aline @@ $*
  filter -wwctue 1 32 @@ @@
}


After issuing this, the window @@ will contain the filtered results. You'll notice that the 40521140400 is first in the list followed by 719036000000, which of course is not correct because:

//if (719036000000 < 40521140400) echo -a true

does not echo.

I was wondering to report this as a feature suggestion or a bug, but choose for the latter, since these numbers are not big enough yet for mIRC to become any sort of problem. $calc can manage them fine, so can an if comparison, so I don't see why /filter shouldn't be able to handle them.

Btw, currently I am zeropadding all numbers and doing an alphabetic sort as a workaround, but I would prefer to be able to have it work in the regular way.

mIRC 6.16, Windows XP+SP2

Gone.