can seem to make this work

set %howlong $datediff(%search-nick4- $+ $nick, %timedate1 $+ $nick)

however this does ..

set %howlong $datediff(%search-nick4-WarlockWeary, %timedate1WarlockWeary)

Any Suggestions ?

other then when setting a variable you need to use $eval when getting a variable that has an identifier in it

have an exsample ? lol

no idea what you just said ..

help ?

by the way the comma right next to $nick
might have something to do with it i could be wrong of course

Well, first of all, what you pasted that you got as result is impossible, and I'll show you why with this example:

//set -s %search-nick-4 $+ $me blah | echo -a %search-nick-4 $+ $me

As you can see, it will echo your nickname ($me), because the %search-nick-4 variable evaluated to $null (nothing) and $me evaluated to your nickname. This is normal procedure, and if you want to evaluate a dynamic variable you need to take special steps in order to do so.

//set -s %search-nick-4 $+ $me blah | echo -a %search-nick-4 [ $+ [ $me ] ]

//set -s %search-nick-4 $+ $me blah | echo -a $eval( $+(%,search-nick-4,$me) ,2)

//set -s %search-nick-4 $+ $me blah | echo -a [ [ $+(%,search-nick-4,$me) ] ]


What did we just do:

First example

%search-nick-4 [ $+ [ $me ] ]

We used evaluation brackets [ ] to control the order of evaluation. We told it to first evaluate $me by surrounding it with brackets [ ] so you get: [ $me ].
Then we want to evaluate the $+ which concatenates the $me part with the %search-nick-4 part so we put brackets around $+ [ $me ] so that it turns into: [ $+ [ $me ] ]

Now mIRC is left with the following to evaluate: %search-nick-4<nickname>, it does this so you get the correct value (blah) here.

Normally it would have valuated the %search-nick-4 part to $null, but because of evaluation brackets we can determine ourselves in what order the parameters should be evaluated.

Second example

$eval( $+(%,search-nick-4,$me) ,2)

What do we see here? We see an identifier $eval which takes two parameters, first being what you want evaluated, and second to what depth (number).

What do we want to evaluate?

$+(%,search-nick-4,$me)

This first evaluates to %search-nick-4<nickname>, this is evaluation of level 1. But since we want the value of this variable, we need to force it to evaluate one level further, so we put 2 as depth, and it evaluates %search-nick-4<nickname> to its actual value, behing "blah" here.

Why didn't I put $+(%search-nick-4,$me) ? Well because of what I already explained, that would evaluate %search-nick-4 to $null, and $me to your nickname, but we don't want that. Therefore pay specific attention to the $+(%, <-- comma that is used there, so that we are certain that the variable will not evaluate yet.

Note that the things I just explained, are means to retrieve the value of a dynamic variable, for setting you do not need to do this.

//set %search-nick-4 $+ $me will work in 100% of the cases, which you should have seen because I used the -s switch that shows what the variable is set to.

Btw, note that $( ..., N) is the same as $eval( ..., N) just shorter notation, but I reckoned I'd mention it because a lot of people, including myself, use the shorter notation.

Third example

[ [ $+(%,search-nick-4,$me) ] ]

We see a special case, where using double evaluation brackets acts like $eval(<param>, 2) in the sense that it offers you double evaluation (or re-evaluation if you will)

$+(%,search-nick-4,$me) evaluates to %search-nick-4<nickname>, which in part evalutes to "blah", which is then what is echoed.

To show this behaviour with a little easier example:

//echo -a [ [ $!me ] ]

evaluates to your nickname. It first evaluated to $me, and then evaluated $me to <nickname>

Another example:

//var -s %x = $+(%,y), %y = 5 | echo -a $(%x,0) ** %x ** $(%x,2) ** [ [ %x ] ]

-> %x ** %y ** 5 ** 5

By now you should understand exactly why you get that as result.

Nah, the comma's serve as parameter delimiters in identifiers, just like spaces serve as delimiters in commands. The commas that touch identifiers or variables within identifiers are harmless as they serve as the delimiters.

You could know this yourself with a simple test btw:

//echo -a $mid($me,2,-1) will evaluate correctly, instead of evaluating the identifier "$me,2,-1", because mIRC sees this:

3 params:

1 = $me
2 = 2
3 = -1

//var %a = 1, %b = 9 | echo -a $rand(%a,%b)

This won't evaluate the variable "%a,%b" which is a perfectly valid variable, instead mIRC sees this:

2 params:

1 = %a
2 = %b

Thus evaluating them correctly.

If we would in fact like the variable "%a,%b" evaluate, we would use evaluation brackets like this:

//set %a,%b 1 | set %c,%d 9 | echo -a $rand( [ %a,%b ] , [ %c,%d ] )

The reason for the evaluation brackets is simple: we don't want $rand to be confused with all those comma's, which it surely will, because $rand takes 2 parameters seperated by 1 comma, so it would give an error.

The reason to use evaluation brackets is to force order of evaluation again. Let's see what mIRC would do with our above code:

Before calling $rand's internal code, which takes two parameters, it first evaluates the parameters, from left to right.

It sees %a followed by a comma so it thinks: ok I found my first parameter %a now let's go to the second parameter which is what's following the comma. This is %b and so far so good. But %b is also followed by a comma, which means there is atleast 1 more parameter (3 or more) though $rand only takes 2 parameters so the following code:

//set %a,%b 1 | set %c,%d 9 | echo -a $rand( %a,%b , %c,%d )

gives you the error: * Too many parameters: $rand, which is logic because when ordering it like this:

$rand( %a , %b , %c , %d ), you can clearly see there are 4 parameters, due to the commas.

With the use of evaluation brackets, we force our two parameters to evaluate first, which they both do to their respective values 1 and 9, and now mIRC sees the identifier $rand with two parameters 1 and 9, which is perfectly valid.

Note that I don't use the /var command to show you this because as you know you can set multiple variables with the /var command, so it would see //var %a,%b as the initializing of variables %a and %b, whilst we want to initialize the variable %a,%b.

OK ...

well .. thats way to hard lol

I thank you for the GREAT exsplaination

I think i can make it work now

Thanks ..

Not so much hard as explained in depth 3 ways.

Plus FiberOptics used the word of the day (I had to look it up)

concatenate: to link together : unite in a series or chain