mIRC Home    About    Download    Register    News    Help

Page 1 of 2 1 2 >
Topic Options
#212448 - 23/05/09 03:09 PM on *:NICK:#channel: { }
westor Offline
Hoopy frood

Registered: 27/12/08
Posts: 1511
Loc: Greece
Hello,

I want to ask first if can be possible to be added the on *:NICK:#channel: {} the #channel option in this event! i will give you an example for this to see that is very useful.

e.g: now with 6.35 the correct is this!
Code:
on *:NICK: {
  if ($newnick ison #mychan) {
    .msg #mychan Warning: The  $+ $nick $+  changed his/her nickname into  $+ $newnick $+ 
  }
}


Can't be this for e.g it will be very helpful in the future and good to improve the mIRC Scripting code!
Code:
on *:NICK:#mychan: { .msg #mychan Warning: The  $+ $nick $+  changed his/her nickname into  $+ $newnick $+  }
_________________________
Need Online mIRC help or an mIRC Scripting Freelancer? -> http://westor.ucoz.com/contact <-

Top
#212449 - 23/05/09 03:59 PM Re: on *:NICK:#channel: { } [Re: westor]
Jigsy Offline
Hoopy frood

Registered: 18/11/04
Posts: 798
Loc: I live inside your computer. S...
Nick changes aren't really specific to channels.

[15:58:34] <- :Jigsy`!Jigsy@Why.are.you.Whoising.me.you.Perve.rt NICK :Jigsy


And, adding ths suggestion would break everybody's scripts.
_________________________
This signature is currently out of order. We apologize for the inconvenience.

Top
#212451 - 23/05/09 04:14 PM Re: on *:NICK:#channel: { } [Re: Jigsy]
westor Offline
Hoopy frood

Registered: 27/12/08
Posts: 1511
Loc: Greece
Originally Posted By: Jigsy
Nick changes aren't really specific to channels.

[15:58:34] <- :Jigsy`!Jigsy@Why.are.you.Whoising.me.you.Perve.rt NICK :Jigsy


And, adding ths suggestion would break everybody's scripts.


Yes, the think that i want to say is that the on *:NICK:#mychan: {} will activated when a nickname change his/her nick and the NEWNICK is on the #mychan channel!


Edited by westor (23/05/09 04:15 PM)
_________________________
Need Online mIRC help or an mIRC Scripting Freelancer? -> http://westor.ucoz.com/contact <-

Top
#212454 - 23/05/09 05:13 PM Re: on *:NICK:#channel: { } [Re: westor]
Horstl Offline
Hoopy frood

