|
|
Joined: Jan 2003
Posts: 64
Babel fish
|
OP
Babel fish
Joined: Jan 2003
Posts: 64 |
There is already functionality in place in 7.17 that allows you to customize where/whether joins/parts/quits are shown in a #channel. It would be helpful to have remote control over this functionality. Writing a script to do the same thing isn't difficult but it's certainly much faster to have the program do it.
There are a lot of channels, for instance #ActiveTrader on FinancialChat and #CLGaming on QuakeNet and where you have tons and tons of people joining/parting/quitting. This would let you screen out some of this "event traffic."
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
It seems like what you're really asking for is not a programmatic /command to control join/part displays, but you want individual channel controls. Or perhaps you're just asking for both. In any case, yes, individual channel controls for hiding join/parts would be nice. However, I'm not sure how high on the list this would really be, given how easy it is to script:
on ^*:JOIN:%hide.channels:haltdef
on ^*:PART:%hide.channels:haltdef
alias hidejoins %hide.channels = $addtok(%hide.channels,$1,44)
alias unhidejoins %hide.channels = $remtok(%hide.channels,$1,0,44)
alias listjoins echo -a * Hiding join/parts on: %hide.channels
You would /hidejoins #mychan to hide it, /unhidejoins #mychan to unhide it, and /listjoins to list what channels the script is working for. Note that I've ignored the QUIT event since the purpose isn't to write you a script but rather to point you in the right direction. It's not much harder, but it's not as braindead simple as JOIN/PART. Again: yes, it would be more convenient to have a channel specific option for, but there are lots of more immediate issues that need dealing with.
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: Jan 2003
Posts: 64
Babel fish
|
|
OP
Babel fish
Joined: Jan 2003
Posts: 64 |
You're right; it would be easy to script... "except." The problem is we wouldn't really ignore all parts and quits. We would only ignore non-active chatroom users who /part and /quit. If someone speaks on the channel, we don't ignore them leaving because we could be talking to them on the channel. Scripting *that* would slow down mIRC. Believe me, I've tried. In some of the channels I visit, you can fill a whole 30k variables.ini in 2 hours -- and then, the script stops working. 
|
|
|
|
|
Joined: Apr 2010
Posts: 969
Hoopy frood
|
|
Hoopy frood
Joined: Apr 2010
Posts: 969 |
Am on a channel of over 1000ppl at the moment, and if my "other nicks" script hasn't had a problem then your's shouldn't try using a hashtable, clear out old data, update with new data constantly Here's an example(I haven't tested it): alias hidejoins %hide.channels = $addtok(%hide.channels,$1,44)
alias unhidejoins %hide.channels = $remtok(%hide.channels,$1,0,44)
alias listjoins echo -a * Hiding join/parts on: %hide.channels
on *:TEXT:*:%hide.channels:{
hadd -mu3600 $+(hc,$cid,:,$chan) $nick spoke
}
on *:ACTION:*:%hide.channels:{
hadd -mu3600 $+(hd,$cid,:,$chan) $Nick spoke
}
on *:NOTICE:*:%hide.channels:{
hadd -mu3600 $+(hd,$cid,:,$chan) $nick spoke
}
on ^*:PART:%hide.channels:{
if ($nick == $me) { if ($hget($+(hd,$cid,:,$chan))) { hfree $v1 } }
elseif ($hget($+(hd,$cid,:,$chan),$nick)) { hdel $+(hd,$cid,:,$chan) $nick }
else { haltdef }
}
on *:DISCONNECT:{
var %x = 1
while ($hget(%x)) {
if ($+(hd,$cid,:,*) iswm $v1) { hfree $v2 }
else { inc %x }
}
}
on ^!*:QUIT:{
var %x = 1, %c, %halt = $true
while ($gettok(%hide.channels,%x,44)) {
%c = $v1
if ($nick ison %c && $hget($+(hd,$cid,:,%c),$Nick)) {
hdel $+(hd,$cid,:,%c) $nick
%halt = $false
}
inc %x
}
if (%halt) { haltdef }
}
Last edited by FroggieDaFrog; 20/01/11 08:44 AM.
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
"Except" what you've described is not how mIRC behaves. The setting for show/hiding joins/parts in Alt+O -> IRC -> Events will show or hide ALL join/parts, regardless of whether they spoke. Making this setting work for individual channels would not magically make it do what you just described-- and it was not part of your initial suggestion. So now it sounds like you've quietly introduced a new requirement: you also want mIRC to only hide these events if the user is inactive. THAT won't happen-- or at least, I highly doubt it will. That makes the feature fairly incongruous and seemingly random (how do you define "active"? everybody would have their own heuristics) Lastly, I reserve my right to *not* believe you. There's no reason scripting that behaviour yourself should/would slow down mIRC. If you're "filling 30k" of variables in 2 hours, you're undoubtedly doing it wrong. Here is a slightly modified version of the above that excludes active users:
ON *:TEXT:*:%hide.channels:hadd -mu60 hidejoins $+($cid,.,$nick) $true
ON ^*:JOIN:%hide.channels:haltdef
ON ^*:PART:%hide.channels:if (!$hget(hidejoins,$+($cid,.,$nick))) haltdef | hdel hidejoins $+($cid,.,$nick) Show me that script acting slow and I'll change my mind.
- 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 |
For the record, mIRC already keeps track of how long a particular user has been idle on a given channel with $nick(#,nick).idle. This should work: ON ^*:PART:%hide.channels:if ($nick(#,$nick).idle > 60) haltdef Quit would require a bit more work (in particular if you want to only hide the quit message from one channel when you have more than one common channel), but it should still be fairly efficient.
|
|
|
|
|
Joined: Jan 2003
Posts: 64
Babel fish
|
|
OP
Babel fish
Joined: Jan 2003
Posts: 64 |
Froggie: Thanks for reminding me about the -uN switches; I had totally forgotten about those. I think another rationale for feature inclusion is the idea that we don't need mIRC and scripts doing the same thing. If you just click the system menu, the functionality is there. Do we really need to make a popup that does entirely the same thing? Since mIRC already has this functionality (you're at the 20 yard line), it makes sense just to finish the deal rather than have a script replicate the functionality totally. argv0... Sequence of events here is that I made a feature suggestion and you made a counter-suggestion, which you are entitled to. After I reiterated that I thought the feature was needed, you say you "don't believe me." Thanks but this isn't kindergarten. Here is the script I was using as of the last effort: on ^1:PART:#:{
if (%HaltDef: [ $+ [ $chan ] ]) { // If we are hiding events on this channel
var %%%evaluate = $+($chr(37), $chr(37), NoHaltDef:, $chan, :, $nick)
if ($eval(%%%evaluate, 2)) unset %%NoHaltDef: $+ $chan $+ : $+ $nick
else haltdef
}
}
on ^1:QUIT:{
var %%%comchan.scan = 1
var %%%comchan.max = $comchan($nick, 0)
while (%%%comchan.scan <= %%%comchan.max) {
var %%%comchan.chan = $comchan($nick, %%%comchan.scan)
if (%HaltDef: [ $+ [ %%%comchan.chan ] ]) { // Once again, if we are hiding events on this channel.
var %%%evaluate = $+($chr(37), $chr(37), NoHaltDef:, %%%comchan.chan, :, $nick)
if ($eval(%%%evaluate, 2)) unset %%NoHaltDef: $+ %%%comchan.chan $+ : $+ $nick
else haltdef
}
var %%%comchan.scan = $calc(%%%comchan.scan + 1)
}
}
|
|
|
|
|
Joined: Dec 2002
Posts: 344
Pan-dimensional mouse
|
|
Pan-dimensional mouse
Joined: Dec 2002
Posts: 344 |
Since I'm bored I'll go ahead and give you a fully working script that should avoid any performance issues: on ^!*:JOIN:%hide.channels:haltdef
on ^!*:PART:%hide.channels:if ($nick(#,$nick).idle > 180) haltdef
on ^!*:QUIT:{
var %i = $comchan($nick,0)
while (%i > 0) {
var %c = $comchan($nick,%i)
if (($istok(%hide.channels,%c,44)) && ($nick(%c,$nick).idle > 180)) haltdef
dec %i
}
}I understand that you'd rather see this implemented directly in mIRC, but my personal opinion is that it is unlikely to happen. This is your best alternative.
|
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
Show me that script acting slow and I'll change my mind. It won't act slow but it does have a slight bug. Your on PART event needs some braces: ON ^*:PART:%hide.channels:if (!$hget(hidejoins,$+($cid,.,$nick))) { haltdef | hdel hidejoins $+($cid,.,$nick) }Otherwise it will try to /hdel an item that doesn't exist when the person leaving is not in the hashtable. Here is the script I was using as of the last effort: on ^1:PART:#:{
if (%HaltDef: [ $+ [ $chan ] ]) { // If we are hiding events on this channel
var %%%evaluate = $+($chr(37), $chr(37), NoHaltDef:, $chan, :, $nick)
if ($eval(%%%evaluate, 2)) unset %%NoHaltDef: $+ $chan $+ : $+ $nick
else haltdef
}
}
on ^1:QUIT:{
var %%%comchan.scan = 1
var %%%comchan.max = $comchan($nick, 0)
while (%%%comchan.scan <= %%%comchan.max) {
var %%%comchan.chan = $comchan($nick, %%%comchan.scan)
if (%HaltDef: [ $+ [ %%%comchan.chan ] ]) { // Once again, if we are hiding events on this channel.
var %%%evaluate = $+($chr(37), $chr(37), NoHaltDef:, %%%comchan.chan, :, $nick)
if ($eval(%%%evaluate, 2)) unset %%NoHaltDef: $+ %%%comchan.chan $+ : $+ $nick
else haltdef
}
var %%%comchan.scan = $calc(%%%comchan.scan + 1)
}
} Variables are horrible inefficient when compared to hashtables. Try using drum or argv0's scripts and you will see speed improvements.
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
The missing { } is intentional. As you can see, I'm haltdef'ing when the item is not present in the table. It is only present when they are active. Your change makes it so the item is never reset.
In any case, deleting an item that doesn't exist is not a bug, since it's effectively a noop. The point is to reset any state when they leave.
- 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 |
After I reiterated that I thought the feature was needed, you say you "don't believe me." I'm not saying I don't believe the feature is needed. I was responding to: Scripting *that* would slow down mIRC. Believe me, I've tried. Don't act like you're a scripting champ and you "obviously" know what is feasible, when you don't. The point is that scripting it is not inefficient. Again, it's unclear what you're suggesting. First you asked for programmatic commands, then you asked for channel specific settings, now [it seems like] you're asking to only hide inactive users. All of these three are completely separate suggestions, and you haven't really clarified exactly what you want. To clarify my end: I believe that a channel independent UI control for showing/hiding events is "useful" (not "needed"). However, the rest of it (programmatic command, only hiding inactive users) brings this feature into scripting territory.
- 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 |
drum: You can't [just] use $nick(#,$nick).idle.
Idle is reset on join, which means 5 seconds after join, $nick(#,$nick).idle == 5.
Anyone who quickly joins/parts will show up even if they've said nothing in the channel. This actually accounts for a large chunk of "event noise" in large channels, where people join and quickly leave. You would see random parts from people who have said nothing. That's why I use a switch set via ON TEXT.
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: Jan 2003
Posts: 64
Babel fish
|
|
OP
Babel fish
Joined: Jan 2003
Posts: 64 |
Don't act like you're a scripting champ and you "obviously" know what is feasible, when you don't You're still trying to make this personal. Like I said, this isn't kindergarten.
Last edited by MegaZeroX; 20/01/11 10:28 PM.
|
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
The missing { } is intentional. As you can see, I'm haltdef'ing when the item is not present in the table. It is only present when they are active. Your change makes it so the item is never reset.
In any case, deleting an item that doesn't exist is not a bug, since it's effectively a noop. The point is to reset any state when they leave. You're right. It's been a while since I scripted properly, I could have sworn that /hdel used to throw an error if the item didn't exist.. but it looks like it only throws an error when the table doesn't exist.
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Actually, you're the one making it personal. I've asked you repeatedly to get back on topic and clarify your feature suggestion. You've yet to do so, and instead chosen to focus on "personal" issues. Frankly, I'm not even sure what you really want from this suggestion, anymore.
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
