Forums Scripts & Popups ^* Prefix for Remote

What exactly does the
^* User Mode Prefix do as oppossed to just * on remotes?

ON ^*:NOTICE: vs ON *:NOTICE:
The former (1st one: ON ^*:NOTICE:) works with this auto-identify script I wrote but the latter (2nd one: ON *:NOTICE:) Does not... Why?
Yet the latter works ok for some servers but not all, but the former works on em all. So what specifically does the ^ do?

/help halting default text

the prefix of *:... just executes for all user modes. Mirc handles the event, then passes it on to you. So if you hade a nick change and had..

on *:NICK: {
/echo -a $nick wants to be called $newnick $+ !
}

You would see...

* KingTomato is now known as KingTomato|Away
KingTomato wants to be called KingTomato|Away

Where as if you had:

on ^*:NICK: {
/echo -a $nick wants to be called $newnick $+ !
}

Now, you would see

KingTomato wants to be called KingTomato|Away
* KingTomato is now known as KingTomato|Away

As you can see, with the ^ prefic, you are able to parse soemthing before mirc has a hand at it, ratehr than after. This is useful for making your own interface, and chnaging the appearance of client messages.. Such as changing the mirc default <nick> to something more decrative such as «(~nick~)».

Thanks, but one thing i dont get, why the ON ^*:NOTICE: worked for this specific while the regualr ON ^:NOTICE: did not for that specific server, yet works on all the others, if there is no answer that is fine, but I have already converted all my statements to ON ^*:NOTICE: to avoid future mishpas

^ isn't specifying a level.. * = all levels, 1 = default level, but ^ is just a prefix

^ halts the standard mirc response ... so in your post saying that the nickname change would aslo say that is wrong

if u had
on *:NICK: { echo -a $colour(nick) NickChange: $nick wants to be called $newnick }

you would see
NickChange: bob wants to be called ted
* bob is now known as ted

if u had
on ^*:NICK: { echo -a $colour(nick) NickChange: $nick wants to be called $newnick | halt }

you would see
NickChange: bob wants to be called ted

the ^ prefix does nothing more than act as a halt identifier for the standard mirc expression

help file:
The ^ event prefix
You can prevent the default text for an event from being shown by using the ^ prefix in an event definition. This allows you to show your own custom event messages.

on ^1:JOIN:#:echo $chan Joins: $nick | halt

This line is triggered by a JOIN event and shows your own custom join event message, /halt prevents the normal message from being shown.

The ^ events don't replace your existing events; your normal events are independent and are still processed whether there is a ^ event in a script or not.

If you only want to halt the default text without /halting the entire script, you can use the /haltdef command.

again type /help Halting default text

it fully explains this there

Must a quote the help file...



if u had
on *:NICK: { echo -a $colour(nick) NickChange: $nick wants to be called $newnick }

you would see
NickChange: bob wants to be called ted
* bob is now known as ted

Untrue, the default mirc text would appear first, no second... 'nuf said

And to further prove it, I had by bot change nicks.

[01:18:24] [KingTomato] ^nick Testing
[01:18:24] *ChanSys is now known as TestNickChng
NICK: Testing

Code:
on *:NICK: { /echo -a NICK: $newnick }

ok what does that have to do with user modes? i mean maybe i missread your example but the person was asking if it was a user mode in your example u even shed alil light on this .. but u never explained it at all



u left the person in question needing more info than u provided ... if your didnt like my explanation hey sorry wasnt meant as a shot at you

I was simple correcting you on your order of events when using the carrot. You has said that mirc default text shows after an echo in an event even without the carrot. I was just simply stating what correctly happens.

The question was also why the ^ does not work as a user level and what effect does it have on scripts. Both questions were answered already by myself, and Nimue pointed out the help index.

u left the person in question needing more info than u provided ...
...so you came and provided wrong information, possibly adding up to his confusion.

Let me quote you:
^ halts the standard mirc response ... so in your post saying that the nickname change would aslo say that is wrong
the ^ prefix does nothing more than act as a halt identifier for the standard mirc expression

Both statements are wrong and it seems that you don't understand what the ^ does. KingTomato's explanation was fine, merely because it was correct. He even said that it can be used to customize the display of events, although he didn't mention /halt or /haltdef.

The ^ prefix does NOT halt anything, /halt or /haltdef do that. All ^ does is let the event trigger BEFORE the default mirc behaviour, so that /halt (IF used) gets a chance to stop that behaviour. Have you tried to use the ^ prefix without /halt? Maybe then you'd get an idea about what it does, although just reading KingTomato's post should give you some hints.

TY qwerty >:D Yes, i did forget to mention the haltdef, but something you just have to figure out yourself. >:D

Well than I guess my question is what is the: (^ present)

ON ^*:NOTICE:*This nickname is registered and protected.*:?: {
if (( $nick == NickServ ) && ( AnimeNetworks isin $network )) {
.msg NickServ IDENTIFY <PASSWORD>
}
}

doing? versus the: (no ^)

ON *:NOTICE:*This nickname is registered and protected.*:?: {
if (( $nick == NickServ ) && ( AnimeNetworks isin $network )) {
.msg NickServ IDENTIFY <PASSWORD>
}
}

Because the 1st one recognizes the NickServ message:

-NickServ- This nickname is registered and protected. If it is your
-NickServ- nick, type /msg NickServ IDENTIFY password. Otherwise,
-NickServ- please choose a different nick.

Whiel the second does not...

the former would register before you yourself sawy the nickserv message displayed on the screen, where as the latter would wait to show it first.

As to wy would trigger and one wouldn't I'm not sure. Teh fact that you trigger it before or after default text shouldn't matter.

You are also able to dispense with the outer set of parentheses, no need for them in this script.

Yes, but its not a bad habbit to get into. Especially if you ever considered going onto another language such as C\C++ where they are required.