|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
If there is one thing that has ALWAYS driven me nuts are the ridiculous number of events and the total inconsistency from usage of one event to the next. Eventually... I decided that I should just use SIGNAL instead... and have one event of each event which would call a single ON SIGNAL:<EVENT>: trigger. Here are the events so far... and this really shows just how many oddball events there. CTCP *:*:*: { __CALL.EVENT $1- }
RAW *:*: { __CALL.EVENT $1- }
ON ^*:LOGON:*: { __CALL.EVENT $1- }
ON *:LOGON:*: { __CALL.EVENT $1- }
ON ^*:JOIN:*: { __CALL.EVENT $1- }
ON ^*:PART:*: { __CALL.EVENT $1- }
ON ^*:QUIT: { __CALL.EVENT $1- }
ON ^*:KICK:*: { __CALL.EVENT $1- }
ON ^*:MODE:*: { __CALL.EVENT $1- }
ON ^*:SERVERMODE:*: { __CALL.EVENT $1- }
ON ^*:USERMODE: { __CALL.EVENT $1- }
ON ^*:NICK: { __CALL.EVENT $1- }
ON ^*:NOTICE:*:*: { __CALL.EVENT $1- }
ON ^*:SNOTICE:*: { __CALL.EVENT $1- }
ON ^*:TEXT:*:*: { __CALL.EVENT $1- }
ON ^*:ACTION:*:*: { __CALL.EVENT $1- }
ON ^*:CHAT:*: { __CALL.EVENT $1- }
ON ^*:SERV:*: { __CALL.EVENT $1- }
ON ^*:TOPIC:*: { __CALL.EVENT $1- }
ON ^*:INVITE:*: { __CALL.EVENT $1- }
ON ^*:PING: { __CALL.EVENT $1- }
ON ^*:WALLOPS:*: { __CALL.EVENT $1- }
ON ^*:OPEN:*:*: { __CALL.EVENT $1- }
ON ^*:CLOSE:*: { __CALL.EVENT $1- }
ON *:CTCPREPLY:*: { __CALL.EVENT $1- }
ON *:NOTIFY: { __CALL.EVENT $1- }
ON *:UNOTIFY: { __CALL.EVENT $1- }
ON *:RAWMODE:*: { __CALL.EVENT $1- }
ON *:CONNECT: { __CALL.EVENT $1- }
ON *:CONNECTFAIL: { __CALL.EVENT $1- }
ON *:DISCONNECT: { __CALL.EVENT $1- }
ON *:INPUT:*: { __CALL.EVENT $1- }
ON *:START: { __CALL.EVENT $1- }
ON *:EXIT: { __CALL.EVENT $1- }
ON *:LOAD: { __CALL.EVENT $1- }
ON *:UNLOAD: { __CALL.EVENT $1- }Now I'm not finished but does anyone spot any syntax errors? Also... I would love it so I could replace all REMOTE triggered events with RAW:*: ... not just numerics.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
1) There are more events than you listed
2) Not all events fall into the "RAW *" category, some of them are very high level UI, like on LOAD, etc.
3) There's nothing inconsistent about events besides the parameters required, which is not so much inconsistency as it is "required".
4) What are you planning on doing with a catch all event? A big if statement? Individual events is a better design, that's why it was done this way.
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
In responce to question 4... ALIAS __CALL.EVENT {
var %error, %error.num = 0
var %ticks = $ticks
:_error
if $error {
var %error = $error
if (%error.num) $&
/halt
inc %error.num
/!reseterror
/output ERROR -esp ERROR - %error
if ($var(%h.event,1).local) $&
/hfree %h.event
/halt
}
if ($numeric isnum) {
var %event = $+($#,$numeric)
}
elseif $len($event) {
var %event = $+($#,$upper($event))
}
while ($len($hget($+(%event,.,%ticks)))) { inc %ticks }
var %h.event = $+(%event,.,%ticks)
/hmake %h.event 30
/hadd %h.event EVENT $iif($len($numeric),$numeric,$event)
/hadd %h.event NUMERIC $iif($len($numeric),$numeric)
/hadd %h.event ARGSTRING $iif($0,$1-)
/hadd %h.event TARGET $iif($len($target),$target)
/hadd %h.event CHAN $iif($len($chan),$chan)
/hadd %h.event NICK $iif($len($nick),$nick)
/hadd %h.event NEWNICK $iif($len($newnick),$newnick)
/hadd %h.event ADDRESS $iif($len($address),$address)
/hadd %h.event SITE $iif($len($site),$site)
/hadd %h.event WILDSITE $iif($len($wildsite),$wildsite)
/hadd %h.event FULLADDRESS $iif($len($fulladdress),$fulladdress)
/hadd %h.event RAWMSG $iif($len($rawmsg),$rawmsg)
/hadd %h.event INPASTE $iif($len($inpaste),$inpaste)
/hadd %h.event CNTLENTER $iif($len($ctrlenter),$ctrlenter)
/hadd %h.event NETWORK $iif($len($network),$network)
/hadd %h.event HALTDEF $false
if ($EVENT == CTCP) || ($EVENT == CTCPREPLY) $&
/hadd %h.event CTCP $1
/DEBUGMSG 12 -l1 $+([,%event,]) %h.event $iif($len($numeric),$numeric,$event) $1-
/set -u %g.hevent %h.event
/.signal -n $($+(+,%event)) $1-
if ($halted || $:haltdef) { /.signal __CALL.POST.EVENT %h.event %event $true $1- }
else $&
/.signal __CALL.POST.EVENT %h.event %event $false $1-
:error
if $len($error) { goto _error }
}
on *:SIGNAL:__CALL.POST.EVENT: {
set -eu %g.hevent $1
if (!$3) $&
/.signal -n $2 $4-
if $hget(%g.hevent) { /hfree %g.hevent }
/unset %g.hevent
}
ALIAS :EVENT return $hget(%g.hevent,EVENT)
ALIAS :NUMERIC return $hget(%g.hevent,NUMERIC)
ALIAS :ARGSTRING return $hget(%g.hevent,ARGSTRING)
ALIAS :RAWMSG return $hget(%g.hevent,RAWMSG)
There's more btw...
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
1) There are more events than you listed Yes... there are... 2) Not all events fall into the "RAW *" category, some of them are very high level UI, like on LOAD, etc. I said all REMOTE triggered events. Events triggered by a server or another user. Not local events! [3) There's nothing inconsistent about events besides the parameters required, which is not so much inconsistency as it is "required". LOL! Yes... the problem... that the "required" parameters for events are sometimes more "required" than others.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
Wow, mIRC's way of doing things is a ton neater than that.
You've written a lot of unnecessary code and it doesn't even offer an improvement over mIRC events.
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
I said all REMOTE triggered events. Events triggered by a server or another user. Not local events! ON START, ON LOAD, ON UNLOAD, ON EXIT, ON INPUT are all local events. ON CONNECT, ON CONNECTFAIL, ON DISCONNECT, ON LOGON are "remote" events, but not all remote events correlate with RAW *. Specifically, none of these events occur due to any actual "RAW" server response. They are all meta-events, which RAW events do not handle. RAW events are only meant for actual text coming in from the server connection, nothing else. LOL! Yes... the problem... that the "required" parameters for events are sometimes more "required" than others. No, this was not my point. There is no such thing as "more required". The issue is that some events don't have the same parameters as others, and therefore require different syntax. Consider ON TEXT vs. ON NICK. Text events require a matchtext and a channel (or target). an ON NICK event has neither, therefore one requires ":*:#:" and the other does not. This is completely logical and consistent with the IRC protocol.
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
Wow, mIRC's way of doing things is a ton neater than that. How does miRC "do things"? And mIRC code is not neat. You've written a lot of unnecessary code and it doesn't even offer an improvement over mIRC events. Do you have *any* idea how much time this has reduced me looking up stuff in the help file to do inconsistencies between how different events are handled? I would estimate maybe a 1/3. More than the amount of time it took to write... and that was less than three months ago...
Last edited by MeStinkBAD; 16/08/10 08:29 PM.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
I meant that the built-in method of event handling is so much neater and easier to use. on *:text:hello world:#:{
echo -a hello world
}vs. on *:signal:+#TEXT:{
if ($:ARGSTRING == hello world) { echo -a hello world }
}(from what I can fathom from your script and assuming $# returns #) More code. Not at all more self explanatory or easier to remember than the built-in event syntax.
|
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
I said all REMOTE triggered events. Events triggered by a server or another user. Not local events! ON START, ON LOAD, ON UNLOAD, ON EXIT, ON INPUT are all local events. ON CONNECT, ON CONNECTFAIL, ON DISCONNECT, ON LOGON are "remote" events, but not all remote events correlate with RAW *. Specifically, none of these events occur due to any actual "RAW" server response. They are all meta-events, which RAW events do not handle. RAW events are only meant for actual text coming in from the server connection, nothing else. Since everything you have stated is true, I *know* you understand what I'm saying about when RAW * is executed. No, this was not my point. There is no such thing as "more required". The issue is that some events don't have the same parameters as others, and therefore require different syntax. Consider ON TEXT vs. ON NICK. Text events require a matchtext and a channel (or target). an ON NICK event has neither, therefore one requires ":*:#:" and the other does not. This is completely logical and consistent with the IRC protocol. Here let me give you an example... ON INPUT. It requires one parameter. But off the top of my head i don't recall if it's the window name, or the text entered that it matches. Pretty sure it's the former but not positive. Ambiguous "parameters" like that are a problem. People quickly learn that it's easier to just always use *. No one ever really uses these parameters because they aren't universal. What is universal is the user level (which also no one uses in event definitions). mIRC makes things worse with the event prefix like ^. Notice that ^ is required to halt all default text for mode events... except RAWMODE. This truly makes no sense. and basically shows that the ^ ends up hurting more than it helps.
Last edited by MeStinkBAD; 16/08/10 09:14 PM.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
You know, just learning the language isn't that difficult to do. I have no difficulty remembering the parameters for on INPUT because I use it. If you've been using that thing you scripted for so long, then it is no wonder you can't remember basic syntax. I had on INPUT memorized (without actually trying to) within a very short time of starting to script.
Now, there are certain events that I don't remember because I rarely use them (such as on SIGNAL). However, it is so quick to open help and get the syntax that it isn't really a waste of time. And if I find that I'm using the event more often, I'll end up remembering the syntax for that as well.
I really don't see a benefit to changing the language into something it isn't instead of using what works and learning it. But if that makes it easier for you, go for it. I'll stick to using the events the way they are designed.
Invision Support
#Invision on irc.irchighway.net
|
|
|
|
|
