Forums Feature Suggestions on *:NICK:#channel: { }

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!


Can't be this for e.g it will be very helpful in the future and good to improve the mIRC Scripting code!

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!

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.

Any way i didn't see that.

How is this different from the very simple existing syntax of:

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.

when i said # there I meant a literal #channel that would have been used in his matchtext anyway.

In that case, there is no difference that I can see.

Yes, and why the ON *:NICK:#chan: { } could not be added while the JOIN , PART events have the same meaning?

e.g:
-
e.g:

i know that these could be made and with this way

e.g:
e.g:

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 ?

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 ...

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:

$comchan($nick,1-)

Indeed.

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).

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). vs:Ain't the latter one sufficient and more clear?

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.

If you really want a dedicated event for it, just make a NICK event to generate a bunch of custom signals.



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.

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...



The above is far simpler (and probably faster) than any tokenization tricks.