Put in aliases. /a3 will give " */set: invalid parameters " error.

been discussed a few times in the past.

I imagine this is because /set is unique in that it scans ahead for set's %variable before it allows evaluation to begin. Since it does this before evaluation, it pays no heed to the $+ attaching it to -u. It just sees %s and says "this must be the varaible I am setting to."

You will have to use [ ]'s to force premature evaluation.

Guess what?

Thats becuase it is a invalid parameter.

just becuase u can get away with "set %blah $+ %num 123" and not have to do "set %blah [ $+ [ %num ] ] 123" doesnt mean u can getaway with it everywhere else.

Then why does [color:000099]/ban -u $+ %secs %chan %nick 3[/color] work?

Your question is flawed.

To uses another subject...

I made a statment like "Just becuase that ball bounces on concrete doesnt mean it well bounce on everything"

And you replied "Then why does my ball bounce on wood?"

Its irrelevent if it does or doesnt, its not a "then why" question.

It is?
I did?

Please point out the fundimental difference between these two commands?

[color:000099]/set -u $+ %s %var test[/color]
[color:000099]/ban -u $+ %secs %chan %nick 3[/color]

They are identical. The only difference is the /set command errors, while the /ban command does not... for the reasons I stated 2 posts ago. mIRC performs special pre-evaluation level handling for /set commands which makes it think [color:000099]%s[/color] is the target variable.

- Raccoon

the only reason i would say it is a bug is that some commands allow -u $+ %var and some don't, i wouldn't say it's a bug because -u $+ %var doesn't work.. considering that's what evaluation brackets are used for ;-]

the /set modifies a local contents for a limited time
the /ban modifies a irc security for a limited time


Lets do a little test...
//if ($(/set -u $+ %s %var test,0) == $(/ban -u $+ %secs %chan %nick 3,0)) echo My we are the same!
//if ($(/set -u $+ %s %var test,0) != $(/ban -u $+ %secs %chan %nick 3,0)) echo Hmmm we seem to be different.

Now after the (sarcasticly written) replies above, I dont really see how you felt what i said was wrong, just becuase it sometimes works dont mean it well work all the time.

Set by its logic of what its doing must not evaluate the first variable it finds else it cant set that as it would have evaluated it, and no longer have the variable name to set something to.

I hav had this to deal with...
//set %con %hold 1
it sets %con to the value of [ %hold ] 1
but %con actually held "-u30" becuase it was a conditional set of %hold for 30 seconds.
had to make it this...
//set $(%con,1) %hold 1
when i found the falut in my code before replacing with the above line, i looked at it and thought, well damn, of course its gonna set the first one to that, how is it ment to know what i wanted it to do.

//ban %con %chan %nick
is fine of course as it is would what it would be.

That's called CONSISTENCY. And there IS a similiarity between:



I don't care if they perform different commands. The problem here is the SYNTAX.

You're saying that I can do and I cannot do because they perform different things.

LOGICALLY, it is NOT an invalid parameter.

But you see the needs of the many (to set variables) out weigh the needs of the few (to resetem on a time).

As i have said else where in this message, you cant just hope for the best because something works ok in one place, that its gonna work else where.

U used this as your example "set -u $+ %s %var test"
what if insead it had this ben this...
var %display.set.for.debugging = -s
set %display.set.for.debugging %var test

now you tell me what should happen? Should it set %var to test while displaying it becuase of the -s ?

the /set command is a different command, and thus may have different syntax. it must operate differently to accomplish the goal which it is meant to achieve. deal with it, honestly.