|
Joined: Nov 2009
Posts: 295
Fjord artisan
|
OP
Fjord artisan
Joined: Nov 2009
Posts: 295 |
I find the behavior of the on open command weird. It only triggers when someone queries me and not when I open a query window. The on close event triggers whether someone queried me or I opened the window myself. I feel the on open should trigger when I open a query with someone.
on *:open:?:*:echo -s Just opened $target query window on *:close:?: echo -s closed $target query window
(Yes I did post this in another section. I just wanted opinions and no one argued that it should work this way, so here we are.)
|
|
|
|
Joined: Feb 2006
Posts: 181
Vogon poet
|
Vogon poet
Joined: Feb 2006
Posts: 181 |
I feel the on open should trigger when I open a query with someone. Use this alias:
query {
var %c = !query
if ($1 == -n) {
%c = !query -n
tokenize 32 $2-
}
if ($1 == $null) halt
if (!$query($1)) {
%c $1
echo $1 * You just opened this query window
%c $1-
}
else %c $1-
}
Last edited by Crinul; 11/11/10 12:38 PM.
|
|
|
|
Joined: Nov 2009
Posts: 295
Fjord artisan
|
OP
Fjord artisan
Joined: Nov 2009
Posts: 295 |
Damn I was wanting to post this in bug reports since the behavior is off in my opinion.
Thanks for the alias but it doesn't account for all the ways a query window can be opened. Making the on open work no matter how the window was opened is the best solution.
|
|
|
|
Joined: Feb 2006
Posts: 181
Vogon poet
|
Vogon poet
Joined: Feb 2006
Posts: 181 |
Damn I was wanting to post this in bug reports since the behavior is off in my opinion. You did post this in 'Bug Reports', it was moved. It's certainly not an mIRC bug. Thanks for the alias but it doesn't account for all the ways a query window can be opened. The alias takes account for all the ways you open a query window. Use alias + on open event. Making the on open work no matter how the window was opened is the best solution. Might be an issue in terms of backwards compatibility.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
There is no backwards compatibility issue with added behaviour.
Using an alias doesn't account for all the ways "you" open a window. Namely, a script can still use /!query to bypass the alias, secondly, there are many non-command ways to get a query window: selecting "query" from the Notify window is one of them-- that behaviour is not overridable, nor is it tied to /query.
For what it's worth, the behaviour has to do with a somewhat archaic convention mIRC used to use regarding event triggering. In the past, the convention was that no event would ever fire if there was a command equivalent to trigger it. Recently, however, ON CLOSE was changed, and therefore it's probably time that ON OPEN changes as well for consistency's sake.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Feb 2006
Posts: 181
Vogon poet
|
Vogon poet
Joined: Feb 2006
Posts: 181 |
There is no backwards compatibility issue with added behaviour. No? Scripts use on open for query flood protection. Namely, a script can still use /!query to bypass the alias That's a good thing, if you want to bypass the alias. selecting "query" from the Notify window Query popups?
menu query {
Custom Query:query $$1
}
Recently, however, ON CLOSE was changed, and therefore it's probably time that ON OPEN changes as well for consistency's sake. 20.Extended on CLOSE event to work with channels. Because of the '/remove <nick>' command on some networks? (Not sure about this)
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
There is no backwards compatibility issue with added behaviour. No? Scripts use on open for query flood protection. And setting on open to trigger when you open a query isn't going to affect a query flood protection script. It's not like you're going to open enough queries yourself fast enough to trigger that kind of script. I really doubt there's any backward compatibility issues with triggering on open when you open the query. If there are, it likely means a script is so badly written that it needs to be updated anyhow. Also, your query popups isn't what argv0 was referring to. That still uses /query, so it *is* covered by the alias shown. argv0 was referring to things that the alias wouldn't cover.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Feb 2006
Posts: 181
Vogon poet
|
Vogon poet
Joined: Feb 2006
Posts: 181 |
And setting on open to trigger when you open a query isn't going to affect a query flood protection script. It's not like you're going to open enough queries yourself fast enough to trigger that kind of script. Something like: on ^*:OPEN:?:*: fself $nick $me $wildsite $address fself alias increments number, closes window, ignores, sends messeges.... If you open two querys that adds 2 to flood check, if you get 4+ querys from bots, that adds too. What about 'PM / Query Blocker' scripts? What about messeges sent when query opens, like away messeges?
[qpopup]
n0=Info:/uwho $$1
n1=Whois:/whois $$1
n2=Query:/query $$1
n3=-
n4=Ignore:/ignore $$1 1 | /closemsg $$1
n5=-
n6=CTCP
n7=.Ping:/ctcp $$1 ping
n8=.Time:/ctcp $$1 time
n9=.Version:/ctcp $$1 version
n10=DCC
n11=.Send:/dcc send $$1
n12=.Chat:/dcc chat $$1
n2=Query:/query $$1 (The qpopup is the notify menu too) selecting "query" from the Notify window This is what argv0 was referring to. Possible solution? on me:*:OPEN:?:*: echo -s You just opened this query window
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
Fjord artisan
Joined: Apr 2003
Posts: 342 |
Crinul, you are stretching here. It's ON OPEN not ON QUERY. A query is a private msg, or a /msg. /query <nick> <msg> opens a window. It should call the ON OPEN event.
Who is going to use ON OPEN for flood detection? Once the query window is open ON OPEN is not called again. (Actually I have not tested this... omigod please tell me it doesn't call ON OPEN whenever you get a private query!)
The help file is also incorrect.
Format: on <level>:OPEN|CLOSE:<?|@|=|!|*>:<matchtext>:<commands>
OPEN and CLOSE are not identical... they should be but they are not.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Feb 2006
Posts: 181
Vogon poet
|
Vogon poet
Joined: Feb 2006
Posts: 181 |
Query flood, not (TEXT,NOTICE,ACTION,CTCP,WHATEVER).
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
Fjord artisan
Joined: Apr 2003
Posts: 342 |
Query flood, not (TEXT,NOTICE,ACTION,CTCP,WHATEVER). A "query" triggers the ON TEXT event. In fact... try using //msg $chan $+ , $+ $me Hello World.
Last edited by MeStinkBAD; 12/11/10 07:20 PM.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Feb 2006
Posts: 181
Vogon poet
|
Vogon poet
Joined: Feb 2006
Posts: 181 |
A "query" triggers the ON TEXT event. In fact... try using //msg $chan $+ , $+ $me Hello World.
The number of query windows, that's what query flood is. Not the text sent when the query window is open.
|
|
|
|
Joined: Dec 2002
Posts: 344
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Dec 2002
Posts: 344 |
Also, your query popups isn't what argv0 was referring to. That still uses /query, so it *is* covered by the alias shown. argv0 was referring to things that the alias wouldn't cover. When you right-click a name in the notify window, it will display the query popups. In other words, right-clicking to query someone in the Notify window does in fact use /query. In fact, I've tried to find a way to open a query window that doesn't use /query and as far as I can tell, none exists. Do you have any specific examples where /query is not triggered?
|
|
|
|
Joined: Feb 2006
Posts: 546
Fjord artisan
|
Fjord artisan
Joined: Feb 2006
Posts: 546 |
What about 'PM / Query Blocker' scripts?
this is a good point that doesn't seem to have been addressed. sure, if on OPEN's functionality were extended in the manner described, scripters could still check $rawmsg or the value of certain remote identifiers to determine whether the window was opened on receipt of a PRIVMSG, but the change would still affect all scripts that presently do not. argv mentioned on CLOSE's recent change, but it still doesn't trigger when you use /window -c or /close, nor should it. MeStinkBAD, by that very reasoning on SOCKCLOSE should trigger even when /sockclose is used, which it currently doesn't. on OPEN (for query windows) without an incoming message should only trigger if /query was not used to open it, if indeed such an example exists.
"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
but it still doesn't trigger when you use /window -c or /close, nor should it. Actually, I'd think it should. That functionality has actually been suggested a few times before. As I mentioned, mIRC's policy *used to be* that /commands don't trigger events-- but frankly, that policy isn't really upheld like it was, nor is there any reason to. Why shouldn't /close trigger ON CLOSE? I don't really see a reason. A window closed. There should be a centralized way to catch this occurrence. The change to make ON CLOSE work for channels means that clicking the x button triggers the event. Why is clicking with the mouse any different from typing a /command? I don't really buy overriding builtin /commands to be a viable alternative. Sure, you *can* override /query, or /close, but there are more ways to /close a window (/window -c)-- you a) can't override them all easily, and b) the second you have 2 scripts running that both modify the alias, you're screwed. mIRC's event-based design is what makes scripts modular and robust. The answer should not be "override /query to trigger ON OPEN". That's a hideous hack. by that very reasoning on SOCKCLOSE should trigger even when /sockclose is used This is a pretty bad example, because /sockclose is actually dreadfully inconsistent w.r.t. the other /sock* commands, so you basically just opened a can of counter-argument-worms. Actually, by your reasoning, /sockopen should not trigger ON SOCKOPEN. Similarly, /sockwrite should not trigger ON SOCKWRITE. Frankly, I'll bet neither of us think that's a good idea. The consistent thing to do would be to make /sockclose trigger ON SOCKCLOSE, like the other commands. But this is a conversation about ON OPEN, not sockets, so that's another discussion. What about 'PM / Query Blocker' scripts? I don't see the issue. "query blocker" scripts tend to be in the form: ON ^*:OPEN:?:*:if ($nick == foo) halt That generally means you don't want to open a query with that nickname anyway... Sure, currently you can override this with /query, but IMO the "backwards incompatibility" here is minor. Oh no, you can no longer open a query with a nick your script is specifically designed not to open queries with. Also note that mIRC can easily mitigate this by ignoring /halt in the ^ version of ON OPEN if triggered by you-- that is to say, it won't halt if *you* open the window. That solves most related scripts (and gives you the current behaviour of overridability), while still being able to at least *trigger* the event. The alternate form of these blockers is: ON ^*:OPEN:?:*some banned phrase*:halt This doesn't even pose an incompatibility, since $1- (and matchtext) should be empty if you trigger the opening of a window anyway. I can't think of another form besides maybe flood control, but again, that shouldn't cause significant incompatibilities.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Feb 2006
Posts: 546
Fjord artisan
|
Fjord artisan
Joined: Feb 2006
Posts: 546 |
Why shouldn't /close trigger ON CLOSE? I don't really see a reason. to remain consistent with the standard that it's adhered to ever since its introduction. i'm not saying there shouldn't be a comfortable way to intercept ALL window closures, i just think it ill-advised to make such changes willy nilly. it's a shame that on OPEN/CLOSE didn't exhibit this fuller functionality to begin with; scripters have now become used to and perhaps, at times, rely on present behaviour. I don't really buy overriding builtin /commands to be a viable alternative. it isn't! in cases like these, scripters should endeavour to include the necessary handling with the portions of their scripts that use the /query, /close etc. commands. even though it can be out of their control, this is the sensible approach to the problem, and the one that should be mentioned first and foremost. Actually, by your reasoning, /sockopen should not trigger ON SOCKOPEN. no no, the key difference with on SOCKCLOSE is that it is triggered in response to external stimuli whereas those other events trigger only as a direct result of their respective /sock* commands. there are only a handful of events that are appropriate to the discussion (ones that can conceivably trigger in direct response to a command or from an external message); on SOCKCLOSE was the first that came to mind :P I don't see the issue. "query blocker" scripts tend to be in the form: ON ^*:OPEN:?:*:if ($nick == foo) halt sometimes, sometimes not. what you have there is just about the same as adding foo!*@* to your ignore list for private messages. a more common example is something similar to:
on ^*:open:?:*:%q = $nick : $1- | .timerq 1 0 $eval(%q = $input(Accept pm? %q, y), 0) | .timerq -e | if (!%q) halt
to suddenly change on OPEN in the proposed way would be undesirable for the user of such a script, don't you agree? a more pragmatic approach would be to introduce a new event prefix to have on OPEN/CLOSE trigger in response to commands, as well as what they currently do:
on ~*:OPEN:?:*:{ ; triggers for all query window openings }
as such, compatibility with older versions is fully preserved
"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
|
|
|
|
Joined: Feb 2006
Posts: 181
Vogon poet
|
Vogon poet
Joined: Feb 2006
Posts: 181 |
a more pragmatic approach would be to introduce a new event prefix to have on OPEN/CLOSE trigger in response to commands, as well as what they currently do:
on ~*:OPEN:?:*:{ ; triggers for all query window openings }
as such, compatibility with older versions is fully preserved I agree with you. Seconded.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
to remain consistent with the standard that it's adhered to ever since its introduction. Show me where this "standard" is written. Implementation is not a standard. Implementation is an implementation *of* a standard. The implementation can be wrong or simply outdated. And in fact, with the change of ON CLOSE for channels, we've seen that this "standard" has in fact been changing over the last few versions. the key difference with on SOCKCLOSE is that it is triggered in response to external stimuli But ON SOCKOPEN is not. Neither is ON SOCKWRITE. They don't trigger randomly, they trigger in response to typing /sockopen or /sockwrite respectively. Sure, there might be a delay, sometimes significant, but it's not "external stimuli". The trigger is specifically coming from your end, namely the /sockwrite or /sockopen-- it can never happen in any other manner. There is an inconsistency here. Personally, I'd rather see things in the form of ON SOCKWRITE/ON SOCKOPEN, because they are much more useful. a more common example is something similar to: on ^*:open:?:*:%q = $nick : $1- | .timerq 1 0 $eval(%q = $input(Accept pm? %q, y), 0) | .timerq -e | if (!%q) halt Sorry, no, I don't acknowledge this as more common. You're using workarounds to make things work when they should not-- ie. a /timer to make $input work even though mIRC does not allow modal dialogs in events (for a very good reason). Let these scripts break. We're not going to argue that maintaining backwards compatibility is more important than allowing for unintentional functionality. a more pragmatic approach would be to introduce a new event prefix to have on OPEN/CLOSE trigger in response to commands Extra prefixes are not necessary. I already proposed a reasonable implementation that preserves the functioning of "common" scripts (including the one above, although I don't consider it common). To repeat, /halt in a ^ event will not /halt if triggered by you. mIRC can implement an internal switch without affecting the usage. Whether you can /halt your own /queries isn't absolutely necessary. The real heart of this issue is simply being able to get a callback when you /query-- that's really all that's being asked for. In that sense, I think losing /halt on self-triggered OPEN events is a reasonable compromise. Probably not too hard to implement, either.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Dec 2002
Posts: 344
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Dec 2002
Posts: 344 |
the key difference with on SOCKCLOSE is that it is triggered in response to external stimuli But ON SOCKOPEN is not. Neither is ON SOCKWRITE. They don't trigger randomly, they trigger in response to typing /sockopen or /sockwrite respectively. Sure, there might be a delay, sometimes significant, but it's not "external stimuli". The trigger is specifically coming from your end, namely the /sockwrite or /sockopen-- it can never happen in any other manner. There is an inconsistency here. Personally, I'd rather see things in the form of ON SOCKWRITE/ON SOCKOPEN, because they are much more useful. Saying ON SOCKOPEN or ON SOCKWRITE are triggered in response to /sockopen or /sockwrite is equivalent to saying that ON TEXT is triggered by //msg $me hello. In both cases events occur outside the scope of mIRC with unpredictable delay. Just because /sockopen or /sockwrite started a chain of events doesn't mean that no external stimuli were involved at a later point.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Saying ON SOCKOPEN or ON SOCKWRITE are triggered in response to /sockopen or /sockwrite is equivalent to saying that ON TEXT is triggered by //msg $me hello. In both cases events occur outside the scope of mIRC with unpredictable delay. Just because /sockopen or /sockwrite started a chain of events doesn't mean that no external stimuli were involved at a later point. No, there is an important difference here: mIRC will *always* trigger ON SOCKOPEN. An "unpredictable delay" does not mean it's not triggered by you. It may not always come within X ms, but it is guaranteed to be triggered. You can get an unpredictable delay from many events that you trigger, /dns being the first example that comes to mind. And yet, /dns is guaranteed to trigger ON DNS in the same way ON SOCKOPEN is guaranteed to be triggered by /sockopen, regardless of the delay. This is very much unlike ON TEXT for a few reasons. First, ON TEXT is specifically in response to the server sending you a message, which means there is no guarantee that message will ever be sent. No, //msg $me hello does not guarantee an ON TEXT event will trigger. You must be connected, the server must allow that command, etc. Only at this point is another external "entity" making a decision about what you will receive. ON SOCKOPEN does not go through any external entity to get the data necessary to trigger the event. It is an inherent part of the control flow of /sockopen. You can think of /sockopen as being implemented by the following pseudo-code:
/sockopen {
MIRC_SOCKET_STRUCT *socket = create_socket();
/* read in arguments */
socket->fd = connect(socket->fd, socket->hostname, sizeof(hostname));
socket->err = WSAGetLastError();
trigger_event(EVENT_SOCKOPEN, socket);
} I used a blocking call to connect(), which mIRC may or may not be doing, but one thing is being done by both implementations: the event is triggered after connect() finishes, regardless of whether the connection was successful. In this sense, and certainly if you look at the pseudo-code above, the ON SOCKOPEN event is a direct result of the /sockopen command. Sure, connect() blocks for an indefinite amount of time, but that doesn't make the event any less direct a result of the command.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Feb 2006
Posts: 181
Vogon poet
|
Vogon poet
Joined: Feb 2006
Posts: 181 |
Sorry, no, I don't acknowledge this as more common. You're using workarounds to make things work when they should not-- ie. a /timer to make $input work even though mIRC does not allow modal dialogs in events (for a very good reason). Let these scripts break. You can make a 'PM / Query Blocker' script without using $input. You can check (hash table, text file, access level, variables) and depending on result: close query, ignore nick, send message. Not common?
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Query blockers are common (I provided 2 simple examples myself), don't misquote me. Query blockers in the form provided by jaytea are not. Most are setup to specifically block certain names or message patterns beforehand. As I mentioned, these specific types of scripts would not be affected by the change.
The only ones that would be are those that arbitrarily block nicknames based on modal user input (an invalid case, as I mentioned), or flood control scripts. For flood control, there are alternatives out there (like mIRC's builtin flood control), and worst case scenario is that you accidentally trip your flood control with /query, so it's not a huge incompatibility.
Also, given how *common* query blockers are, how easy they are to script, and how many alternatives are available (server-side ignore, /ignore, mIRC flood control, etc.), breaking a few of these scripts becomes less of a big deal. At least in this case, users have alternatives, and the simplicity of these scripts (they all seem to be < 100 lines of code) means it is trivial to fix them.
Progress should not be stunted simply for backwards compatibility's sake. There's more to the argument than "scripts will break"-- part of the question is: "how bad will it be if they break?". In this case, not so bad.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Feb 2006
Posts: 181
Vogon poet
|
Vogon poet
Joined: Feb 2006
Posts: 181 |
Sorry, no, I don't acknowledge this as more common. I thought you meant scripts like that, query blocker scripts. The only ones that would be are those that arbitrarily block nicknames based on modal user input (an invalid case, as I mentioned), or flood control scripts. For flood control, there are alternatives out there (like mIRC's builtin flood control), and worst case scenario is that you accidentally trip your flood control with /query, so it's not a huge incompatibility.
Also, given how *common* query blockers are, how easy they are to script, and how many alternatives are available (server-side ignore, /ignore, mIRC flood control, etc.), breaking a few of these scripts becomes less of a big deal. At least in this case, users have alternatives, and the simplicity of these scripts (they all seem to be < 100 lines of code) means it is trivial to fix them. This are compatibility issues, not everyone knows how to fix them. 'server-side ignore', what if the network doesn't support it? 'mIRC flood control', you can't customize it (change my nickname, etc.) '/ignore', before flood occurs?
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
This are compatibility issues, not everyone knows how to fix them. My point was that there are enough alternatives that people don't need to fix them on their own. Plenty of such scripts will *not* break, or be promptly updated upon a new release. Your link shows over 20 separate scripts, that's a lot of options for the layman. 'server-side ignore', what if the network doesn't support it? 'mIRC flood control', you can't customize it (change my nickname, etc.) '/ignore', before flood occurs? Again, these are *options*. Not all options will automatically work for everybody, but in most cases at least one option will be available. In the case where none of these options work, we can talk about the fact that there are tons of scripts out there to pickup the slack. And I'll bet there would be plenty that would be updated soon after mIRC released a new version, if the behaviour changed. I just think the idea that a broken script will never be updated is a little faulty. It's certainly a concern for monolithic scripts that no longer get maintained (ircN, PnP, etc.), but small snippets like query blocking should not pose a problem. There are enough alternatives and enough interest to update such scripts.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Feb 2006
Posts: 546
Fjord artisan
|
Fjord artisan
Joined: Feb 2006
Posts: 546 |
But ON SOCKOPEN is not. Neither is ON SOCKWRITE. They don't trigger randomly, they trigger in response to typing /sockopen or /sockwrite respectively. apparently you misunderstood me, or we're thinking about this in different ways. on SOCKOPEN and on SOCKWRITE only follow their respective /sock* commands (i said this originally). you said this: Actually, by your reasoning, /sockopen should not trigger ON SOCKOPEN. Similarly, /sockwrite should not trigger ON SOCKWRITE. that's wrong. on SOCKCLOSE doesn't follow /sockclose because there is an external stimulus involved. this external stimulus does not come in to play with on SOCKWRITE or on SOCKOPEN, that's why it's not sensible to compare them to on SOCKCLOSE. Sorry, no, I don't acknowledge this as more common. you missed the point i'm afraid. i realize that specific method is uncommon (it's the only example i had, commented out, in my scripts), that's why i qualified it with 'similar to'. what we would typically see is more like:
on ^*:open:?:*:{
if (!%qnick) {
.msg $nick Please await query authorization...
echo -ea $nick just queried you with: $1-. Press F2 to accept or F3 to reject.
%qnick = $nick
halt
}
}
alias f2 query %qnick I have accepted your query request. | unset %qnick
alias f3 .msg %qnick I have denied your query request | unset %qnick
not great, but typical. i'm not saying the fixes would be complicated, but why do you want to introduce a problem? we've already witnessed the effects on the public of abrupt changes to the client, namely: discontinuation of code page support. the way i see it, it's as simple as: if you change on OPEN then some people will be impacted negatively, if you add an event prefix then they will not. you said it yourself: There is no backwards compatibility issue with added behaviour.
what you're proposing is a change, what i'm proposing is added behaviour.
"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
Fjord artisan
Joined: Apr 2003
Posts: 342 |
jaytea, you sure are digging yourself a deeper and deeper hole...
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Feb 2006
Posts: 546
Fjord artisan
|
Fjord artisan
Joined: Feb 2006
Posts: 546 |
jaytea, you sure are digging yourself a deeper and deeper hole... frankly, i don't know what you're talking about
"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
|
|
|
|
Joined: Nov 2009
Posts: 295
Fjord artisan
|
OP
Fjord artisan
Joined: Nov 2009
Posts: 295 |
I'm glad to see some one agree with me. Also please don't get too off topic.
Lastly if mirc doesn't ever break backwards compatibility it can't move forward (not that i feel this change would do anything bad). That's why scripts should/do include what versions they work with. If it doesn't work with a new version tough luck, fix it or bug the creator to fix it.
|
|
|
|
Joined: Jan 2007
Posts: 1,156
Hoopy frood
|
Hoopy frood
Joined: Jan 2007
Posts: 1,156 |
I'm responding to everyone, not just argvo.
First of all, I was surprised that certain windows do not trigger the close or open events, but finding a work around was pretty easy. I wouldn't mind support for this but it is unnecessary.
As I said in the original post, if you want to know when a query window has been opened, either you monitor when YOU OPEN THE WINDOW, or you recognize the very first query from someone. At this point you can double check $query($nick).
I don't see how lack of open or close event for a query window would make it so you cannot write a flood protection. Depending on your server there are a few ways to monitor queries. Ex: on *:text:*:?:{ raw whisper:*:{
I wrote a few query block scripts. They basically monitored incoming queries and if the person was blocked, either it didn't allow the query window to open in the first place, or it closed the window when needed.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
And more importantly, for a backwards incompatible change of this kind, (a) the bug is minor and (b) there are many alternatives already.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
either you monitor when YOU OPEN THE WINDOW How do you do that without overriding aliases? I had already pointed out that overriding /query is extremely poor form, and a very brittle solution at that, since any secondary script that also overrides the alias would effectively wipe your code. A solution that only works "if you don't load any other scripts" isn't much of a working solution, hence the motivation for the suggestion. I don't see how lack of open or close event for a query window would make it so you cannot write a flood protection. Nobody said that you cannot write flood protection scripts if this change is made. What was said was that a small amount of scripts may break due to this change, because of the fact that ON OPEN is generally /halt'ed in these situations. [Not specifically directed to you, DJ_Sol]: Again, I should point out that a (far more) backwards compatible way to implement this feature addition would be to trigger ON OPEN for the user opening a query window locally, but *not* the ON ^:OPEN variant. The OP is not looking for a way to halt opened windows, just a reliable and centralized way to detect them.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
There's absolutely no reason to break backwards compatibility when there are several perfectly good workarounds for this situation already. One such example that comes to mind is simply changing the alias that is called when you double click on a name in the nicklist through Alt+O > Options > Mouse. Change it to something like my_query_alias_that_nobody_else_will_use and you can be sure it won't be overwritten If the on open even was to be modified then perhaps there can be something similar to $menucontext so that the scripter knows how the window opened. That way, all existing query blocker scripts that make use of on OPEN could keep their existing functionality by simply wrapping the code block in something like: if ($opencontext == message) {
; code here
}
Last edited by hixxy; 17/11/10 07:38 PM.
|
|
|
|
Joined: Jan 2007
Posts: 1,156
Hoopy frood
|
Hoopy frood
Joined: Jan 2007
Posts: 1,156 |
Well I connect to my server using a socket so I can use the local socket if I want to. I would have to see the purpose and point of a specific script to comment on how I would know if I opened a query window or not. Bottom line is that you use the /query command to open a query window. You could make an alias that does some checks then opens a query window with the /query command and put that alias in the "command to be performed when you double click the nicklist".
I monitor incoming queries and my input:?: event. I guess you could set a timer to check for query windows but that sounds pretty silly.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
One such example that comes to mind is simply changing the alias that is called when you double click on a name in the nicklist through Alt+O > Options > Mouse. Change it to something like my_query_alias_that_nobody_else_will_use and you can be sure it won't be overwritten This is the same problem as overwriting the alias, the problem is just displaced. The option itself can be overwritten, so we're still talking about a centralized point of failure. More importantly, it means only one script can access this information at a time, which is still not a sufficient solution. If I change the alias to "my_query_alias_that_nobody_else_will_use", I break "my_other_scripts_query_alias". This is definitely a workaround, but not even close to a "perfect" one. The whole point of having events is to allow scripters parallel and independent access to state operations. Just like the joining of a channel, one such state operation is the opening of a query window. Also note that the default popups menu uses /query, so that would need to be changed too. Again, you run into the problem of multiple scripts potentially modifying one centralized setting. I'm not sure why everyone is so hung up on backwards compatibility, as mentioned, there are a dozen ways in which ON OPEN can trigger WITHOUT breaking backwards compatibility. Let's stop talking about a problem that does not exist.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
I just think backwards compatibility should be maintained when there are acceptable (admittedly, not perfect) workarounds available. Perhaps this could be another event that supports the undocumented "me:" prefix so that you can catch the event triggering yourself. on me:*:open:?:{
; I opened the window.
}
on *:open:?:{
; Someone/something else caused the window to open.
}
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
Although that does well for making everyone happy, it also means there's a difference in how the non-use of the me prefix works depending on the event. For example, using me for on OP will trigger only for you. That would still be true for on OPEN with this example. However, with on OP, not using it means it triggers for everyone including you (based on the level prefix, of course). Not using it for on OPEN, however will trigger for everyone except you. Although the difference in minor and most scripters won't care one way or another, it does add to potential confusion for any new scripters because of the difference in how it works. Of course, since it's undocumented and isn't changing how it currently works, maybe it doesn't matter. I'd just expect any event that takes the me prefix to have the same 2 possibilities - me = just me, no me = everyone including me.
I don't really care either way. I do any flood protection on the TEXT event anyhow rather than the OPEN event and it works very well. Just thinking that having that difference between how it works between events might not be a good thing. Still, anything done or not done will likely not be a perfect solution for everyone, and this is probably the best solution I've seen in this thread even though I personally don't think worrying about backwards compatibility is a good excuse for not making the change in this event. It really won't affect all that many scripts and the improvement can help all of those AND more scripts, so it's a win-win for everyone once the scripts are updated and updating them is very easy.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Let me be clear, my proposal is this:
ON ^*:OPEN: should not trigger for self-opened query windows. Only ON *:OPEN: should trigger.
Since these /halting flood/spam control scripts make use of ON ^*:OPEN:, this will maintain backwards compatibility for 99.9% of existing scripts-- certainly all the ones I've seen, and all of the ones that were listed here.
As a backup, I wouldn't mind the ME: prefix, but I think simply not triggering the haltdef'd open event effectively avoids the problem.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
That would work too
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
Fjord artisan
Joined: Apr 2003
Posts: 342 |
The open event isn't triggered is the user uses a single message window. It's only fired if it's disabled and a query window doesn't already exist for the specific user. The on text event is always fired.
The problem I have is a window opening has nothing to do with receiving a private message. mIRC just happens to open a query window if the appropriate options are set. Ironically there is no option not to open a window and treat the message like it does a notice.
The open event will also fire before the on text (or ctcp action) event strangely.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
|