mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Oct 2004
Posts: 73
M
Mardeg Offline OP
Babel fish
OP Offline
Babel fish
M
Joined: Oct 2004
Posts: 73
If I enter this line in the Perform dialog for network Foo:
Code:
msg nickserv IDENTIFY $$input(Password:,qep,Identify Registered Nick for $network)

mIRC tries and fails to auto-join a channel in Favourites which is set +R (registered nicks only) before the password is entered.

But when using this code in Remotes it works:
Code:
on 1:CONNECT:{
  if ($network == Foo) msg nickserv IDENTIFY $$input(Password:,qep,Identify Registered Nick for $network)
}

Only tested on a SSL server, is this reproducible for anyone else?

Joined: Feb 2004
Posts: 2,019
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2004
Posts: 2,019
EDIT: Confirmed on DALnet.

mIRC 6.16
Windows XP, SP2

Last edited by FiberOPtics; 07/10/05 06:40 PM.

Gone.
Joined: Oct 2004
Posts: 73
M
Mardeg Offline OP
Babel fish
OP Offline
Babel fish
M
Joined: Oct 2004
Posts: 73
Update: If the +R channel window is left open after a previous disconnect, sometimes mIRC successfully waits till the Perform dialog password is entered before joining the channel.

Using the on Connect in Remotes when the +R channel is left open seems now to not wait before failing to join...

I'm unsure if it's just how fast I type the password or not.

Joined: Jul 2003
Posts: 655
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
I think its just a matter of the time it takes to enter the password, there is an internal delay between the perform and the autojoin. But when your perform prompts you its quite likely that by the time you have entered your password and the command is sent that this time delay has passed.


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Joined: Aug 2004
Posts: 7,252
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
Also confirmed on Bondage.com and BDSM-Net.com

Additionally, the problem also exists even if the password is hard coded into the Perform, rather than having a prompt.

Joined: Aug 2003
Posts: 41
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Aug 2003
Posts: 41
Not a bug. This occurs because you try to join the channel too fast, before nickserv has a change to set mode +r on you. The server will not allow you to join +R channels until you have mode +r.

Stick a

.timer 1 1

before your join command and you will see the problem disappear.

Or code an event to wait for the mode change and THEN join the channel.

Last edited by The_Mega_ZZTer; 08/10/05 12:01 AM.
Joined: Oct 2004
Posts: 73
M
Mardeg Offline OP
Babel fish
OP Offline
Babel fish
M
Joined: Oct 2004
Posts: 73
Quote:
Not a bug. This occurs because you try to join the channel too fast, before nickserv has a change to set mode +r on you.


You're assuming I'm using a join command, but this bug is referring to the built-in "Join on connect" option for a channel in Favourites, which has no method of adjusting the pausing/waiting time.

Joined: Oct 2004
Posts: 73
M
Mardeg Offline OP
Babel fish
OP Offline
Babel fish
M
Joined: Oct 2004
Posts: 73
Quote:
"there is an internal delay between the perform and the autojoin."


It's unclear when the perform code is triggered, since scripting is supposed to be single-threaded.

So this leaves me wondering why the on Connect code does work. Does it interrupt the internal delay until the prompt is entered, or are Remotes checked for on Connect before the internal delay is started between perform and autojoin?

Joined: Oct 2005
Posts: 51
T
Babel fish
Offline
Babel fish
T
Joined: Oct 2005
Posts: 51
I doubt this is a bug with mIRC, I have a feeling that its following the standard IRC protocol, and that it doesn't account for network services options like +r and +R on channels.

From what I can tell "perform" list is executed first, because its sole purpose is to perform operations upon connecting, where as on connect is part of remote scripting, and scripts are executed second due to the fact that they are multipurposed and not just ment for one operation.

I could be wrong, however, logic would dictate that order as being the current used one. Possibly, this problem could be caused by that order.

Secondly, I have a feeling that Mardeg is right, the order is linear. The on joins do not seem to be executed seperately, independent of the event before it. I have a sneaking suspision that anything that would cause a halt in the code (waiting for user input) would halt the following events.


Link Copied to Clipboard