To see the sucker in work try:
//echo $gettok(.........WHY?....., 1, $asc(.))

It will return WHY?
why?
Don't get me wrong, but why? is hardly the first token. I doubt there will me much resistance on this point. But, I often delinate data I store with ; or . or some other character I know I won't use in the data itself. The problem is sometimes the data is empty, and in these cases I have to put a zero and code that a zero means null or the bugger gives me the next items which really isn't right...

i dont think thats really a bug because to separate ur gettok its asking for it to say what is the first match between the ... in there ....... test it filling in the spaces between the dots with something like

//echo $gettok(.a.s.d.f.g.h.j.u.WHY?....., 9, $asc(.))

and it also will now return WHY? but using 1 it returns a
by having the . (dots, periods) thats the separator in the line ..... i dont think thats really a bug but maybe ur usage of it thats kinda off a lil ....... altho i could be mistaken

i also dont believe that this is a bug
i already wrote a gettok function and used the same strategy, because this is so more useful
i am not sure how you want to store that data, but maybe using indexed dynamic variables or ini entries would be better

This isn't a bug, token identifiers are designed this way (they ignore empty/null tokens).

ok see i thought it was like that but um i wasnt positive thats why i sai i could be wrong ....... lol good to see someone else agreeswith my opinion

Hmmm, somehow I think it should return $null when the token is null.

That would break a hell of a lot of scripts... perhaps a new switch for the identifiers would be nice, but that would be a feature suggestion, not a bug.

I'd rather see $null tokens added and have broken scripts then have half-measures and workarounds for the sake of compatability.

Perhaps its not the prettiest way of doing things, but it's hardly a workaround or a half-measure, it's an option, and IMO hardly an option work screwing up alot of scripts for either.

The ability to have $null tokens, both in the token identifiers and in $N would be a very useful extension to the scripting language. Certainly worth the occasions that it messes up old scripts in my opinion.

It is scriptable for the token identifiers (I mean to make your own), but not for the $n ones (which would be useful), so since it would be stupid to do one without the other I'll change my vote (i.e. you win ).

How about $gettok(...).all or something (for all token identifiers) that would include $null tokens for counting while $gettok(...) would return the same.

I agree. Logically mirc should return * /echo: insufficient parameters, when this is typed:

//echo -a $gettok(one@@three,2,64)

Ive scripted mIRC for a long time, and this is how I would expect mIRC to act. That fact that mIRC returns 'three' is inconsistent and unuseful in my opinion. I don't know why we should presume that Khaled intended it to perfom this way... Nobody knows that. This COULD be a bug, If it isn't, In my opinion, it's a design flaw, and should be fixed. Who cares if breaks 'Ultr4 D34tH ScRiPT' on mIRC 5.6...