Forums mIRC Help Unique nick/alternate for every network

I always use a unique nick/alternate for every network. Is this possible in mIRC without installing a copy into multiple folders?

-unworthy

Yes.

The method I use, is to store the information in a custom ini file, although there may (and probably are) other options.

An example from my ini file:


The I use the following script

Additionally the /server command will allow you to specify the main and alternate nicks using the -i switch

See /help /server for more details.

Perfect! Thank you so much, Russel!



By the way, that line doesn't seem to be working, as I disconnected from several networks and it created mnick/anick, but never asked for password, nor did it create an entry in connections.ini.

Regretfully I'm at a loss to understand why that part didn't work, as I have been using that script for the past couple of years.

How are you disconnecting from several network ? I've tried to use $? in a on disconnect event, and even when I disconnect from several network, it work, i've used :

$$?="test $network "

This shows a message box and cannot be used in a script event. Best to just echo the window with normal text and identifiers. $nick . $network . $server . $me . $scid($cid).mnick

Also, right before you connect you can set nick. /nick newnick

Like,

server -n irc.server.net | nick <nickname> | server irc.server.net

This will open a new status window and crate a cid for the new connection but not connect to it. Then set nick and connect to server.

Tell me you have tested, before came here and say this...
It work perfectly fine, try it.
If you use //scid -at1 disconnect, it disconnect you from the first server connected, then waiting for the input request, then disconnect from the second server connect etc...
Also :


-m and -i could/should be used

Using /quit or the disconnect button. Neither prompted.

The problem is simple, what happen here is that $network" does not exists, mirc would said it if you have checked the "identifier warning option" in the mIRC script editor, but since there's a '.', it quiet the output and you don't see anything.
The question is why is there a dot since /writeini does not output a message that could be annoying (like /timer) ? I've seen so many script (whole script or not) do this on several command, always wondering why they wanted to hide errors...

Ah, yes. So, mirc sees the ." as part of the variable name. I added a space and it works exactly as expected. That's definitely a bug, as mirc should know the ." isn't part of the name, once it finds that the character after the . isn't alphanumeric. Instead, mirc thinks it's looking for the " property of the $network variable!

Thanks to Wims, and everyone, for the help.

Sure, but when was the last time you disconnected from a network that you'd never visited, or that wasn't already present in connections.ini? I'm thinking that doesn't happen very often.

There's no bug.
The dot '.' is used to quiet output, this mean that nothing will be print out.
If for example you do //timer 1 1 noop, it will echo in you window :
If now you do //.timer 1 1 noop, you won't see this message.
In the situation above, mirc parse $network" as an identifier and simply, either tell you that it does not exists if you have enabled the option "identifier warning" (as an error message), either it return the $null value.In both case, mirc will stop because it's either an error and mirc stop, either the double $ make mirc stop because he his seeing $$?="... (this return $null too).This is why RusselB never see any error, not because he doesn't use his feature often.

You'd be right that it's been a while.. probably a year minimum.

I think you've misunderstood what I wrote. I realize that the '.' in front of writeini silences the output, however, that isn't the problem to which I'm referring. The '.' at the very end of the line is the problem.

By adding a space after the 2nd $network, and before the '.' at the very end, the line works exactly as expected, because $network is defined, but $network[size:14pt]. isn't defined. (Notice the trailing period?)

That's the bug, (in my opinion), because mirc shouldn't see the '.' as being part of the variable name unless an alphanumeric character follows it.[/size]

This is not a bug, but, imo, expected behaviour.

It is possible to set up an alias called network. and call it as an identifier (see /help $isid)

In the code I provided $network exists but $network. does not
(ie: there is no trailing period with the $network identifier anywhere in the code I provided).

If you alter a working code and it stops working, then the problem is with the alteration of the code, not with mIRC.

Yeah, teh identifier is $network, not $network. The bug is yours. Typo's are my bane!



$?*!="message"

Note: This identifier cannot be used in a script event.

So why does it work in the disconnect event then?

I was beleived this note was for $input but indeed, don't know why.

Alright, let's call it a feature. It is possible, but that doesn't give it an established purpose or make it especially useful. On the other hand, the purpose of a leading period in an identifier is well established. (e.g. echo -q) Of course, I may have forgotten, or missed, something in the docs, so don't hesitate to correct any mistake on my part.



Hm, nor is there one in my reply. I must be suffering from some form of dementia or senility in my old age , because I don't remember making alterations. In fact, that must have been the only alteration, because the rest of the script matches verbatim.



I couldn't agree more, except for the last three words. The usefulness of a trailing period in an identifier is somewhat debatable, imo.

In any case, thanks again for sharing the wonderful script! Huzzah!

Many times Ive hit a ket without knowing while the script editor was open. Lol, or start typing somewhere else but the cursor was in the remote editor?? I can't be alone on this.

I'd like to alter this script to update the e-mail address, as well, however, the connect event doesn't occur until after the connection is already made, and thus, uses the previous emailaddr setting. What's the best method of scripting an update to the setting just prior to connection?