mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2005
Posts: 44
S
Ameglian cow
OP Offline
Ameglian cow
S
Joined: Jan 2005
Posts: 44
Included in my tokens are the remote identifiers $nick and $chan.

I've noticed that $gettok wont retrieve those tokens unless I leave a space after them in my coding. Is this a bug or is there a logical reason for this?

my token separator is the "&"

Code:
on *:text:*:#: {
  if ($istok($1-,hi,32)) {
    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)
  }
  elseif ($istok($1-,bye,32)) {
    var %bye = see ya, $nick &bye&Hmmmmmmmm....&laters&bye bye bye&see yaaa&hu hu hu bye&I will miss u....&Do you really have to go?&Hey where are you going?
    msg $chan $gettok(%bye,$r(1,10),38)
  } 
}  

Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Quote:
Included in my tokens are the remote identifiers $nick and $chan.

I've noticed that $gettok wont retrieve those tokens unless I leave a space after them in my coding. Is this a bug or is there a logical reason for this?


Its a logical reason, $nick or $chan cant have any characters following it other wise its not "$nick" its "$nick&Hello" which doesnt come back with the nick.

simple fix $+
var %hi = hello, $nick $+ &hello again&Hmmmmmmmm....&do I know you?&kk&hey&Hey how are you?&Sup man wb!&Waaaassssup?&Welcome To $chan

$+ connects whats on the left and right with no spaces.

Joined: Jan 2005
Posts: 44
S
Ameglian cow
OP Offline
Ameglian cow
S
Joined: Jan 2005
Posts: 44
Quote:


Its a logical reason, $nick or $chan cant have any characters following it other wise its not "$nick" its "$nick&Hello" which doesnt come back with the nick.



I mean, I do realise that that's the case which is why I added the extra space in the above code, but shouldn't the token separator which is & prevent "$nick&Hello" being treated as one word?

I would have thought everything from & onwards gets ignored after $nick . It just seems an inconsistant rule for tokens.

Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
It's not inconsistent, considering that the token separation happens after the evaluation of identifiers, variables etc. This is perfectly normal, here's an example:

//var %blah = XbYbZ | echo -a $gettok(%blah,2,98)

(98 is the ascii value of the letter "b")
Wouldn't you expect the above line to echo "Y" (ie the 2nd token in the value of %blah) and not "lah" (which is the 2nd token in %blah's name)?


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Jan 2005
Posts: 44
S
Ameglian cow
OP Offline
Ameglian cow
S
Joined: Jan 2005
Posts: 44
Quote:
It's not inconsistent, considering that the token separation happens after the evaluation of identifiers, variables etc. This is perfectly normal, here's an example:

//var %blah = XbYbZ | echo -a $gettok(%blah,2,98)

(98 is the ascii value of the letter "b")
Wouldn't you expect the above line to echo "Y" (ie the 2nd token in the value of %blah) and not "lah" (which is the 2nd token in %blah's name)?


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?

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 still think it can be fixed without ruining anyones day or stuffing up anyone's script.

Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
The reason tokens aren't separated prior to evaluation in $*tok identifiers is to maintain consistency with the rest of the identifiers, whose parameters are first evaluated one by one and then their values are passed to the appropriate internal function. So I think we'll agree that if $*tok identifiers were to work like you want, they should either work differently from the rest (inconsistency) or the language should be redesigned. Whether the latter should happen is a different and very long discussion, but on this particular area, I think you're just not used to this way. Once you get to know the language, you'll find that you can do a LOT of things with strings very easily. In your case, for example, something like that would do the trick:

//var %a = $(hello $me&I'm using windows $os $bits $+ -bit&blah,0) | echo -a $($gettok(%a,$r(1,3),38),2)

$() is the same as $eval(). So what we're doing is wrap $(..,0) around the text, to prevent mirc from evaluating it. Then we feed it to $gettok(), which returns a specific token (with any identifiers left unevaluated). That token is then fed to $(..,2), which evaluates any identifiers/variables in it.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Jan 2005
Posts: 44
S
Ameglian cow
OP Offline
Ameglian cow
S
Joined: Jan 2005
Posts: 44
Quote:
, but on this particular area, I think you're just not used to this way. Once you get to know the language, you'll find that you can do a LOT of things with strings very easily.


That's probably the root of my frustration, I guess - not being fully versed in mirc scripting, some things just don't seem logical at first glance.

And I'm not wanting to sound like I'm criticizing, but the help files don't really shed much light on this sort of thing.

Anyway, thanks for your patience with me and for clarifying it more.

Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
[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]

Quote:
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)


Quote:
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.

Quote:
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"


Quote:
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 #mirc
Of 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 **

Last edited by DaveC; 16/02/05 09:46 PM.
Joined: Jan 2005
Posts: 44
S
Ameglian cow
OP Offline
Ameglian cow
S
Joined: Jan 2005
Posts: 44
thankyou for the explanation. Had to read it a few times before I fully grasped what you meant, but I think I understand now.


Link Copied to Clipboard