I apologise for misconstruing the efficiency of the expression as I posted it. I also apologise since, it seems from a little bit of further research, that mIRC's handling of inline if statements is grossly less efficient than I'd thought. In any other language, interpreted or not, they're handled with a rather great deal more speed than mIRC.
I was taught that regardless of the implementation of the regular expression, using a regular expression with no regards to the specific content of the text - that is, if the regular expression needs to be invoked at all - should be frowned upon in favour of simpler if statements to check if the complexity of a regular expression is required. Unfortunately, when it comes to mIRC, this method of thinking is less efficient than desired, but presuming the average percentage of lines containing 'BBCode' is under 90%, there's still advantage to be gained with the use of an if statement. Execution speed when only 5% of lines contain 'BBCode' is nearly halved, while when 95% of lines contain 'BBCode' execution speed is slower by 10%. (For reference, the percentage at which the two methods apparently reach equal execution times is 89.7%, although I doubt that the method of testing we're using is accurate to that level of precision.)

And, in case you're curious, the adaption to your speedcheck alias which I used to test this out is:

alias speedcheck {

  ;Play with average percentage of lines containing []s
  var %perc 897
  ;var %perc 500

  var %b = 20000
  !var  %t = $ticks
  while (%b) {
    var %a = $iif($r(1,1000) > %perc,$str(abcd,100),$str(aaa[ $str(b,30) ]ccc,10))
    if ([ isin %a) { !noop $regsubex(%a,/\[[^]]+\]/g,) }
    else { !noop %a }
    !dec %b
  }
  !var %c = $ticks - %t

  var %b = 20000
  !var %t = $ticks
  while (%b) {
    var %a = $iif($r(1,1000) > %perc,$str(abcd,100),$str(aaa[ $str(b,30) ]ccc,10))
    !noop $regsubex(%a,/\[[^]]+\]/g,)
    !dec %b
  }
  !var %d = $ticks - %t

  echo -a First method: %c ms -- Second method: %d ms
}

Anyway, Jaytea, thankyou for giving me the opportunity to learn a little more.

You're missing the point. Using a character class - especially a negated one - creates additional work for the regular expression engine. The simpler the match, the quicker the function. A character class is slower than a wildcard match; The . wildcard is particularly efficient, since the regular expression engine doesn't have to care so much about what it matches.
The byte-size of your regular expression has very little to do with its efficiency.
Strictly speaking, if you wanted to improve the execution speed when dealing with large amounts of text, you'd use something along the lines of
alias a4 return $iif([ isin $1-,$regsubex($1,/[.+?]/g,),$1-)
Since an if/find operation is vastly quicker in execution than a regular expression.
Hope my explanation helps.

Your regular expression is long and requires an unnecessary amount of parsing. /[.+?]/g is slightly more efficient.

Wow. How did you manage that? Which location are you looking up weather for? I've never seen nor experienced such before.

In the case of mIRC scripting, which is going to run slower than a fat bitch up a flight of stairs, there's only so much difference that using a replace instead of a bunch of if's will make.

There's an option in the popups to disable the flood protection, and you're also able to set the flood time-out to what you wish - simply look in the code for where the comment states the flood protection is, and set the 300 second limit to something smaller. :)

sif, joshface. A simple per-nickname flood protection would make the script more useful. Josh = fool.

Sigh. Even if you add a ",0" to my $iif() statement, it still won't behave like the original, since the lower bound would be 0 rather than 1. Realistically, you'd need to use $calc() to increase the output by 1, in order to match his example.
HOWEVER the fact that it does not match the example in behaviour by returning the same values for the same modes is irrelevant - the fact remains that higher modes return higher numbers, thus you're able to establish precedence, which is the point of the snippet as explained in the original post.

While yes, you can shorten the code in that fashion, you'd have a single, long, hard to read, and hard to edit line. As the code stands, it's quite readable and editable. :)

Sure, they both work fine - but so did the original. I was pointing out to you that if you wish to save space, then do it, but do it neatly and properly.
Also, it won't error, it'll return nothing. In other words, return $null - the common behaviour of most in-built mIRC identifiers.

It's messy because you're using braces and pipes where you need not use them, and the vars don't need to be used at all either. See the following:

alias modenum return $iif($findtok(+ % @ & ~,$left($nick(#,$1).pnick,1),32),$v1)

Perhaps the global variables could be replaced with a more dynamic data type, so that you could allow multiple simultaneous users? Just my two cents. :]

Slacker, those are the worst variable names I have ever seen, and you're using variables rather pointlessly. Why not code cleaner?

A snippet to retrieve a number of bits of useful information from Google. Can look up Weather or Time for a location, and can look up results from Google's calculator. Usage: In a channel where the bot is running...

I hate to break it to you, but if you're storing that much data in an INI file, perhaps the access is frequent enough to warrant the use of a set of hash-tables.

Besides that grudge, there are two areas in which this could be improved greatly:
1) Obfuscation of variable names makes life difficult. %y, %x, %d, and %b could be a little more descriptive.
2) If I were you, I'd have written it using /fopen, /fseek, and /fwrite. Much faster and more powerful.

Other than that, it looks useful and well written. :]