Registered: 03/11/06
Posts: 1559
Loc: Germany
You cannot simply add a new event format (you mustn't have two format definitions for the same event) and, as pointed out already, changing the current format would break virtually ALL current scripts. To safe yourself a single if-condition?
That aside the event has the current format because nickchanges have no location/target - you don't change a nick "in a channel" or in some way related to a channel. It's like requesting "on *:quit:<target>:" only because a user may be in some channel while quitting.

Top
#212457 - 23/05/09 05:43 PM Re: on *:NICK:#channel: { } [Re: Horstl]
westor Offline
Hoopy frood

Registered: 27/12/08
Posts: 1511
Loc: Greece
Originally Posted By: Horstl
You cannot simply add a new event format (you mustn't have two format definitions for the same event) and, as pointed out already, changing the current format would break virually ALL current scripts. To safe yourself a single if-condition?
That aside the event has the current format because nickchanges have no location/target - you don't change a nick "in a channel" or in some way related to a channel. It's like requesting "on *:quit:<target>:" only because a user may be in some channel while quitting.


Any way i didn't see that.
_________________________
Need Online mIRC help or an mIRC Scripting Freelancer? -> http://westor.ucoz.com/contact <-

Top
#212461 - 23/05/09 07:47 PM Re: on *:NICK:#channel: { } [Re: westor]
argv0 Offline
Planetary brain

Registered: 13/10/03
Posts: 3918
Loc: Montreal, QC, Canada
How is this different from the very simple existing syntax of:

Code:
on *:NICK:if ($nick ison #) { }



_________________________
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"

Top
#212467 - 24/05/09 01:56 AM Re: on *:NICK:#channel: { } [Re: argv0]
RusselB Offline
Planetary brain

Registered: 03/08/04
Posts: 7252
Loc: Ontario, Canada
Simply due to the fact, or at least in my experience, # or $chan returns $null when referenced in a script that uses the ON NICK event.

Top
#212469 - 24/05/09 03:20 AM Re: on *:NICK:#channel: { } [Re: RusselB]
argv0 Offline
Planetary brain

Registered: 13/10/03
Posts: 3918
Loc: Montreal, QC, Canada
when i said # there I meant a literal #channel that would have been used in his matchtext anyway.
_________________________
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"

Top
#212472 - 24/05/09 04:55 AM Re: on *:NICK:#channel: { } [Re: argv0]
RusselB Offline
Planetary brain

Registered: 03/08/04
Posts: 7252
Loc: Ontario, Canada
In that case, there is no difference that I can see.

Top
#212480 - 24/05/09 02:13 PM Re: on *:NICK:#channel: { } [Re: RusselB]
westor Offline
Hoopy frood

Registered: 27/12/08
Posts: 1511
Loc: Greece
Yes, and why the ON *:NICK:#chan: { } could not be added while the JOIN , PART events have the same meaning?

e.g:
Code:
on *:part:#mychan: { .notice $nick good bye $nick }

-
e.g:
Code:
on *:nick:#mychan: { .notice $newnick good bye $nick $+ , Welcome $newnick }


i know that these could be made and with this way

e.g:
Code:
on *:part:*: {
  if ($nick ison #Mychan) {
    .notice $nick good bye
  }
}

e.g:
Code:
on *:nick: {
  if ($newnick ison #mychan) {
    .notice $newnick Good bye $nick $+ , Welcome $newnick
  }
}

_________________________
Need Online mIRC help or an mIRC Scripting Freelancer? -> http://westor.ucoz.com/contact <-

Top
#212481 - 24/05/09 02:19 PM Re: on *:NICK:#channel: { } [Re: westor]
Sat Offline
Hoopy frood

Registered: 19/04/04
Posts: 838
Loc: The Netherlands
As mentioned already in this thread: because the PART message relates to a channel in the IRC protocol (the channel is included in the message from the IRC server), while the NICK message does not. It is only natural to model the scripting language's events after what is actually going on, rather than what some people happen to find convenient.
_________________________
Saturn, QuakeNet staff

Top
#212482 - 24/05/09 02:40 PM Re: on *:NICK:#channel: { } [Re: Sat]
westor Offline
Hoopy frood

Registered: 27/12/08
Posts: 1511
Loc: Greece
Originally Posted By: Sat
As mentioned already in this thread: because the PART message relates to a channel in the IRC protocol (the channel is included in the message from the IRC server), while the NICK message does not. It is only natural to model the scripting language's events after what is actually going on, rather than what some people happen to find convenient.


So you mean that can not be added into the mIRC as an NICK event option ?
_________________________
Need Online mIRC help or an mIRC Scripting Freelancer? -> http://westor.ucoz.com/contact <-

Top
#212483 - 24/05/09 03:34 PM Re: on *:NICK:#channel: { } [Re: westor]
Horstl Offline
Hoopy frood

Registered: 03/11/06
Posts: 1559
Loc: Germany
I think you're just confused by the fact that the network is sending messages to your IRC client in both cases: if someone parts a common channel, and if someone changes his nick in a common channel.

Now these two events are different not only by name:
If someone parts a channel, the IRC network will inform all the users of this specific channel about it (including you). The message send to the users includes the channel as a parameter. You simply cannot have a part without this location parameter. Now mIRC will process this "raw" message like all other IRC clients do (it will remove the user from the nicklist, it will display a default part info etc). And it uses this message and it's parameters to create the "event" you use in scripts.
On the other hand side you can change your nick without being on any channel, the network will send a message to you to confirm the nickchange none the less (only then your nick has "changed"). You didn't change the nick anywhere specific, but an "event" occured and you can script with it. And if you have one or multiple common channels with some user who changes his nickname, the network will of course send a message to inform you about this. But you get only one message. It's this "raw" message again that mIRC will processes an of which it creates the "event". The raw message has no location parameter, consequently the event hase none.

Please try to understand that some events have a specific location (you'll always message/kick/ban/part/... somewhere) while other actions are "global" for the network (you can only quit the whole connection, and you change your nick for the whole connection). If something happens on the whole connection, it cannot have a location, right? For "global" events, it's up to you (your script) to relate it to some specific channel / all common channels / no channel at all ... or completely different things ...

Top
#213067 - 16/06/09 07:43 PM Re: on *:NICK:#channel: { } [Re: Horstl]
s00p Offline
Fjord artisan

Registered: 01/07/08
Posts: 236
Loc: Hell, Australia
Code:
on 1:NICK: {
  var %x = 1
  var %y = $comchan($nick,0)

  while (%x <= %y) {
    msg $comchan($nick,%x) warning, $nick $+ , I am a b00b.
    inc %x
  }
}


for consistency's sake, Khaled, a review of the functions that allow indexes of some sort and return something? $gettok allows ranges, $comchan is just one of those that doesn't. It'd be nice to be able to do:

Code:
tokenize 32 $comchan($nick,1-)
while ($0 > 0) {
  msg $1 $nick $+ : I'm a b00bo
  tokenize 32 $2-
}


Edited by s00p (16/06/09 07:48 PM)

Top
#213068 - 16/06/09 08:27 PM Re: on *:NICK:#channel: { } [Re: s00p]
RoCk Offline
Hoopy frood

Registered: 16/12/02
Posts: 2009

$comchan($nick,1-)

Indeed.

Top
#213070 - 16/06/09 09:10 PM Re: on *:NICK:#channel: { } [Re: s00p]
starbucks_mafia Offline
Hoopy frood

Registered: 09/12/02
Posts: 2962
Loc: Norwich, UK
I expect the token functions support ranges because there's an explicit delimiter, whereas for $comchan and most similar identifiers there isn't. To use your example again, why would $comchan($nick, 1-) return space-delimited channel names? Why not commas for usage like msg $comchan($nick, 1-) Nick change: $nick -> $newnick? In the absence of an obvious/explicit choice it makes no sense to pick one over the other and risk confusion.

In fact if anything using commas would make more sense since at least in that usage you've changed a loop into a single-line command. In your example all you've done is replace a loop through $comchan() with a loop through $n (albeit a convoluted one).
_________________________
Spelling mistakes, grammatical errors, and stupid comments are intentional.

Top
#213073 - 17/06/09 04:09 AM Re: on *:NICK:#channel: { } [Re: s00p]
Horstl Offline
Hoopy frood

Registered: 03/11/06
Posts: 1559
Loc: Germany
Additionally, while being able to return the complete index might be useful - e.g. "My comchans with $nick are: $comchan($nick,1-)" - the method you intend to use for a loop is imho unnecessarily bloated (no offense).
Code:
tokenize 32 $comchan($nick,1-)
while ($0 > 0) {
  msg $1 $nick $+ : I'm a b00bo
  tokenize 32 $2-
}
vs:
Code:
var %n = 1
while ($comchan($nick,%n)) {
  msg $v1 $nick $+ : I'm a b00bo
  inc %n
}
Ain't the latter one sufficient and more clear?

Top
#213158 - 20/06/09 03:41 AM Re: on *:NICK:#channel: { } [Re: starbucks_mafia]
s00p Offline
Fjord artisan

Registered: 01/07/08
Posts: 236
Loc: Hell, Australia
starbucks_mafia:
Have you ever used $snicks? edit: I agree

Horstl:
That depends what your opinion of "bloated" is. Each thread allocates about 1MB of stack space, and regardless of whether or not you use it, it's still statically allocated by the thread.


Edited by s00p (20/06/09 04:10 AM)

Top
#213165 - 20/06/09 06:47 PM Re: on *:NICK:#channel: { } [Re: s00p]
Quietust Offline
Ameglian cow

Registered: 09/03/03
Posts: 27
If you really want a dedicated event for it, just make a NICK event to generate a bunch of custom signals.

Code:
on *:NICK {
  var %n = 1
  while ($comchan($nick,%n)) {
    signal NICKCHAN $v1 $nick $newnick
    inc %n
  }
}

on *:SIGNAL:NICKCHAN {
  ;$1 = $chan
  ;$2 = $nick
  ;$3 = $newnick
  ;do stuff here
}


Of course, for the case mentioned by the OP, this wouldn't help much because it'd still require checking the parameters within the event handler. On that note, it'd be nice if the SIGNAL event allowed the format "on *:SIGNAL:signame:matchtext" to restrict what it matches; though that would have the same problem as extending the NICK event as described above, I personally think it would be a lot more useful.
_________________________
* Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another

Top
#213168 - 20/06/09 09:15 PM Re: on *:NICK:#channel: { } [Re: s00p]
argv0 Offline
Planetary brain

Registered: 13/10/03
Posts: 3918
Loc: Montreal, QC, Canada
What does this topic have to do with threading?

The point here is $comchan($nick, 1-) has no advantage since you will have to loop over the result either way. Looping with /tokenize is not clean nor recommended, since you destroy $1- (In an ON QUIT event, for instance, this would matter). I don't understand what the complaint is...

Code:
var %i = 1
while ($comchan($nick, %i)) { 
  do_something_with $v1
  inc %i
}


The above is far simpler (and probably faster) than any tokenization tricks.
_________________________
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"

Top
Page 1 of 2 1 2 >