[edit]
I should really stop writing replies and leaving them open for hours on end before sedning them, you had been replied to and replied before i sent this up, sorry
[/edit]
I would have thought everything from & onwards gets ignored after $nick . It just seems an inconsistant rule for tokens.
You have missed a simple point here, $nick is not present in the %hi, the actual nick is present in there, The setting of the values of $nick and $chan into the string have nothing at all to do with tokens, and the character & is not a token seperator its just a character. Mirc can not know what you intened to do with this string so how is it to know you well ever only want one of the sections of it based on the character & untill it encounters a command such as a $gettok.
var %hi = hello, $nick &hello again&Hmmmmmmmm....&do I know you?&kk&hey&Hey how are you?&Sup man wb!&Waaaassssup?&Welcome To $chan
msg $chan $gettok(%hi,$r(1,10),38)
If it occurs after, it's a very inefficient way of going about something simple.
Say for example, you have a whole line of remote identifiers as tokens, why evaluate each and every remote identifier if only one is actually needed?
Inefficient? or Inconvenent to you? If understand you, you felt a string should maintain the litteral strings "$nick" & "$chan", this is impracticial as bioth those values are temporary local only on the event driven script running.
While you did set them to a local variable mirc can not foresee your inteneded use of that vairable, so can not know you were going to use it as a set of tokens. So can not know only one of them was going to be needed.
Granted the var %blah in your example would need to be evaluated first, but other than the immediate var in the gettok, the remote identifiers contained in tokens themselves should only be looked at after token separation.
Was this overlooked, or did Khaled have a rationale why he did it this way? (or is it that remote identifiers were never intended to be used within tokens?)
I keep getting this idea poping up that you thing the $nick and $chan are actually in the string, there not, the contents of them are ie if $nick is DaveC and #chan is #mirc then
%hi = hello, DaveC &hello again&Hmmmmmmmm....&do I know you?&kk&hey&Hey how are you?&Sup man wb!&Waaaassssup?&Welcome To #mirc
Tokens identifiers are designed to break up a string of text based on one particular character in that string of text and then perform there said action on said tokens. They dont care what the contents of that string is, whether it be "$nick" or "DaveC"
I still think it can be fixed without ruining anyones day or stuffing up anyone's script.
If changed to how you percieve it would cause IMO the largest number of functional scripts to fail ever percieved, It also would not effect your script one bit, since you use NO remote identifiers in your $gettok, u only use the already evaluated result.
heres an example of some bugs it would produce
Assume : $1- = The trial went well. We gave it all we had. And we won.
$gettok($1-,2,46)
returns $null since there are no "." in "$1-" Assume : $address =
DaveC@my.domain.com$gettok($address,2,48)
returns $null since there are no "@" in $address var %a = $address | $gettok($address,2,48)
returns my.domain.com becuase %a = "DaveC@my.domain.com"-
At the end of it all this is what you wanted.
var %hi = hello, $!nick $!+ &hello again&Hmmmmmmmm....&do I know you?&kk&hey&Hey how are you?&Sup man wb!&Waaaassssup?&Welcome To $!chan
msg $chan $eval($gettok(%hi,$r(1,10),38),2)
$!identifier well be placed into the %hi as $identifier so is not yet evaluated, you then need to tell mirc to
$EVALuate that string for identifiers etc,
,2 becuase evealating the string once is changing it from
%hi to
hello, $!nick $!+ &hello again&Hmmmmmmmm....&do I know you?&kk&hey&Hey how are you?&Sup man wb!&Waaaassssup?&Welcome To $!chan and the 2nd time to
hello, DaveC&hello again&Hmmmmmmmm....&do I know you?&kk&hey&Hey how are you?&Sup man wb!&Waaaassssup?&Welcome To #mircOf course that above is if u $eval(,2) the whole string, you only do it to one of the tokens.
** Be advised watch what you put in a string that your going to evaluate like that, dont allow it to be user inputed, ie no ON *:TEXT $1- values, beucase they can exploit you **